From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtpout2.vodafonemail.de (smtpout2.vodafonemail.de [145.253.239.133]) by sourceware.org (Postfix) with ESMTPS id 2A6483858010 for ; Mon, 28 Dec 2020 18:23:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 2A6483858010 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=nexgo.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=Stromeko@nexgo.de Received: from smtp.vodafone.de (unknown [10.2.0.34]) by smtpout2.vodafonemail.de (Postfix) with ESMTP id 03EFA123CDD for ; Mon, 28 Dec 2020 19:23:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nexgo.de; s=vfde-smtpout-mb-15sep; t=1609179789; bh=AaF/oa6acP93d0U3monC+4jzUhtCJB7qvUswzYdoQnY=; h=From:To:Subject:References:Date:In-Reply-To; b=ZI4RR9rvQbw808sFV7UvQLrTd4aWzmBFdSEojKGSBaGEseAWTSwZCCV7YaZtDPuy/ iEr3DOiT1oGGUGrvETqxo5dS5fo1kwa/WYJNTqRXRJ93NXFwnncTTPqgnNziLIzEIc jE4kIqo9w3moGKGqLHR9IdXR7sXkKHFG316lh/g4= Received: from Gertrud (p54a0ca05.dip0.t-ipconnect.de [84.160.202.5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (2048 bits)) (No client certificate requested) by smtp.vodafone.de (Postfix) with ESMTPSA id 8554814108B for ; Mon, 28 Dec 2020 18:23:08 +0000 (UTC) From: Achim Gratz To: cygwin-apps@cygwin.com Subject: Re: [RFC] cygport mingw.cygclass References: <2e2ce3ce2cb56200f583341bb5c15a61aff27a33.camel@cygwin.com> Date: Mon, 28 Dec 2020 19:23:05 +0100 In-Reply-To: <2e2ce3ce2cb56200f583341bb5c15a61aff27a33.camel@cygwin.com> (Yaakov Selkowitz's message of "Mon, 11 May 2020 12:13:26 -0400") Message-ID: <87ft3paiye.fsf@Rainer.invalid> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate: clean X-purgate-size: 2853 X-purgate-ID: 155817::1609179788-00003440-C2775F4C/0/0 X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham 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: Mon, 28 Dec 2020 18:23:12 -0000 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=E2=80=A6 > 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 tar= get multiple cross-architectures from the same package source. Regards, Achim. --=20 +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada