Re: [Boost-build] Static runtime link on Linux

From: Vladimir Prus (ghost_at_[hidden])
Date: 2006-08-04 14:58:56

On 8/4/06, Rene Rivera <grafikrobot_at_[hidden]> 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