Boost logo

Boost-Build :

From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2006-10-17 16:43:27

Vladimir Prus wrote:
> On Wednesday 11 October 2006 18:33, Rene Rivera wrote:
> You've explained your point very clearly above, thanks!

Your welcome :-)

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

Yes, and bjam also has the "-q" option that also provides the alternate
mode of immediate exit on error.

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

OK. Note, when I talk about warnings I really mean a user message plus
continuation. If the message is in the form of an error is perfectly
fine :-)

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

I'd say at least (a) and (c), but (b) and (c) would be ideal. Repeating
error messages has been requested in the past.

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

Ah, yes mentioned above :-)

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

OK, I can go with that, assuming I'm understanding you correctly. Are
you suggesting that *all* build errors would not cause an exit?

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

Well I'm not sure that's the ideal. This sounds like a reactive solution
to solve the inability of toolsets to declare what they can actually
build. But I guess there would be a general need to have this type of
error handling, i.e. the same way try/catch in C++ is useful.

> What do you think?

My concern is that we might not be able to differentiate between
expected an unexpected errors. In the case we are talking about I would
consider it an expected error from the POV of Boost, and the BB toolsets
specifically. If we can expect to have errors, as is the case when the
toolset can't build a variant, it should be possible to specify this at
some level such that as developers one can avoid users knowing about
such expected situations. Basically I'm afraid of the user case, where
they try and build Boost for the first time and even though it seems to
build, there are also a bunch of "errors".

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

Well we could implement some builtins that give us the ability to
implement exceptions. All it really takes is a builting that allows one
to set and clear a sticky early return from rules.

Going back to an earlier comment on this message...

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

...I have a question regarding generators. Is the handling of the
situation where a generator doesn't do anything when "run", different
from the case where there is no generator found? I'm asking because
currently the former is what we have implemented in gcc.jam. But it
seems possible to define a toolset such that the later is done instead.
For the gcc case I'm thinking that we could change the generator

generators.register [ new gcc-linking-generator
   : <toolset>gcc ] ;


generators.register [ new generators.skip-generator
   : <toolset>gcc <target-os>unix <runtime-link>static ] ;

The skip-generator would add the "<build>no" to the requirements, and
possibly add a
"<toolset>gcc,<target-os>unix,<runtime-link>static:<build>no" to the
usage requirements.

-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. -
-- rrivera/ - grafik/
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at