[RFC] cygport mingw.cygclass

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[RFC] cygport mingw.cygclass

Yaakov Selkowitz
To ease the maintenance of MinGW cross-compiling packages, I have
written a new mingw.cygclass (actually, a series of cygclasses, but
that's the top-level one that you should use) which is designed to
allow building both 32- and 64-bit MinGW binaries in the same build.
 It also allows for the introduction of Windows for ARM toolchains,
which I have bootstrapped but am not able to verify due to the lack of
access to such systems.  (Therefore, they are disabled by default.)

Because this moves fundamentally away from the single-arch paradigms on
which cygport was built (remember that cygport predates the widespread
availability of 64-bit Windows systems), extensive changes were
required that could possibly break something.  Therefore, I have posted
this to the topic/mingw branch of cygport.  If maintainers could please
test this with both mingw and ordinary packages, that would be
appreciated.

Also needed is feedback on the naming schemes currently used:

* mingw32_* functions and MINGW32_ definitions/variables for i686
* mingw64_* functions and MINGW64_ definitions/variables for x86_64
* mingwarm32_* functions and MINGWARM32_ definitions/variables for
armv7
* mingwarm64_* functions and MINGWARM64_ definitions/variables for
aarch64

* mingw-* for source package names
* mingw64-i686-* for i686 binary packages
* mingw64-x86_64-* for x86_64 binary packages
* mingw64-armv7-* for armv7 binary packages
* mingw64-aarch64-* for aarch64 binary packages

The function/definition naming scheme is designed around Fedora (which
does not have ARM, so I made those up myself) but the binary package
scheme match our current usage.  I realize the source package names are
those from the old i686-only mingw.org packages; whether we want to
rename the binary packages to mingw32-/mingw64-, or rename the source
packages to mingw64-, or do something else entirely, I'm open to
suggestions.

--
Yaakov