Re: CVS libtoolize wants to read unexisting aclocal.m4

>>> "Gary" == Gary V Vaughan <gary@xxxxxxx> writes:

[...]

 >> I feel it might be worth moving away from the traditional
 >> 
 >> fooize  # install foo's macros and aux files
 >> aclocal
 >> autoconf
 >> 
 >> to something like
 >> 
 >> aclocal --copy # copy system-wide macros locally
 >> autoconf
 >> fooize         # install only foo's aux files
 >> 
 >> That way `fooize'-like tools can trace all they want in configure.ac.

 Gary> In principle I couldn't agree more... infact, I am in the
 Gary> camp that wants aclocal functionality to be rolled in to
 Gary> autoconf, and this is a step in that direction.

 Gary> Another good thing that comes of this scheme is that
 Gary> autoconf can maintain all of the macros it uses (in an
 Gary> aclocal-x.y style tree).

 Gary> Bad citizens like libtool and gettext would need to
 Gary> co-operate with autoconf again about where they install
 Gary> their macros, but autoconf could ship a tool that fooize
 Gary> installers can use to install their macros.

The day this is done, autoconf will obviously scan
/usr/share/aclocal/ for backward compatibility.  Gettext already
install its macros there.  IFAICT only CVS libtool doesn't.

As I've already argued in
http://mail.gnu.org/archive/html/libtool/2004-02/msg00014.html 
I think this change is a step backward.

If you install *.m4 files in /usr/share/aclocal/ again, you
can already experiment with a `libtoolize --postautoconf'
version of libtoolize that scan libtool from meaningful macros,
and install the necessary auxiliary scripts.  That does not need
any other support.  Once that is done, it should be easy to
modify autoreconf so it uses this new libtoolize option when
available.  (Or perhaps the autoreconf modification can wait
until `aclocal --copy' exists.)

[...]

 Gary> What can I do to help it all happen? (I'll get back to m4
 Gary> as soon as libtool enters feature freeze for the next
 Gary> release).

Nothing is needed in m4 for the above to work.  

However, I think we already discussed about the need to
dynamically modify the include search path from inside m4
macros.  Such feature is necessary to support

  1) parallel/versioned installations
     (e.g., multiple automake versions -- this currenlty works
     only because aclocal knows the automake version to consider,
     but when that functionally is moved over to autoconf we'll
     have to indicate the version with a macro)

  2) AC_CONFIG_MACRO_DIR

-- 
Alexandre Duret-Lutz