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

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?

[snip]
> 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.

Yes.

> 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.

[snip]
> 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 :-)

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

Yes.

> 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 
> <build>no

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 
"A/<runtime-link>static"?

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 
be skipped.

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 
built.

> However, I think it will do the job, so maybe we can postpone optimizing this 
> until later.

Perhaps.

-- 
-- 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