Re: newlib build machinery

[Jeff Johnston <jjohnstn at redhat dot com>]

Ralf Wildenhues wrote:
> 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.
>
>   

Ok, I have added the comment and made the change to Makefile.am.
> > > 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.
>
>   

It would be simpler to copy override.m4 over so I can avoid an 
additional directory specifier for each aclocal, but in my initial 
experiment I specified -I ../config and the aclocal.m4 referenced: 
depstand.m4, lead-dot.m4 and override.m4 from the config directory.  If 
it is highly recommended to use the config directory, then I guess I'll 
do so.  In either case, do I need to remove confsubdir.m4 if we are 
using override.m4?

Regards,

-- Jeff J