This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
libcpp's aclocal.m4 regeneration question. Also is it time for atoplevel "m4" directory?
- From: Kelley Cook <kcook at gcc dot gnu dot org>
- To: GCC Mailing List <gcc at gcc dot gnu dot org>
- Cc: Paolo Carlini <pcarlini at suse dot de>
- Date: Mon, 23 Aug 2004 10:17:50 -0400
- Subject: libcpp's aclocal.m4 regeneration question. Also is it time for atoplevel "m4" directory?
- Hop-count: 1
What are the steps required to regenerate libcpp's aclocal.m4?
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.
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)
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.
Kelley Cook