on autolib, --add-missing, and aclocal (Was: Re: Installing COPYING whatever the previous `value')

[Alexandre Duret-Lutz]

>>> "Akim" == Akim Demaille <address@hidden> writes:

 Akim> Hm.  Do you think we should use AC_LIBSOURCE?  Or introduce a new
 Akim> macro, which would ``type'' the files?  

By all means, yes!

 Akim> (I'm thinking for instance that AC_LIBSOURCES should be
 Akim> in AC_CONFIG_LIBDIR).

Yeah.  Something I don't like with AC_LIBSOURCES is that it
isn't tied to a directory.  So Automake has to distribute
anything matching a file listed in AC_LIBSOURCES.  Too
bad if the tree contains two files with the same name.  It would
be nice if there was a smooth way to introduce something like
AC_CONFIG_LIBDIR.

 Akim> Yeah, that would be safer.  Maybe AC_REQUIRE_CONFIG_FILE,
 Akim> AC_REQUIRE_BUILD_FILE or something.

My first though was for AC_AUXSOURCES, for symmetry.  Maybe
SOURCES is confusing.  AC_REQUIRE_CONFIG_FILE looks good; I'd
prefer AC_REQUIRE_AUX_FILE since files go into the AUX_DIR.

Hmmm... s/AC/AL/?

 >> (*) Note that presently these helper scripts are required in
 >> packages where Python or Elisp files are built/installed.  This
 >> is somewhat finer that the simple use of an Autoconf macro.  For
 >> instance I could be running AM_PATH_PYTHON because I need Python
 >> X.Y during the build, and still don't need py-compile.

 Akim> Arg.  Good point.

Note that, at worst, there is an evil way to get rid of --add-missing
and still handle difficult files such as mdate-sh or ylwrap: have Automake
ask the user to call some new macro when these files are needed.

 Akim> Still, at least to simplify our tools, I suggest that we handle the
 Akim> others this way: introduce another macro, and have the proper AC and
 Akim> AM macros require config.*, install-sh etc.

 Akim> OK with you?

Yep.  However, if Automake's going to rely on autolib to install
some files previously installed by --add-missing, Automake will
have to install these files somewhere autolib can find them.

This raises the versioning issue.  Because (1) automake supports
parallel installations and (2) these files can differ from
version to version,

   aclocal-1.8
   autolib

should not install the same files as

   aclocal-1.9
   autolib

Ha ha!  You sure like this.

The same question will come up the day Autoconf replaces aclocal.

As far autolib is concerned, one idea might be to add a macro to
modify the search patch.  For instance Automake 1.8's could
install its files in /usr/share/autoconf/autolib/automake-1.8/
and AM_INIT_AUTOMAKE would call AL_SEARCH_PATH([automake-1.8]).

Regarding an aclocal replacement, I've no idea how this issue
could be dealt (unless Automake continues to install a fake
aclocal that calls the replacement with the right flags).  

It becomes even funnier if you consider parallel installation of
Autoconf itself.
-- 
Alexandre Duret-Lutz