Re: [jamboost] Re: link-compatibility poll: results and feature removal

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-03-02 09:45:39

David Abrahams wrote:

> > And my own vote goes for "pointless messages". So, the distibution is
> > very even and it's hard to draw a coclusion. Guess I'll have to decide
> > myself.
>
> I, for one, am really afraid of removing the check. I guess I'm in
> the "sounds important" camp.

Okay.

> > The problem with link-compatibility check is that they fail in more
> > complex scenarious. For example, I want to link single-threaded library
> > into multi-threaded one -- I really want that. Yet, I get a warning about
> > link-compatibility and I can stop it.
>
> Then single/multi-threaded shouldn't be link-incompatible.

Well, the person who said it has helped mentioned precisely MT/ST 
compatability, so that's one of the cases when the check works.

> > Another example is that I have custom toolset which is gcc + some
> > extra processing steps. Now, I get numerous warnings that the new
> > toolset is not link-compatible with gcc.
>
> I don't understand that one at all.

I have a <toolset>nmm. A custom generator passes sources though a certain 
preprocessor, and then changes <toolset> to gcc and compiles/link the targets 
as usual. But the link-compatability check notices that main target is built 
with <toolset>nmm and object files are with <toolset>gcc, and issues a 
warning.

> > That fact that non-trivial cases produce warnings that can't be stopped
> > is really unfortunate, because spirious warnings make it almost
> > impossible to spot real warnings -- and users will learn to ignore *all*
> > link-compatibility warnings.
>
> Yep, that's a serious problem.
> Maybe the right thing to do is to have a way to say: "Yes, I know
> there's a link-incompatibility here. Don't warn me and do it anyway"

The problem is to design and implement such a method. And that precisely what 
will take the time :-(

> > So, link-compatibility is half-implemented feature. I'm really not
> > sure I'll have the time to finish it by 2.0 release. And while I'm
> > sorry to remove a feature, especially one that have helped at least
> > one user, I'm going to remove it later this week, unless there are
> > good arguments against removal.
>
> I guess I'm not very clear on the consequences of the proposed
> removal. Normally when you request a target build, its dependencies
> are built in a link-compatible way. So how does the warning get an
> opportunity to fire?

Either when dependency target specifies link-incompatible property in 
requirements, or you explicitly change the property when requesting the 
build, like in:

lib runtime : runtime.cpp common/<threading>single : <threading>multi ;

- Volodya