From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.137]) by sourceware.org (Postfix) with ESMTPS id C4CD7385800A for ; Sun, 20 Jun 2021 19:00:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C4CD7385800A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=SystematicSw.ab.ca Authentication-Results: sourceware.org; spf=none smtp.mailfrom=systematicsw.ab.ca Received: from [192.168.1.104] ([68.147.0.90]) by shaw.ca with ESMTP id v2fslm0maiLmnv2ftlWErE; Sun, 20 Jun 2021 13:00:06 -0600 X-Authority-Analysis: v=2.4 cv=W+Nb6Tak c=1 sm=1 tr=0 ts=60cf9036 a=T+ovY1NZ+FAi/xYICV7Bgg==:117 a=T+ovY1NZ+FAi/xYICV7Bgg==:17 a=IkcTkHD0fZMA:10 a=LF2dOfbMAAAA:8 a=w_pzkKWiAAAA:8 a=MU4eybcMYzc-gjLx57oA:9 a=QEXdDO2ut3YA:10 a=TmiWL2DCWjWbbQwbIu5r:22 a=sRI3_1zDfAgwuvI8zelB:22 From: Brian Inglis Subject: Re: [RFC] cygport mingw.cygclass Reply-To: cygwin-apps@cygwin.com To: cygwin-apps@cygwin.com References: <2e2ce3ce2cb56200f583341bb5c15a61aff27a33.camel@cygwin.com> <87ft3paiye.fsf@Rainer.invalid> <0dc2c9c4-1185-3193-dc5e-558bd218c5ea@SystematicSw.ab.ca> Organization: Systematic Software Message-ID: Date: Sun, 20 Jun 2021 13:00:04 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <0dc2c9c4-1185-3193-dc5e-558bd218c5ea@SystematicSw.ab.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-CA Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4xfD54re48bJmvACwqihodnv/YKHz993WLI9QG16bN4qSFIOCEYFP+1TwgyOyaj005H8OCC8aaMViuFYbxzhrgJ/hiyVRH//yM8DkACpwsQ3BLby4v73HN EN4jeSomSKB9Rre8aACQ0MQiVjcM0CjNNQfSjmHJhVWuC6cam4wEPC291vPgFuEmnANVHpSom3X8rgcMSkjt0yFmXPPqeaqfuqk= X-Spam-Status: No, score=-3487.8 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin-apps@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Cygwin package maintainer discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2021 19:00:08 -0000 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 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--gcc cross compiler, installed in >> /usr/-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 - 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.]