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. > > A very long bootstrap time could be an issue. > > However, compilation time normally outweighs by far the Autotools regeneration 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=bfin-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 the concrete issues in the context of this project, and not just some general "all solutions in this area seem to suck" justification. again, this isn't "just newlib". newlib is part of the historically combined toolchain tree/ecosystem. that means you can take binutils, gdb, gcc, newlib, 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 they have diff git repos, but the top-level dir and a few subdirs are still shared, 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 usually if you can convince gcc to change, the rest will follow to keep things simple. 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