Question about autoreconf to regenerate configuration files

[R. Diez]

> [...]
> We do thia one tree style.

Combining the repositories has drawbacks. Mixing things at least increases chances for confusion.

What are the advantages of using the "combined tree" versus separate directories?

With a "combined tree", do you still need to build GCC in 2 phases, or can you do it in one pass?

My first thought is that a "combined tree" may allow for more parallelism when building, but my makefile already builds all components in parallel too. The components of the toolchain I am building are:

Binutils
GMP
MPFR
MPC
GCC
Newlib
GDB

Binutils, GMP, MPFR and MPC probably need to be completely built before the GCC cross-compiler, so the "combined tree" is not going to paralellise that.

GDB needs MPFR and GMP, but does not need the GCC cross-compiler, for it is a host-based tool.

Therefore, at first sight, it looks like a "combined tree" may only increase parallelism when building GCC with an integrated Newlib, as opposed to building Newlib completely before building GCC. But I wonder if the "combined tree" build system serialises those steps (building GCC and building its Newlib) anyway.

In any case, there may be an advantage of combining the GCC and Newlib source trees, but I cannot see yet how that could benefit the other components.


> [...]
> We move or symlink the newlib/ directory under the top GCC directory.

Just the newlib/ directory? That means that top-level files in the Newlib Git repository, like 'configure' next to newlib/ and libgloss/ , are not used at all for your builds.

Consider top-level file README, which starts like this:

"This directory contains various GNU compilers, assemblers, linkers,
  debuggers, etc., plus their support routines, definitions, and documentation."

This file does not seem to come from Newlib. Why do we need it in Newlib?

The "combined tree" instructions on this page:

https://gcc.gnu.org/wiki/Building_Cross_Toolchains_with_gcc

state the following:

"with the GCC files overriding the binutils/gdb/newlib files when there's a conflict."

But the way you are symlinking just "newlib/" does not create any conflicts, does it?

By the way, are you aware of any public full example (a script or makefile) somewhere which I could use as a reference for creating and building with a combined tree?


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

OK, I gather that copying those files across from GCC is the standard practice. But why do we need to keep doing that in Newlib? According to the (outdated) cross toolchain build instructions, when combining the tree the GCC versions should prevail.

It is not like anybody would take Newlib without GCC and use those top-level files (the 'configure' script) to build say just Newlib and Binutils, is it?


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

> Joel Sherrill wrote:
> Based on how we always build, I'd say it is just invocation.

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

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

Why do we need to fix the Autoconf version to 2.69 then? We could use the newer 2.71 for Newlib.

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 generated with Automake 1.15.1 from 2017-06-19, and the latest is 1.16.5 from 2021-10-03.

If we want to strictly keep in sync with GCC, shouldn't we check the exact Automake version too?


> Mike Frysinger wrote:
> the multilib multiplexing logic with libraries makes things a bit messier too.

Does the multilib multiplexing logic affect the interface between the combined tree build system and Newlib? Or does it require something special inside newlib/ that would conflict with newer Autotools versions?


Thanks for the information,
   rdiez

-- 
rdiez