[RFC] cygport mingw.cygclass

[Brian Inglis]

On 2021-06-20 09:54, Brian Inglis wrote:
> 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?

Upload does not seem to DTRT:

$ cygport mingw-curl.cygport upload
 >>> Uploading curl-7.77.0-1.noarch
 >>> Running lftp sftp://cygwin:@cygwin.com
cd ok, cwd=/noarch/release
Transferring file `curl-7.77.0-1-src.hint'
Transferring file `curl-7.77.0-1-src.tar.xz'
Transferring file `curl-7.77.0-1.hint'
Transferring file `curl-7.77.0-1.tar.xz'
Making directory `curl-debuginfo'
Transferring file `curl-debuginfo/curl-debuginfo-7.77.0-1.hint'
Transferring file `curl-debuginfo/curl-debuginfo-7.77.0-1.tar.xz'
Total: 1 directory, 6 files, 0 symlinks
New: 6 files, 0 symlinks
8019667 bytes transferred in 34 seconds (227.7 KiB/s)
Upload complete.

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