Question about autoreconf to regenerate configuration files

[Joel Sherrill]

On Fri, Jan 21, 2022 at 4:09 PM Mike Frysinger <vapier@gentoo.org> wrote:
>
> 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
> <this errored out, not sure why, so it might normally take even longer :p>
>
> # 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.

This is on the order of what we saw using autotools with RTEMS.

> > 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.

Sorry. I meant that more as all build systems have tradeoffs. You just
have to be conscious of the pain points and who incurs them.

>From an RTEMS use case, all our users build tools from source with
something similar to BSD ports. These fetch source and apply patches.
We rarely use the newlib release tarballs and track from git.

I built an aarch64 toolchain yesterday and it tool about 25 minutes on my
laptop. It's a 2.87Ghz i7 with 4 real cores. It's a few years old and
far from the
fastest but still faster than what I see user with when I teach RTEMS classes.
This would add 5 minutes to that since I assume we can skip libgloss as
we don't use it.

If newlib goes to needing a bootstrap process, RTEMS will adjust. The question
is how many newlib users get binaries and how many build it themselves.
The burden goes on newlib developers, tool distributors, or end users building
from source.  This is something for the newlib community to decide

> 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.

That's all I was trying to point out. Every build system and approach to using
it has advantages and disadvantages.

> -mike