Re: Copying vs m4_including macro files

[Alexandre Duret-Lutz]

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.

  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).

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 presume the main drawback is that not building these configury files
  makes it harder to distribute these subdirectories?

> 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.

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.

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?


[*] 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.