* [RFC] cygport mingw.cygclass @ 2020-05-11 16:13 Yaakov Selkowitz 2020-12-28 18:23 ` Achim Gratz 0 siblings, 1 reply; 6+ messages in thread From: Yaakov Selkowitz @ 2020-05-11 16:13 UTC (permalink / raw) To: cygwin-apps 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] cygport mingw.cygclass 2020-05-11 16:13 [RFC] cygport mingw.cygclass Yaakov Selkowitz @ 2020-12-28 18:23 ` Achim Gratz 2021-06-20 15:54 ` Brian Inglis 0 siblings, 1 reply; 6+ messages in thread From: Achim Gratz @ 2020-12-28 18:23 UTC (permalink / raw) To: cygwin-apps 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] cygport mingw.cygclass 2020-12-28 18:23 ` Achim Gratz @ 2021-06-20 15:54 ` Brian Inglis 2021-06-20 18:50 ` Brian Inglis 0 siblings, 1 reply; 6+ messages in thread From: Brian Inglis @ 2021-06-20 15:54 UTC (permalink / raw) To: cygwin-apps 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.] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] cygport mingw.cygclass 2021-06-20 15:54 ` Brian Inglis @ 2021-06-20 18:50 ` Brian Inglis 2021-06-20 19:00 ` Brian Inglis 0 siblings, 1 reply; 6+ messages in thread From: Brian Inglis @ 2021-06-20 18:50 UTC (permalink / raw) To: cygwin-apps 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.] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] cygport mingw.cygclass 2021-06-20 18:50 ` Brian Inglis @ 2021-06-20 19:00 ` Brian Inglis 2021-06-23 5:19 ` Brian Inglis 0 siblings, 1 reply; 6+ messages in thread From: Brian Inglis @ 2021-06-20 19:00 UTC (permalink / raw) To: cygwin-apps 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.] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] cygport mingw.cygclass 2021-06-20 19:00 ` Brian Inglis @ 2021-06-23 5:19 ` Brian Inglis 0 siblings, 0 replies; 6+ messages in thread From: Brian Inglis @ 2021-06-23 5:19 UTC (permalink / raw) To: cygwin-apps 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.] ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-06-23 5:19 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-05-11 16:13 [RFC] cygport mingw.cygclass Yaakov Selkowitz 2020-12-28 18:23 ` Achim Gratz 2021-06-20 15:54 ` Brian Inglis 2021-06-20 18:50 ` Brian Inglis 2021-06-20 19:00 ` Brian Inglis 2021-06-23 5:19 ` Brian Inglis
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).