newlib build machinery

[Jeff Johnston]

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