This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: libcpp's aclocal.m4 regeneration question. Also is it time for a toplevel "m4" directory?
- From: Kelley Cook <kcook at gcc dot gnu dot org>
- To: Zack Weinberg <zack at codesourcery dot com>
- Cc: GCC Mailing List <gcc at gcc dot gnu dot org>, Paolo Bonzini <bonzini at gnu dot org>
- Date: Mon, 23 Aug 2004 13:52:14 -0700 (PDT)
- Subject: Re: libcpp's aclocal.m4 regeneration question. Also is it time for a toplevel "m4" directory?
- Reply-to: kcook at gcc dot gnu dot org
--- Zack Weinberg <zack@codesourcery.com> wrote:
> 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.
Yes, but this is because your /usr/share/aclocal likely contains a few
macros from your system's already installed gettext (which is later
than 0.12). Specifically the included lib-ld.m4 which is from a newer
version of gettext than the fragment of 0.12.1 that is already included
with GCC's sources.
IMO, we should import all of GCC's required gettext macros into the
toplevel config (or m4) directory.