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.
> > 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
> > 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 ;
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk