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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2006-10-17 13:14:20

On Wednesday 11 October 2006 18:33, Rene Rivera wrote:

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

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

Yes. Advantage of (1) and (2) is that it does not require much design.

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

Me too, but I don't have yet a clear picture who that would work.

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

Yes, or when "B" has some explicit requirements:

    lib B : b.cpp : <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.

You've explained your point very clearly above, thanks! I agree that for large 
projects, Boost.Build-level error in some part can still permit a 
sufficiently useful subset to be built. In fact, bjam takes a similar 
approach when it comes to compile errors -- it just goes on.

So, I think that it would be reasonable to go on in case of Boost.Build 
errors. There are some extra points that I think are important.

- If a target fails to build, the user should know. So, at the end of the 
build we should emit either a summary of errors, or repeat the errors, or 
make bjam return non-zero, or all of that.

- If a target main target fails to build, all dependents must be skipped.

- bjam has the '-q' option that causes it to stop on first error. I think we 
need to do the same with Boost.Build level errors.

- There are many possible calls for errors.error and errors.user-error in 
Boost.Build. I think "can't build target because there are no generators" 
should not be singled out -- we need to do the same for all errors.

So, the ideal plan would be to catch errors in few strategic points -- like 
when we try to build a target, and implement the new behaviour there. Then,
we get consistent handling for all errors.

What do you think? Not that I know how to implement this easily -- we might 
want to first port in Python and then use Python's exceptions ;-)

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

I'll think about it more.

Thanks,
Volodya