[RFC] cygport mingw.cygclass

[RFC] cygport mingw.cygclass

[Yaakov Selkowitz]

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

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.

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

--
Yaakov

Re: [RFC] cygport mingw.cygclass

[Achim Gratz]

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.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: [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.]

Re: [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.]

Re: [RFC] cygport mingw.cygclass

[Brian Inglis]

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

Re: [RFC] cygport mingw.cygclass

[Brian Inglis]

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