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