[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Copying vs m4_including macro files

From: Gary V. Vaughan
Subject: Re: Copying vs m4_including macro files
Date: Tue, 23 Sep 2003 15:49:44 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030903 Thunderbird/0.2

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

Not an option since all of the automake macros need to be copied in for 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/
  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

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

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

  ())_.  Gary V. Vaughan    gary@(|
  ( '/   Research Scientist       ,_())____
  / )=   GNU Hacker  \'      `&
`(_~)_   Tech' Author   =`---d__/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]