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: Zack Weinberg <zack at codesourcery dot com>
- To: Paolo Bonzini <paolo dot bonzini at polimi dot it>
- Cc: Kelley Cook <kcook at gcc dot gnu dot org>, GCC Mailing List <gcc at gcc dot gnu dot org>
- Date: Mon, 23 Aug 2004 23:53:01 -0700
- Subject: Re: libcpp's aclocal.m4 regeneration question. Also is it time for a toplevel "m4" directory?
- References: <4129FC8E.4040909@gcc.gnu.org> <87k6vp3lm9.fsf@codesourcery.com><412AE275.8050407@polimi.it>
Paolo Bonzini <paolo.bonzini@polimi.it> writes:
> Another nice project would be to use aclocal also in directories that do
> not use Automake.
Ya.
> While I agree that splitting macros across several files would be a good
> move, I do not see how it would reduce the size of aclocal.m4 (aclocal
> 1.8.5 already uses m4_include for .m4 files *within the tree*) and,
> especially, of configure scripts.
Well, if *all* the macros defined in *all* the aclocal.m4 files were
moved to config/foo.m4 files, then the aclocal.m4 files would reduce
to just a series of m4_include operations.
You're right that this wouldn't help at all with the size of configure
scripts; there's no way to change that without changing basic design
principles of Autoconf itself (no use of shell functions, no use of
the '.' command).
> Zack: I'm working on the libcpp Makefile now.
Thanks.
zw