Re: 304-gary-add-libtool-macro-file-serial-tags.diff

[Gary V. Vaughan]

Ralf Wildenhues wrote:
> Hi Gary,
>
> * Gary V. Vaughan wrote on Thu, Oct 27, 2005 at 03:37:35PM CEST:
>
> > I believe this to be the correct fix for the bug uncovered by your
> > test with openMPI.  I've also added a new test batch to save us from
> > regressing later.
>
> Thanks.

NP.

Thanks for the review.

> > Okay to commit?  (This is now at the front of my queue btw)
>
> Hmm.  I've got some questions before answering that one.
> This patch actually makes several logical changes:

ACK.  If you'd rather see it as separate commits, I can break it up.
I figured that since they were there to fix a single bug that putting
them in a single patch was okay.  I don't mind either way :-D

> - put some ugliness with _lt_pkgdatadir in libtoolize's output instead
>   of replacing AT_DATA with
>    cat >expout <<EOF
>    something containing $_lt_pkgdatadir ..
>    EOF
>   I don't care much, but I don't like it much either.

Agreed.  Not sure why I didn't do that in the first place!  D'oh :-)

> - equip all libtool m4 files with named serials.
>
> - use that to find out versions in hand-maintained aclocal.m4.
>   (Would that work with `acinclude.m4' as well, by the way?)

Only if m4_include(acinclude.m4) is added to aclocal.m4.  acinclude.m4
doesn't make sense for a hand maintained aclocal.m4 -- either aclocal
manages aclocal.m4 and acinclude.m4 is copied into it, or else aclocal.m4
is hand maintained, in which case macros will be pasted into aclocal.m4
directly.

We could add support for users that hand maintain acinclude.m4 instead
of letting aclocal m4_include local copies of macro files, but use
aclocal to maintain aclocal.m4 proper. There are definitely some odd
corner cases, such as aclocal.m4 not yet generated.  But doing that is
a feature: hence, post 2.0.

> - treat argz.m4 like ltdl.m4.  This is the most troublesome.
> `aclocal' is actually smart enough not to include argz.m4 in the case
> that libltdl is a subproject, because *then*, the user doesn't actually
> need the argz tests in the toplevel project; but she does need other
> stuff in ltdl.m4.

But Automake will not distribute argz.m4 for the top-level Makefile.am,
even if it is in AC_CONFIG_MACRO_DIR, unless aclocal uses it.  Only ltdl.m4
uses argz.m4, so it seems odd to treat them differently.  However, I'm happy
to commit just the other parts and discuss this issue separately.

> I get the impression that we are trying to outsmart something which, in
> the end, may just as well break again with the next change in aclocal.
> Why not just tell those users that hand-maintain aclocal.m4 to get their
> act together and take care of keeping it up-to-date themselves.  No need
> to try to be any smarter than that.

Apart from the argz.m4 change, the rest of this patch is only about
asking the user to update some or all of the newly copied libtool m4
macro files.  Just getting the messages right, and nothing else...

> I am somewhat undecided on that matter, and you certainly have more
> experience.  What do you think?
> > -    case `echo " "$my_included_files" "` in
> > +    case `echo " "$my_included_files" " | $NL2SP` in
>
> You can simplify this to either
>        case `echo " $my_included_files " | $NL2SP` in

ACK.  I've changed to this format.

> or
>        case `echo " "$my_included_files" "` in
> In the first case, word splitting will not occur, but NL2SP will help
> you; in the second case, word splitting will occur on $my_included_files
> before `echo' is called.  The fact that the first resulting word there
> starts with a space is fine.

Until I added NL2SP, the latter version wasn't matching at all with
bash-2.05b or bash-3.0 on my darwin machine.

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