[RFC] cygport mingw.cygclass

[Brian Inglis]

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.]