[Boost-build] Building boost and "impossible features"

From: Vladimir Prus (ghost_at_[hidden])
Date: 2006-10-11 03:29:24

Rene wrote:

> >> Hm, I wonder if an easier solution is to have the gcc toolset add a
> >> "<build>no" to the properties. Is that possible? It would seem to solve
> >> all the problems of skipping targets and dependents.
> >
> > I'm not sure what you mean. We can add
> >
> >     <toolset>gcc,<link>shared,<runtime-link>static:<build>no
> >
> > to top-level requirements, so that if such combination won't be ever
> > built.
>
> Well kindof, what I meant is can we make the toolset itself add that to
> targets. There seem to be a variety of time when the toolset itself
> needs to impose such constraints on what gets built. I did this in BBv1
> with the toolset::requirements rule. And I thought that was the overall
> intent of the custom gcc generator. So the overall question:
>
> How do we impose build requirements from a toolset?

I think it's possible to make <toolset> a composite feature, so that it 
expands to extra properties. It's a bit complicated -- what happens if 
<toolset> tries to set some property and user explicitly requests other 
value.

I think before jumping into that we need to discuss what we want -- afresh. My 
attempt is below.

1. Some combinations of properties are "impossible" for a specific toolset -- 
toolset has no way to create a target that corresponds to the documented 
meaning of requested properties.

2. When building Boost on such toolset, we don't want any errors or warnings 
to be emitted -- it does not make sense to inform the user 
about "limitations" of his toolset. As we've seen already, users are pretty 
annoyed with any warnings during build process.

3. User might request impossible combination explicitly. We should produce a 
diagnostic in this case, and either not build a target, or build it with 
different properties.

Let's look at (3) first. I think that building a target with different 
properties, even with emitting a warning, is a bad idea. For a large build, 
user might not even notice a couple of warning lines, but would get a build 
that does not correspond to his intentions.

So, I think that if impossible properties are requested for any target, we 
should not build this target. We can either emit a warning or error.

If we emit a warning, then other targets that depend on not-really-built 
target will still be built. I don't think that's a good idea either. Again, 
the warning about not-build target is easy to miss. And not building one 
target is likely to result in buffling linkg errors. After debugging them for 
a while users will blame Boost.Build for not reporting the problem right 
away.

Also, impossible properties might be an indication of generally wrong build 
properties. It would be better to report the error right away, then spend 
time to build all other target with possibly wrong properties.

So, I think that failure to build a target should be an error, not a warning.

Now let's look at (2) -- how to avoid any errors or warning when building 
Boost. Alternatives are:

1. In top-level Jamfile, add <build>no conditional properties for the affected 
toolset and properties.

2. Take V1's toolset::requirements rule, add it to top-level Jamfile.v2 and 
use "indirect conditonal requirements" to call that rule, which would set 
<build>no

3. Implement a mechanism for toolset to flag impossible combination. Change 
property expansion so that when we say:

     debug release threading=single threading=multi link=static link=shared
     runtime-link=static runtime-link=shared

the impossible combinations won't be even generated.

In all of this cases, it's still possible that target A is built with right 
properties but depends on target B that is built with wrong properties. In 
that case, I think building B should fail with an error, and build process 
should stop.

Of the three alternatives for getting warning-free Boost build, I like (3) 
most. First two mean that we'll try to build each target with a build request 
like:

    <toolset>gcc <link>shared <runtime-link>static
    <toolset>gcc,link>shared,<runtime-link>static:<build>no

which apparently will never produce anything. It just sounds not optimal. 
However, I think it will do the job, so maybe we can postpone optimizing this 
until later.

Comments?

- Volodya

-- 
Vladimir Prus
http://vladimir_prus.blogspot.com
Boost.Build V2: http://boost.org/boost-build2