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

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.

Yes.

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

generators.register [ new gcc-linking-generator gcc.link.dll
   : LIB OBJ : SHARED_LIB
   : <toolset>gcc ] ;

To:

generators.register [ new generators.skip-generator gcc.link.dll
   : LIB OBJ : SHARED_LIB
   : <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. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo