From: Vladimir Prus (ghost_at_[hidden])
Date: 2006-10-11 03:29:24
> >> 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
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
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
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
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
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
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
<toolset>gcc <link>shared <runtime-link>static
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
-- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build V2: http://boost.org/boost-build2
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