From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2006-10-11 10:33:23
Vladimir Prus wrote:
> Rene wrote:
>> How do we impose build requirements from a toolset?
> 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.
Yea, users get concerned with any form of build noise.
> 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.
Yep. Initial instinct for me is to not build.
> 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.
Yes, agree. Since this is an explicit request either a warning or error
is fine by me. If it wasn't explicit I would always go for a warning :-)
> 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.
Maintenance PITA :-\ And it doesn't help anyone but Boost.
> 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
Equivalent to (1), but at least would be usable by others.
> 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.
Seems like the ideal to me.
> 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.
Making sure I understand this case. Is this when target A refers to a
specific variant of target B? For example if target A had
Note: Below by developer and user I mean a Boost or other developer
using BBv2 for their software. And for user I mean a Boost user
building+installing Boost and equivalent for non-Boost.
I think this is where we disagree as to the handling. From a developers
point of view this is an explicit request. But from a users point of
view this is an implicit request. The developer might want to fix the
impossible dependency so that the build works. The user on the other
hand is not going to be interested on why he can't build target A out of
targets A through N. They may not be interested in that part at all, and
if they are it doesn't preclude interest in the other targets which is
implied if nothing builds because of 1 target not building. So from a
users perspective I would want to get an indication that it can't build
a target, but still build the rest. In this example both B and A would
Now back to the developer case. Yes it behooves the developer to make
things work and hence is likely to want an error. But, this assumes the
developer knows the capabilities of all the platforms they are
targeting. For many this is usually not a problem as it's a small
number, many times just one. But for a Boost developer this is an
indefinite number. And during a release cycle where it is a definite
number they developers don't want to interrupt the whole build for one
problem as it makes the test-debug-fix cycle that much longer. This is
not serious a problem right now with Boost testing as we only test one
variant, but then testing one variant is not an ideal testing regiment.
Hence even from the developer point of view I would think it more
advantageous to build as much as possible and warn about what can't be
> However, I think it will do the job, so maybe we can postpone optimizing this
> until later.
-- -- 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