newlib build machinery

[Ralf Wildenhues]

Hello Jeff,

* Jeff Johnston wrote on Tue, Aug 18, 2009 at 09:54:16PM CEST:
> Ralf Wildenhues wrote:
> >1) newlib.hin is apparently written manually, [...]

> I just updated the acconfig.h file to handle the missing templates,
> but manual editing is needed because newlib cannot generate
> PACKAGE_NAME, etc.. in newlib.h and AC_INIT does so under the
> covers.  The newlib.h header file is included internally by the
> standard header files and so we don't want to clash with a user's
> header file which also wants to define PACKAGE_NAME, etc...  So, I
> originally used autoheader then deleted those offending lines
> manually.  Later changes just edited the newlib.hin file directly.
> If there is a cleaner way to do this, I'm all ears.

Well, one definite improvement would be, if you edit newlib.hin
manually, to prominently state so at the beginning of the file,
and to add a no-op rule for newlib.hin in Makefile.am to prevent
the automake-generated rule from accidentally overwriting the file.

> >2) The newlib tree already uses differing versions of autoconf and
> >automake for various of its files.  Is that all by accident or was it a
> >conscious decision?
> >
> I tend to stay away from new autoconf/automake as they have caused
> breakage in the past when updating and newlib is more interested in
> things continuing to work the way they did before, rather than
> exercise new features.  So , it is part accidental.

Understood.

> >3) The macros from toplevel src/config/ are not used, esp. override.m4,
> >which is crucial in allowing a smooth upgrade and working around bugs in
> >Autoconf.  Is that not-use a conscious decision, and if yes, are there
> >reasons to keep it that way (e.g., a need to build independently of the
> >src/ tree), and if yes, which way should I go?

> It is not a conscious decision.  Would this solve the very annoying
> check for changes in compile flags which  doesn't handle ignoring
> white-space differences?

Yes, it would; as would an update to a newer autoconf.  We do also fix
bugs in newer versions, instead of only introducing new ones!  :-)

Seriously though, override.m4 is currently the lever to

- force exactly one Autoconf version for all configure scripts that
  include this file,
- fix all Autoconf bugs known to the version used,
- and used throughout GCC and binutils, and parts of gdb already.

This also means that, while there are likely more bugs exposed by
updating to new tools now, it's also easy to fix them throughout the
tree (and there are more likely people able to fix them for you).  In
that way, it's at least debatable which version to use will be better
for you; but you decide.

Cheers,
Ralf