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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2006-10-18 01:29:58

On Wednesday 18 October 2006 00:43, Rene Rivera wrote:

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

Ok.

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

Precisely.

I though about making some errors really fatal -- for example, if no generator 
was found to build C++ program, it's likely user-config.jam is wrong, so 
going on does not seem reasonable. But if say that some errors are fatal and 
others are not, we'd need to examine all errors and understand all contexts 
in which the error might be emitted and have a huge potential of getting this 
all wrong.

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

We need *both* -- the ability to ignore the errors and some magic to avoid 
building impossible combination with gcc. In fact, I'm about to add some 
top-level requirements to fix the latter today -- since it's pretty annoying 
now (no matter if we get N warning, one fatal error, or N non-fatal errors).

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

Yes.

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

Can this be solved by property worded summary? I understand that users like 
errors, but if they look for libfoo and it does not build without any 
warnings, it's bad. For impossible properties on gcc we can add top-level 
requirements that will eliminate the error in this case.

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

Hmm, we might make return returning, for a start ;-)

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

No, the logic in 'construct-really' will in both cases decide that generator 
failed to produce anything.

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

Actually, generator can't add anything to requirements, because generator is 
involved with specific property-set, when requirements are already processed.

A generator can however return usage-requirements that will be returned back 
to main target and then propagated to all dependents. I think just 
returning "<build>no" will cause all dependents to be not build. It's also 
possible to modify existing gcc linking generator to return <build>no, 
instead of nothing, when invoked with impossible properties.

This will solve our immediate problem, but again I think not building 
impossible combination by using top-level conditional properties is more 
direct -- you don't need to go to generator level just to fail. And again, 
what about other kinds of errors?

-  Volodya