Re: Copying vs m4_including macro files

[Gary V. Vaughan]

Alexandre Duret-Lutz wrote:
> On Mon, Sep 22, 2003 at 06:12:50PM +0100, Gary V. Vaughan wrote:
> [...]
>
> > I was hoping to remove acinclude.m4 and use m4_include in aclocal.m4 by
> > switching to CVS automake, but currently the contents are still copied to
> > aclocal.m4 if they are not in the same directory as configure.ac.  Wherever
> > I put libtool.m4, 8 sibling directories still get a copy of the macros
> > instead of an m4_include.
>
>
> Idea 1:
>   Do not use aclocal.m4 in these subdirectories.  Simply add
>   m4_include([../aclocal.m4]) and maybe m4_include([../ltdl.m4])
>   at the top of all these configure.ac.

Not an option since all of the automake macros need to be copied in for 
configure.ac to be expandable to a working configure script :-(

>   Or alternatively you can build your own aclocal.m4 containing these
>   one or two statements.  Simply do not run aclocal.  Automake
>   contains code to disable the rebuild rule for aclocal.m4 when it
>   hasn't been generated by aclocal (I'm not sure how well tested this is,
>   but if it doesn't work this is certainly something we should fix).

Same problem here: aclocal knows about the macros it needs to pull in (aside 
from libtool.m4 and ltdl.m4) so that the other autotools can be run.

> Idea 2:
>   Since most of these subdirectories are used by the test suite, maybe
>   it could make sense to build configure/aclocal.m4/Makefile.in/etc.
>   on the user's host with the installed tool.  Using a wider range of
>   tools versions is likely to help to catching incompatibilities.

I want users of m4 to be able to `make check' without having the autotools 
chain installed.

>   I presume the main drawback is that not building these configury files
>   makes it harder to distribute these subdirectories?

That's true, but I'm worried about the testsuite not running at install time, 
and about dragging 21 200k copies of libtool.m4 around in the tarball. 
Actually acinclude.m4 isn't needed with aclocal-1.7a, so I can reduce it to 11 
copies now.  Also it is easier to check that the correct libtool.m4 is being 
used by autoconf when aclocal.m4 can m4_include([../libtool.m4]), than when 
the entire contents are copied into aclocal.m4.

> > I think that it is wrong for aclocal to copy macros from AC_CONFIG_AUX_DIR
> > directories, if the directory is listed there, then that directory will
> > need to be shipped, or `make dist' won't work. If the directory is shipped,
> > then it is okay for aclocal to m4_include files from it.
>
>
> I agree, but I also think we shouldn't incite users to lump .m4 files
> with auxiliary build tools.  Many projects have separate m4/ and
> tools/ (or config/ or aux/, pick your favorite) directories, so it
> would be better if we can solve this problem without merging these
> directories.

Good point.  Aside:  You can't use a file or directory called AUX (or COM for 
that matter) on FAT32 filesystems!!

> Maybe we could simply revisit the way aclocal decides whether a macro
> is local.  Right now paths starting with /, c:/, ./../, or ../ are not
> considered local.  But most of the time ./../* and ../* files _are_
> distributed.  I don't know how frequent it is that people use `aclocal
> -I ../somedir' to build aclocal.m4 and yet do not distribute
> ../somedir.  Maybe we should consider ./../* and ../* files as local,
> and let people write `aclocal -I `pwd`/../somedir' when it is untrue.

It is definitely wrong (from a "don't hide files from the user" point of view) 
to not ship special macros needed by configure.ac, as the user will never be 
able to regenerate the build files from the dist tarball.  Therefore I think 
it is fine to consider relative directories specified with -I to be project local.

> Alternatively we could take any leading `./' as an indication that
> the files should be local, so that one would just write
> `ACLOCAL_AMFLAGS = -I ./../m4' instead of `ACLOCAL_AMFLAGS = -I ../m4'
> when ../m4 is to be considered local.  Any opinion?

That feels like a hack.  There are better ways to do it.

> [*] BTW, I recall a discussion with Akim (not sure it was done on a
> mailing list) about a future version of aclocal (actually we were
> talking about an Autoconf-supplied equivalent) which should copy third
> party macros from /usr/share/aclocal/ to a directory local to the
> project before m4_including them from aclocal.m4.  The question was in
> which directory should these files be copied, and the answer was we
> needed an AC_CONFIG_M4_DIR macro to specify this.  Maybe it's time to
> introduce this macro.  Even though .m4 files would not be copied yet,
> it would be useful to hint aclocal that a directory should be
> considered local, without constraining people to use aux_dir for .m4
> files.

I've touched upon the same subject with Akim.  Infact he prototyped the idea 
with make rules in CVS m4 a couple of years ago :-)  I think that it is a fine 
goal.  Actually, developing Autoconf, Automake and Libtool in their own 
packages makes less and less sense as their interdependencies grow.  One day 
I'd like to see a combined Autotools development and distribution...

I think AC_CONFIG_M4_DIR as you describe it above is the correct solution, and 
since CVS automake already requires CVS autoconf, there is no reason not to 
put a dummy definition in CVS autoconf.  Only the people who want to use the 
feature will need to ensure they upgrade autoconf and automake in synch.

The autoconf part of this feature is trivial (I can provide a patch if that's 
useful), but I suspect I'd need to be able to write perl to implement the 
aclocal end :-)

Cheers,
        Gary.
--
  ())_.  Gary V. Vaughan    gary@(lilith.warpmail.net|gnu.org)
  ( '/   Research Scientist http://www.oranda.demon.co.uk       ,_())____
  / )=   GNU Hacker         http://www.gnu.org/software/libtool  \'      `&
`(_~)_   Tech' Author       http://sources.redhat.com/autobook   =`---d__/