libtool-patches
[Top][All Lists]
Advanced

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

Re: HEAD: static tests


From: Ralf Wildenhues
Subject: Re: HEAD: static tests
Date: Wed, 22 Feb 2006 00:10:30 +0100
User-agent: Mutt/1.5.9i

Hi Gary,

* Gary V. Vaughan wrote on Tue, Feb 21, 2006 at 11:03:17PM CET:
> 
> In principle, this seems like a good thing to go in, except that I still
> have one nagging doubt:  If 1.5.22 is the only release with the
> regressed semantics for -static, then for bugwards compatibility, I'd be
> inclined to revert to it's former meaning with years old pedigree, and
> come up with a new flag name for the (better) semantics we introduced in
> 1.5.22...

We are going in circles here:
1.5.22 has the -static semantics that 1.4.x and all releases before 1.4
had.  So effectively reverting that was reenabling backwards
compatibility.  It also was the behavior documented all the way.

I do see reason in the new semantics of -static-libtool-libs, which is
what 1.5.x (x<=20) -static did.  However, it was never documented that
way.

BTW, actually I see good reasons for both semantics; they just serve
slightly different purposes.

At one point in time we just have to stop going round in this circle.
One person complained about 1.5.22 -static, and he agreed to use the new
flag if given, so we invented -static-libtool-libs.

> Hmmm (thinking out loud), might it be better to come up with two
> entirely new flag names, one for non-1.5.22 semantics and another for
> 1.5.22 semantics to recommend from here on in.

Not necessary IMVHO: it creates another backward incompatibility step
for users.  And no, I don't want to recommend one behavior over the
other; someone would need to convince me which behavior is better, and
why.

Even if there would be two new names: this patch introduces a new name,
nothing more.

> If we get a '-static'
> flag, we should then issue a big fat warning that for compatibility
> we will interpret this flag as for pre-1.5.22, but it would be better
> for the developer to pass one of the new flag names instead to avoid
> ambiguity in the future.

Why?  It is mentioned in NEWS that the behavior was changed, the next
release will have a mention that -static-libtool-libs will from now on
give you the other behavior.

> What say you?

I say these things will all become irrelevant when per-deplibs static
flags are in a released version.  I surely would like to convince you
rather than to have you (or anyone else) give in to my nagging.  ;-)

Cheers,
Ralf




reply via email to

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