> 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 ())_. [EMAIL PROTECTED],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
