On 2020-12-28 11:23, Achim Gratz wrote:
Yaakov Selkowitz writes:
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.)
I've had a look finally and when I say that I really mean reading the
diffs…
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.
Anything that you'd particularly want to have checked or just generally
that things still work? I still need to rebase that branch to current
master and then put my patches on top, so I don't expect to immediately
start testing.
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
I'm not particularly enamored with mingw32 as that's not what it is
(both are using MingW-W64), on the other hand I have no better idea
either.
* 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.
I'd tend to leave the names alone unless/until we come up with a way to target
multiple cross-architectures from the same package source.
I'm now implementing this for the libraries I maintain, having used
gvimdiff to edit the Cygwin PKG and mingw64-ARCH-PKG cygport files
consistently (and maintain consistency across packages), now adding
mingw-PKG.cygport, and see a few issues, of varying impact:
* file name - mingw-PKG.cygport - so it can be in the same repo as PKG
* NAME = PKG - SRC_DIR does not appear to be handled differently so this
works for default SRC_DIR=$P; mingw internally strips mingw- prefix for
some uses but not this?
* SUMMARY - used to suffix " (Win<BITS> development)" - now should we
just use Win, or change to Mingw, or exported symbol?
* DESCRIPTION - used to append:
"Package provides Mingw MS VC RT-linked binaries, NOT Cygwin binaries,
for use with the mingw64-<XARCH>-gcc cross compiler, installed in
/usr/<XARCH>-w64-mingw32/sys-root/mingw/{bin,lib,include}/."
now:
"Package provides Mingw MS VC RT-linked binaries, NOT Cygwin binaries,
for use with the mingw64-{x86_64,i686}-gcc cross compiler, installed in
/usr/{x86_64,i686}-w64-mingw32/sys-root/mingw/{bin,lib,include}/."
or ?
* BUILD_REQUIRES - need to handle ARCH variant dependencies - used to
use <XARCH> - now use pattern \$[X]ARCH or MINGW32/64_BUILD_REQUIRES or ?
Suggested/desired/best practices before I do too many more?
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]
