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

[Bonzini]

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

Isn't AC_CONFIG_LIBOBJ_DIR already there?

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

No, too much backwards incompatibility.  Do we care about *two* files each
3k long?  Couldn't we include mdate-sh in Automakized programs, make ylwrap
depend on AC_PROG_YACC, and so on?

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

That's fine for me.

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

We could call autolib aclocal, it even has the same initials :-) (just
kidding)

Paolo