newlib build machinery
Wed Aug 19 11:53:00 GMT 2009
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.
>>> 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
-- Jeff J
More information about the Newlib