Re: newlib build machinery

[Jeff Johnston <jjohnstn at redhat dot com>]

Ralf Wildenhues wrote:
> Hello,
>
> I'm ploughing through src in order to update its autotools usage;
> first thing I'm trying is whether current rebuild rules work and
> things are in decent shape.
>
> For now, I see the following issues in the newlib tree:
>
> 1) newlib.hin is apparently written manually, but still, with
> --enable-maintainer-mode, rebuild rules are in place to invoke
> autoheader (which then fails due to missing templates).  Which
> is the desirable mode of operation, autoheader or manual generation
> of the file?  In the latter case, the rebuild rule should be deactivated
> to avoid accidental trigger of the wrong rule.
>
>   
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.
> 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. 
> 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?
> I think minimally, override.m4 needs to be included, since you seem to
> already have confsubdir.m4 in place (hey, I added that! :-).
>
>   
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?
> Thanks,
> Ralf
>