From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from omta002.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33]) by sourceware.org (Postfix) with ESMTPS id EAEB6385803B for ; Mon, 1 Nov 2021 18:47:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EAEB6385803B 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 shw-obgw-4001a.ext.cloudfilter.net ([10.228.9.142]) by cmsmtp with ESMTP id hcKamyzBZps7PhcKrm6Uax; Mon, 01 Nov 2021 18:47:09 +0000 Received: from [192.168.1.105] ([68.147.0.90]) by cmsmtp with ESMTP id hcKqmwLmgXoZRhcKrmKtOY; Mon, 01 Nov 2021 18:47:09 +0000 X-Authority-Analysis: v=2.4 cv=R8NgpfdX c=1 sm=1 tr=0 ts=6180362d a=T+ovY1NZ+FAi/xYICV7Bgg==:117 a=T+ovY1NZ+FAi/xYICV7Bgg==:17 a=IkcTkHD0fZMA:10 a=dmHZjv3itQn-puC8Rb8A:9 a=QEXdDO2ut3YA:10 Reply-To: cygwin-apps@cygwin.com To: cygwin-apps@cygwin.com References: <87y267zvqp.fsf@Rainer.invalid> From: Brian Inglis Organization: Systematic Software Subject: Re: Dropping various support in future releases - what about Mingw? Message-ID: <6a075655-7038-e3ae-8beb-a184600c1265@SystematicSw.ab.ca> Date: Mon, 1 Nov 2021 12:47:08 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <87y267zvqp.fsf@Rainer.invalid> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-CA Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4xfLG0p12CzWil8yZFKifwNNcZmNWYorKfNy3slhcc6g2HWgytdcJuxygXFDmgc/nlGv+K8qvfK5s4hTRVvgdtfF0ikFFx4geK+G4XH1p76tgnxcOFjFqm 7BpaBq7DY71puk4lJkNZAnb3Z6SjZbWPCOZA+ujO1gWfRl0UeyGVy/h5XR0cciRiQ9ebMg9luhMjj4/pINNtzArkCboVA7FPVxk= X-Spam-Status: No, score=-1160.3 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, LIKELY_SPAM_BODY, NICE_REPLY_A, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Mon, 01 Nov 2021 18:47:11 -0000 On 2021-11-01 10:27, Achim Gratz wrote: > Brian Inglis writes: >> Perhaps someone could explain why Cygwin maintains, builds, and >> distributes Mingw tools and libraries, instead of that being done by >> the Mingw project(s) about which I know little? > > MinGW is not a distribution, so there is no such source. > >> As we will be dropping Windows versions and 32 bit support in future >> releases, should we also be looking at dropping the Mingw packages we >> maintain, build, and distribute, but do not appear to use, except for >> building other Mingw packages? > > In general the MingW packages in Cygwin are used (or were planned to be > used) as dependencies for other stuff that Cygwin builds or uses, like > setup.exe or cross-compilation toolchains. There are undoubtedly > instances where this is not the case or even never was, but those could > be dropped anytime if it presents too much of a burden. Are they actually being used for anything, in this Cygwin project, or the associated Mingw or Wine projects, or are they holdovers from some earlier RedHat project? They appear to duplicate the Fedora packages, so who is using which package builds? >> Supporting the two Mingw variations on packages sometimes takes as >> much work as the Cygwin packages, as parts of the toolchains and >> libraries may have different versions and dependencies. >> >> I basically build, check, and distribute those, but know little about >> using them to check they work, so no idea whether they work or not. > > So? I support packages I use, or libraries used by those packages, as I can dogfood them before release. I am uncomfortable that I can not do so to test the Mingw devel packages I upgrade with their Cygwin equivalents, and know so little about their potential uses. >> I have had little success in getting the Mingw dual arch build process >> working to any useful extent, and no response to questions about that, >> which I may have buried at the end of my other verbiage on this list. > > Not sure what you are talking about. Anything MingW is always cross-compiled, > so if one architecture works, then the other does as well (modulo bugs > and differences in installed packages). I mean the Mingw packages are sufficiently different from the Cygwin packages that they are effectively another different package, but requiring two separate cygport files. I try to maintain all cygport files in sync using gvimdiff to reduce the maintenance burden and increase similarities and synergies at the cost of some commenting out and readability. The inherit mingw cygclass intended to allow Mingw packages to be built like Cygwin packages using the same cygport for both arches, and not require two additional cygport files, two git-cygwin-package repos, etc. It appears to work okay up to the compile but not install, package, etc. cygport stages. -- 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.]