libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC: 77-gary-diagnose-version-mismatch.patch


From: Gary V . Vaughan
Subject: Re: RFC: 77-gary-diagnose-version-mismatch.patch
Date: Tue, 3 Feb 2004 21:27:29 +0000


On Tuesday, February 3, 2004, at 07:01  pm, Scott James Remnant wrote:

On Fri, 2004-01-30 at 17:54, Gary V. Vaughan wrote:

This patch kind of fell out of me wanting libtool to do automake-like version mismatch checking at runtime, and autoconf-like AC_PREREQ version-minima.

If you guys like this, I'll rewrite the docs, update the test directories and
resubmit.

After applying this patch aclocal fails with:

        NONE:0: /usr/bin/m4: ERROR: EOF in string

Which makes it a bit hard to play with :(

D'oh!  Two of the AU_DEFUNs have mismatched brackets.

If you don't like it, I will throw my toys out of the pram :-b Alternatively, you might want to convince me to split out just the version checks with eg.
AC_PROG_LIBTOOL(1.5).

Personally I think that the Automakeish single _INIT_ call is probably
the nicest "canonical" way of doing it, especially as it already matches
an existing add-on tool:

LT_INIT_LIBTOOL([1.6 C C++ disable-shared no-pic])

Though if we want to support LT_PREREQ, and maybe a two-args version of
LT_INIT_LIBTOOL with the tags listed as the second, we could do that.
I'd personally learn towards "only one way to do it" though. The single
command has the advantage of being fairly clear, and at least matches
one of the other tools already.

For the sake of making traces easier I definitely want to separate out the tags. I don't think we should support mix-in tags and options, it will make the implementation messier. The one way should be two args: first list options,
then list tags.

The LT_PREREQ also matches an existing tool :-) I think we should advocate that style as it separates two different functions in two macros. I have no problem with an undocumented mix-in version minima though, for the sake of orthogonality
with AM_INIT_AUTOMAKE.

If you can figure out what's broken aclocal (I couldn't after a brief
stare) then I'll see if I can get the language/tag handling working.
I'll probably do it as an _LT_LANG function that takes either a language
name or tag, and builds up a list of tags to pass to _LT_TAGS so Auto*
can trace that.

No need, automake can trace arg 2 of LT_INIT_LIBTOOL :-) I'm attaching a better version of the patch that applies to HEAD, and seems to work here. It is completely un-debugged though. I'll post again when I've ironed out the wrinkles and updated
the demos and docs.

I've also added an m4_pattern_forbid which means we don't need to keep using the lame LT_AC_ prefix to pick up unexpanded macros in configure -- we can
migrate to a proper LT_ namespace!  :-)

Hurrah, should we make ridding ourselves of *AC* a goal for 1.6?

It would be great if we could clean up the API. But if I get libtoolize into shape before we've had time to do that, we should feature freeze and roll an alpha release.

Is there anything else required before the feature freeze? (other than LT_INIT_LIBTOOL
and libtoolize --ltdl?)

Cheers,
        Gary.

Attachment: 77bis-gary-diagnose-version-mismatch.patch
Description: Binary data


--
Gary V. Vaughan      ())_.  address@hidden,gnu.org}
Research Scientist   ( '/   http://www.oranda.demon.co.uk
GNU Hacker           / )=   http://www.gnu.org/software/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook



reply via email to

[Prev in Thread] Current Thread [Next in Thread]