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

[Gary V. Vaughan]

> Hi Gary,

Morning!

> You already applied this patch.

/me ducks

> However, I had most of this done
> before, so I'll post it nonetheless.  :)

Thanks.

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

The first version I posted did match the description, but I forgot to amend
it when I fixed the patch and reposted based on your feedback.

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

I don't think autoreconf recognises LT_INIT yet either, so after an
autoupdate we are forced to use a bootstrap that says:

     libtoolize -fvi
     autoreconf -fvi

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

Good point.  How?  README?  Another libtoolize advice message?

> 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

I still prefer the former... but consistency is good, and I'm not rabid
about it.  I'll make you a deal: if you write a test for sh.test, then
I'll patch the existing code and stop sending you patches in my preferred
style.  Let's save it until after 2.0 though.

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

I'll try... you'll probably need to keep reminding me for a while though.
Especially the patches that I haven't flushed to the list yet.

Cheers,
        Gary.
-- 
Gary V. Vaughan      ())_.  address@hidden,gnu.org}
Research Scientist   ( '/   http://tkd.kicks-ass.net
GNU Hacker           / )=   http://www.gnu.org/software/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook

signature.asc
Description: OpenPGP digital signature