From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) by sourceware.org (Postfix) with ESMTP id 076E43851C01 for ; Wed, 26 Jan 2022 10:18:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 076E43851C01 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gentoo.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gentoo.org Received: by smtp.gentoo.org (Postfix, from userid 559) id 8745E343190; Wed, 26 Jan 2022 10:18:58 +0000 (UTC) Date: Wed, 26 Jan 2022 05:19:02 -0500 From: Mike Frysinger To: "R. Diez" Cc: joel@rtems.org, Newlib , Matthew Joyce Subject: Re: Question about autoreconf to regenerate configuration files Message-ID: Mail-Followup-To: "R. Diez" , joel@rtems.org, Newlib , Matthew Joyce References: <26fff1a3-7743-e0ce-f7a6-70b39a030118@embedded-brains.de> <41deefa7-d1ae-18f2-6a8e-25e002d85ed6@yahoo.de> <2bc01390-3a5b-fd2d-822c-c4cd9a96f744@yahoo.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="XYtnT0V0gnIN6err" Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: newlib@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Newlib mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2022 10:19:00 -0000 --XYtnT0V0gnIN6err Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 23 Jan 2022 17:57, R. Diez wrote: > > Mike Frysinger wrote: > > [...] > > there is only one set of top-level files. they get manually synced from > > gcc to the other projects by devs who notice & need the fixes. >=20 > OK, I gather that copying those files across from GCC is the standard pra= ctice. > But why do we need to keep doing that in Newlib? According to the (outdat= ed) > cross toolchain build instructions, when combining the tree the GCC versi= ons should prevail. i don't understand what you're asking. the top-level provides files that newlib uses. they need to be kept up-to-date. see AC_CONFIG_AUX_DIR use throughout the tree. > It is not like anybody would take Newlib without GCC and use those top-le= vel files (the > 'configure' script) to build say just Newlib and Binutils, is it? why not ? i have a gdb/binutils dir that i link just newlib & libgloss into. the GNU simulator is part of those trees, and it pulls ABI info out of newlib & libgloss. being able to iterate on those parts without rebuilding gcc is helpful. > >> My guess is that GCC's build system is calling 'configure', > >> 'make' etc. inside newlib/, and it does not really matter > >> if the versions are a little different. > >> Or is a lot of the build system really shared? >=20 > > Joel Sherrill wrote: > > Based on how we always build, I'd say it is just invocation. >=20 > > Mike Frysinger wrote: > > the contract at build time is `./configure`, and even if newlib had its= script > > generated with an old version of autoconf, it doesn't really change the= API. > > the top-level Makefile knows to `cd newlib && ./configure ...` and that= will > > work regardless of the autoconf version. >=20 > There seems to be consensus that the Autoconf version in Newlib does not = matter, > and that the "combined tree" building system interface is just invoking '= configure' and 'make' under newlib/. >=20 > Why do we need to fix the Autoconf version to 2.69 then? We could use the= newer 2.71 for Newlib. the top-level config/ pins to that version. it also contains macros we uti= lize (like the multilib logic). if no one else is testing newer versions, it so= unds like pointless landmines for newlib. conversely, what does autoconf 2.71 get us ? i'm not aware of functionalit= y in there that we need or otherwise fixes/improves things for newlib specifical= ly. > How about the Automake version? The Automake version is not checked like = the > Autoconf version is, isn't it? The checked-in "Makefile.in" files were ge= nerated > with Automake 1.15.1 from 2017-06-19, and the latest is 1.16.5 from 2021-= 10-03. >=20 > If we want to strictly keep in sync with GCC, shouldn't we check the exac= t Automake version too? we pin the min version via AM_INIT_AUTOMAKE to 1.15.1. you're right we don= 't currently pin the maximum, it's more through everyone agreeing to use that version. if gcc et al had a macro to pin the automake version, we'd prob leverage it too. pinning the versions in general is meant to keep generated noise/conflicts down between devs working on these projects, and to make expectations more obvious to users. if diff devs were using autoconf 2.68 & 2.69 to regen and push changes, there would be a ton more noise, and conflicts would be a lot more frequent when pulling git updates. users tend to not be savvy with autotools ... they just run whatever until things compile. getting support requests like "i tried to run autoconf-2.50 and it didn't work" (or conversely, "i tried to run autoconf-2.100 and it didn't work") is a waste of valuable dev time. putting "we used xxx versions" into README files has historically proven to be insufficient. > > Mike Frysinger wrote: > > the multilib multiplexing logic with libraries makes things a bit messi= er too. >=20 > Does the multilib multiplexing logic affect the interface between the com= bined > tree build system and Newlib? Or does it require something special inside= newlib/ > that would conflict with newer Autotools versions? gcc's multilib logic expects a certain layout that newlib provides, and thi= s is simplified by using the same multilib configure+make logic. this is space = that hasn't really been documented anywhere that i'm aware of, and can sometimes= be a bit fragile. i've run into this at various times with diff targets and w= hen maintaining toolchain packages in distros. -mike --XYtnT0V0gnIN6err Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEuQK1JxMl+JKsJRrUQWM7n+g39YEFAmHxIBYACgkQQWM7n+g3 9YFW+A//WDbukp1IoYXFWKpCaLOzPpQeZvq55emVjtz3FlMjC7fuBTD6M4rz4PGT XTi3lLjvANvX93mH+xWFChhv9vKybwhPK0rlocbWhwKeU7BHrUryjRbBhrkdQvUt 8wxheyJiyVuGCFNfDjv28OU4pxsRkn5MKnb3zYXp6HCX7TDQ/IVBInDrdbUSi8zY p2x47z2qWo4kRJo38AYVjPfZYtCpWsjfWII2TZwKq2u7CCmN0k77BTf1Y7SJB5AJ wNhoEE+09IElwOuz/8sBRqmRTXg9c8URvaeVk9BIlLTHUKViQJ0qMzapsJeaENzZ /RQPbB/wOZ4xV9b4VDQH9iuWtp1MYMJ2vtbe20R3MuilaaSiEHApZukEdMkMyOaf ZMKx326/z93chYpX3rIQzIChpGTwDXSdOLtjdEZZCbx7vUgzLv8klF5m7FUD+WLh jNZTwlTBdZonPpJgarnmHsodrH6EZDFd9/oh7umLlPjoknZb7hXIZR3dtjYiag5A 7EzG2/oRsXUf2DUIkwzlpVWRQRJbNRi3fvGsKMIb6IbpPlj8vgxNuIn8N8QLYlFZ DFOTARuGfCX3gkZy96mZkFxGXJWK2Cm1Kmx0lWSZUzWgJRW68jO6QtsBqgYAnAoK AFkOZ7Mne0q6IuBoQxv9LcKa3B2B7PURlJS5c1I+ihmCjqQPDc0= =NqMP -----END PGP SIGNATURE----- --XYtnT0V0gnIN6err--