Re: 278-gary-libtoolize-without-automake-or-AC_CONFIG_MACRO_DIR.diff

[Ralf Wildenhues]

Hi Gary,

You already applied this patch.  However, I had most of this done
before, so I'll post it nonetheless.  :)

* Gary V. Vaughan wrote on Fri, Sep 23, 2005 at 05:09:52PM CEST:
> 
> For users that have an old style configure.in without AC_CONFIG_MACRO_DIR,
> and who don't use Automake (hence no `ACLOCAL_AMFLAGS = -I m4'), libtoolize
> currently refuses to copy any of libtool's Autoconf macros.  This changeset
> reverts to the 1.5.x behaviour of dropping them in the current directory
> in that case.

This description is what completely got me on the wrong track.
The 1.5 behavior is not "dropping them in the current directory" but
"telling the user to update them by hand".

And as such, that is very much ok.  :)

> I've also added another diagnostic that will remind the user that modern
> autoconfiscated projects should use AC_CONFIG_MACRO_DIR to keep these
> macros in a subdirectory.

Good.

With the way autoreconf works currently, there is an issue in that it
calls aclocal before it calls libtoolize.  Unfortunate, because aclocal
will pick up the wrong (old) macros.

We should probably encourage writing a bootstrap script that calls them
in the correct order, when the user decides to use AC_CONFIG_MACRO_DIR?
(Maybe Autoconf should actually do that?)

> from  Gary V. Vaughan  <address@hidden>
>       * libtoolize.m4sh (func_scan_files): Support projects that have
>       upgraded libtool, but still use an old autoconf.  When the libtool
>       macros are not copied (because of missing ACLOCAL_AMFLAGS and
>       AC_CONFIG_MACRO_DIR ), point them at the libtoolize master tree
>       for files to manually copy into acinclude.m4 or aclocal.m4.

I noticed one very small issue:  I don't actually like backslashes at
the end of lines.  We started that because you liked the operator at the
beginning of the line, like this:
   some_command \
       && some_other_command

If you put it at the end of the previous line, you can safely omit the
backslash:
   some_command &&
       some_other_command

This is in a couple of other pending patches as well.  Don't bother
fixing committed code, but for new code it'd be nice to be consistent.

Cheers,
Ralf