Re: libcpp's aclocal.m4 regeneration question. Also is it time for a toplevel "m4" directory?

[Zack Weinberg <zack at codesourcery dot com>]

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