Re: [RFC] cygport mingw.cygclass

[Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>]

On 2021-06-20 12:50, Brian Inglis wrote:
> 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.

Seems to be caused by cygport ... package not iterating to DTRT:

$ llgo curl-7.77.0-1.noarch/??st/*/
curl-7.77.0-1.noarch/dist/curl/:
total 5.3M
-rw-r--r--  1  902 Jun 20 11:44 curl-7.77.0-1.hint
-rw-r--r--  1 3.0M Jun 20 11:43 curl-7.77.0-1.tar.xz
-rw-r--r--  1  722 Jun 20 11:44 curl-7.77.0-1-src.hint
-rw-r--r--  1 2.4M Jun 20 11:44 curl-7.77.0-1-src.tar.xz
drwxr-xr-x+ 1    0 Jun 20 11:44 curl-debuginfo/

curl-7.77.0-1.noarch/inst/usr/:
total 0
drwxr-xr-x+ 1 0 Jun 20 11:42 i686-w64-mingw32/
drwxr-xr-x+ 1 0 Jun 20 11:43 lib/
drwxr-xr-x+ 1 0 Jun 20 11:43 share/
drwxr-xr-x+ 1 0 Jun 20 11:43 src/
drwxr-xr-x+ 1 0 Jun 20 11:42 x86_64-w64-mingw32/

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