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 209683858034 for ; Sun, 20 Jun 2021 15:54:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 209683858034 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 uzmhlljwUiLmnuzmilW7EQ; Sun, 20 Jun 2021 09:54:57 -0600 X-Authority-Analysis: v=2.4 cv=W+Nb6Tak c=1 sm=1 tr=0 ts=60cf64d1 a=T+ovY1NZ+FAi/xYICV7Bgg==:117 a=T+ovY1NZ+FAi/xYICV7Bgg==:17 a=IkcTkHD0fZMA:10 a=LF2dOfbMAAAA:8 a=ejknC5xS72zp2OFXFO8A:9 a=QEXdDO2ut3YA:10 a=TmiWL2DCWjWbbQwbIu5r:22 Reply-To: cygwin-apps@cygwin.com To: cygwin-apps@cygwin.com References: <2e2ce3ce2cb56200f583341bb5c15a61aff27a33.camel@cygwin.com> <87ft3paiye.fsf@Rainer.invalid> From: Brian Inglis Organization: Systematic Software Subject: Re: [RFC] cygport mingw.cygclass Message-ID: Date: Sun, 20 Jun 2021 09:54:55 -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: <87ft3paiye.fsf@Rainer.invalid> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-CA Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4xfGaGyxwS9kd+wLnca7y4cDnM7rZPjlNQOFzOO4lav/uSPqRj3/oxvkznUsvqD096zp0wwA8z5/h0eEd/Rd1sCXcvmsYM/O7O9OsBByTmJpg1sMm5hYsr meNSlq83OgikzvrteiUGswovye/sqI/wjsU9Z0F1cbI9RCO93cMiX7grE0sAd2Vbv/aSREmMd9DYtwpOwIABpUBtfLiI6FKFsjg= 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 15:55:00 -0000 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? -- 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.]