On 8/4/06, Rene Rivera <grafikrobot@gmail.com> wrote:
Vladimir Prus wrote:
> You mean, that warning is now emitted?
Yes.
> 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.
So, now user building Boost on Linux will get a *lot* of warnings. I recall some users complained very loudly about those Python-related and ICU-related warnings, and I'm sure if they get 100+ warnings when building Boost on a very common platform, they will be even more upset.
> Well,
> 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.
I'm not saying it should produce an error, I'm saying it should not try to build combinations that don't work.
> 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.
So, then we'll
- request properties that can't be built with gcc
- have code to emit the warning in that case
- have code to suppress the warning
Suppressing build of those combination just for Boost would be a more direct approach.
> - 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.
This is not a general problem of deciding if arbitrary combination of properties will be built.
We only need to detect runtime-link=static with gcc. It's quite possible to write custom main target class, or a generator that will
suppress building of runtime-link=static when toolset=gcc. Then, top-level Boost Jamfile will declare a target of appropriate type.
This won't require such global changes.
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.
In other words, if you request both static and dynamic runtime, V1 will built two sets of object files, despite the fact that they are roughly equivalent, and both will use dynamic libc? I'm not sure I see the point of silently doing such things.
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.
In this specific case, I think there's a better solution -- filtering build properties by some top-level 'build-all' target.
- Volodya