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.139]) by sourceware.org (Postfix) with ESMTPS id 103D6385800A for ; Sun, 20 Jun 2021 18:50:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 103D6385800A 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 v2WallzyIiLmnv2WblWEVL; Sun, 20 Jun 2021 12:50:30 -0600 X-Authority-Analysis: v=2.4 cv=W+Nb6Tak c=1 sm=1 tr=0 ts=60cf8df6 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 Reply-To: cygwin-apps@cygwin.com Subject: Re: [RFC] cygport mingw.cygclass To: cygwin-apps@cygwin.com References: <2e2ce3ce2cb56200f583341bb5c15a61aff27a33.camel@cygwin.com> <87ft3paiye.fsf@Rainer.invalid> From: Brian Inglis Organization: Systematic Software Message-ID: <0dc2c9c4-1185-3193-dc5e-558bd218c5ea@SystematicSw.ab.ca> Date: Sun, 20 Jun 2021 12:50:28 -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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-CA Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4xfIx8bqQHtleIZbeD/g9PWTD8Cny26MK98woZeAGLjwgIQ/ZQrUFznUBNQaCu1u5S0sOXYp3HYmLSfzjGXOmfHX4JqdsXOyVpSzLBDWoeyISa2B24jOzp meGsDwSXn5OnRkYIx7Smnkc/PagOUKXnUBXKGUEDFMZiYbbmaY1IGgsQseVYLR3RmVoYrIK6Ck98OlFVxZ72zvk9DSWGg9cOYz4= X-Spam-Status: No, score=-3487.9 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 18:50:33 -0000 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. -- 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.]