From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2006-08-04 00:01:13
Vladimir Prus wrote:
> You mean, that warning is now emitted?
> Is it emitted for each target?
Currently yes. I tried finding a way to emit a more informative warning
but the way the code is structured makes it almost impossible to be
meaningfully informative about what is going on.
> it seems a bit unlogical to first request
> build properties that can't be built, and then emit warnings.
User are often "unlogical". Especially when they are trying out a new
procedure. If instead they get an error they are more likely to give up
than to ask why it's producing a warning.
> Imagine a user that just wants to build Boost, and
> gets some warnings. Should he be worried by those warnings? In specific
> case of Boost, he should not, so we'd need to either
> - suppress the warnings just for Boost
Yes. And I'll get to doing that when I find a not so kludge way than the
global var BBv1 does.
> - stop requesting combination that can't be built
There is no way we can know which combination can't be built as it can
change depending on the toolset. If this wasn't clear from previous
discussion I hope it is now.
By the way, this whole runtime-link=static issue is not a problem with
the gcc toolset in BBv1. It gladly builds such a variant regardless of
what is getting built. At some point I get the feeling that the BBv2
toolsets are trying to hard to guard the user into not doing "unsafe"
things. TO the point where it just gets in the way of trying to do valid
things that may not work in the end.
-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
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