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 F390D3858C60 for ; Fri, 21 Jan 2022 22:09:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org F390D3858C60 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 0E75934340C; Fri, 21 Jan 2022 22:09:34 +0000 (UTC) Date: Fri, 21 Jan 2022 17:09:37 -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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wCM0VzfS2StZsg7Z" Content-Disposition: inline In-Reply-To: <41deefa7-d1ae-18f2-6a8e-25e002d85ed6@yahoo.de> X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_PASS, 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: 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: Fri, 21 Jan 2022 22:09:37 -0000 --wCM0VzfS2StZsg7Z Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 21 Jan 2022 17:09, R. Diez via Newlib wrote: > > [...] > > The bootstrap time was large enough to > > negatively impact our ability to do automated regression testing. >=20 > A very long bootstrap time could be an issue. >=20 > However, compilation time normally outweighs by far the Autotools regener= ation step. Is that a problem in Newlib at the moment? autotools (autoreconf really) doesn't run in parallel, so every subdir with a configure script needs a separate serialized run of all the tools. newlib has many many of these (arguably, too many). on my quad core 4.2GHz AMD that is otherwise idle ... $ time (cd newlib && autoreconf) real 5m22.170s user 3m13.709s sys 0m12.332s $ time (cd libgloss && autoreconf) real 1m41.754s user 0m43.505s sys 0m3.618s # Blackfin builds 8 copies (multilib) of newlib+libgloss by default. $ time (cd build; ../configure --host=3Dbfin-elf; make -j4) real 1m40.950s user 0m58.032s sys 0m30.968s so yeah, autotools generation here is significant. > If Newlib wishes to depart from best practice, it would be nice to know t= he concrete issues in the context of this project, and not just some genera= l "all solutions in this area seem to suck" justification. again, this isn't "just newlib". newlib is part of the historically combin= ed toolchain tree/ecosystem. that means you can take binutils, gdb, gcc, newl= ib, libgloss, cgen, sim, zlib, etc... and have a single monolithic source tree = and build them all at once. the projects have separated a little bit in that t= hey have diff git repos, but the top-level dir and a few subdirs are still shar= ed, and some folks still hand merge them. newlib is part of that ecosystem and= as such, follows its conventions. changing newlib behavior would have a ripple effect and is why consensus across all of them is desirable. although usua= lly if you can convince gcc to change, the rest will follow to keep things simp= le. i'm not advocating for this system, but i understand the trade-offs, and it= 's been around longer than i've been a programmer. -mike --wCM0VzfS2StZsg7Z Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEuQK1JxMl+JKsJRrUQWM7n+g39YEFAmHrLyAACgkQQWM7n+g3 9YGC9g/+PEH5eTdIiO4W6Wm3OlWYwXLajlDZkK7E4gFfuCNhVeOaq8siphesb4MR NbR1y9wus7aeB9j4TMSUymougSGgZMPT8skUeuv7q64hq6xproo23lTHOoLaTnOz UXk4GehWwOJDMc77JKnnxf4p7XApaeRsXeJTzWb/TnoFJbnWBN8gsscuo+9yYN0A iVA8l4c90qHbD21Aa72vmzOH5K7foDPTfPPltB5D8v6aN9QWYJ+zmbMZwfNLhLoy P/OiKBirzl7kbyV57RR9lK9YG+U7zNIm4FIEEFaH5hM7gVRqco6HMtBIE+DzPKFm zEePwAFlSMZEOMpDL1qe5TNnPlJOV4tJ8kXlMnzpCoQbd547LrP8RKawpyamNbXp d1EA7wkCIW5Ju+LJIjM3WX3Z4zPpzxZxvsBSdnQ1HuZ8NmWRNfUBB2UsoIUTPuup eQfKfyKE/SQicxbfcxr7q7T31SYTPuKuW8ym2idCqU2iI55H/A+zDZC0it69KWNs +KJbYehOPR3MuMKdVceluolrmzmxQBKziMvA0xe4gP9XwMU57jy2QsYvdDM0jqJU rZH8GgEAFmUhT7z1Dzkec7PAI5SCYyUPU4wR7X67ZRLM4APIsqNS/ws1yXFjGXKc fhzXDVQBo1jysSQp/7gydhy8wVVaGrrrppY+P4bFVjeqNFEqXkg= =MdrO -----END PGP SIGNATURE----- --wCM0VzfS2StZsg7Z--