[Top][All Lists]
[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