This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [boehm-gc] Cleanup aclocal.m4 generation [2/2]
- From: Zack Weinberg <zack at codesourcery dot com>
- To: Alexandre Oliva <aoliva at redhat dot com>
- Cc: Kelley Cook <kcook at gcc dot gnu dot org>, Hans Boehm <Hans dot Boehm at hp dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 28 Sep 2004 11:47:35 -0700
- Subject: Re: [boehm-gc] Cleanup aclocal.m4 generation [2/2]
- References: <41585C13.9010807@gcc.gnu.org><or655ykzl2.fsf@free.redhat.lsd.ic.unicamp.br>
Alexandre Oliva <aoliva@redhat.com> writes:
> Until someone goes and installs some .m4 file in the default aclocal
> search path with the same name as what we have in the GCC tree. Then
> aclocal reports a conflict and stops. This used to be the reason why
> I recommended very strongly sinclude to be used over -I. If this
> changed in current aclocal, the change is safe, although it's still a
> bit inconvenient to have to rerun aclocal to bring changes from .. or
> ../config into aclocal.m4, and then rebuild configure. The m4 files
> are already part of our source tree, so we might as well include them
> instead of collecting copies of it all over the place, which only
> increases the risk that someone will edit the copy without realizing
> aclocal.m4 is generated by aclocal.
This strikes me as a strong argument for having aclocal.m4 files which
consist entirely of m4_include directives for files over in ../config,
and which are *not* generated by aclocal, at least not via makefile
rules.
zw