[RFC] cygport mingw.cygclass

Wed Jun 23 05:19:54 GMT 2021

On 2021-06-20 13:00, Brian Inglis wrote:
> 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/

$ l curl-7.77.0-1.noarch/inst/usr/**/d*/curl*/
curl-7.77.0-1.noarch/inst/usr/share/doc/curl
curl-7.77.0-1.noarch/inst/usr/src/debug/curl-7.77.0-1/lib

Looks like in these cases install should create duplicated or linked 
mingw package arch dependent directories instead of e.g.

	PKG-VER.noarch/inst/usr/share/doc/PKG 			->
->	PKG-VER.noarch/inst/usr/share/doc/mingw64-*86*-PKG

	PKG-VER.noarch/inst/usr/src/debug/PKG-VER		->
->	PKG-VER.noarch/inst/usr/src/debug/mingw64-*86*-PKG-VER

and similarly for any other subdirectories which would be created with 
package names without mingw64-*86*- prefixes, and then those would have 
to be selectively packaged into dist tars.

If the packaging directory is going to be the same, then the CI build 
job would have to detect the latest push of the mingw-/PKG.cygport and 
initiate the appropriate build.

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