libcpp's aclocal.m4 regeneration question. Also is it time for a toplevel "m4" directory?
Zack Weinberg
zack@codesourcery.com
Mon Aug 23 15:54:00 GMT 2004
Kelley Cook <kcook@gcc.gnu.org> writes:
> What are the steps required to regenerate libcpp's aclocal.m4?
On a current Debian unstable box,
$ cd libcpp
$ aclocal-1.8 -I ../config
produces an aclocal.m4 which is identical to the one currently checked in.
The reason there is no m4/ nor acinclude.m4 is, everything comes from
../config or from /usr/share/aclocal.
> When testing whether the entire tree could be upgraded to automake
> 1.9.1, I get errors regarding numerous missing gettext macro's when
> attempting to regenerate aclocal within libcpp.
I will take this opportunity to remind Paolo Bonzini that his
move-cpp-to-toplevel patch was only approved on condition that he
write a proper hand-written Makefile for it in short order. That was May.
> Since there is neither an m4 directory nor an acinclude.m4 within
> libcpp, I've concluded that aclocal.m4 was either handcrafted or there
> was an included directory on a developer's systems that was not checked
> into the tree. One thing that leads me to believe that the latter is
> true is that some of the macros are from gettext 0.13, but we only have
> a libintl 0.12 our the tree (FWIW, the current gettext's libintl is 0.14.1)
Updating to a current libintl would be a Good Thing, but take care:
the build harness from upstream was thrown away and replaced with
something sensible. Also, note that src is still out of sync.
> Also now that we are moving to automake 1.9, shouldn't we be split out
> all the extra macros we use into individual files within a toplevel m4
> directory as the automake people recommend? The generated aclocal and
> configure would become very small if we were to follow that advice.
Yes, I think that would be a good move.
zw
More information about the Gcc
mailing list