Re: [Boost-build] CVS: boost/tools/build/v2/build generators.jam, 1.100, 1.101 targets.jam, 1.197, 1.198

From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2006-08-04 01:51:45

Vladimir Prus wrote:
> On 8/2/06, Rene Rivera <grafik_at_[hidden]> wrote:

>> Skip targets that can't be generated like BBv1 does.
> 
> Just as a check -- did you run V2 testsuite before and after this 
> change, to
> verify it causes no regressions?

No, but that was because I didn't have the time. I'll get to that this 
weekend.

> Index: generators.jam
>> +    # Indicates if this generator can handle building the given target
>> +    # combination.
> 
> I think this comment is not sufficient.

It seems as sufficient as some of the other commented methods in that 
class. It says exactly what it means and nothing else. Perhaps comments 
need to be added to where can-build is called to explain what effect it 
has there.

> How returning false from this rule
> is different from
> returning nothing from the 'run' rule?

I have no clue. But then again the run rule doesn't say what happens 
when it returns nothing.

> I think there are some differences,
> but the comment does not say what they are.

Perhaps... What do you think are the differences?

>> -rule find-viable-generators ( target-type : property-set )
>> +rule find-viable-generators ( target-type : property-set : sources * )
>> {
>>     local key = $(target-type).$(property-set) ;
>>     local l = $(.fv.$(key)) ;
>>     if ! $(l)
> 
> 
> You've added new parameter by you still key the .fv. catch on
> target-type/property-set.
> It means that if two invocation differ by 'source' the second one will 
> reuse
> results of the first.

OK, didn't notice there was a cache being use. May I suggest better 
names for such variable. Perhaps something that has the word cache in 
it, like "viable-generators-cache". I'll go fix the cache key problem 
though :-)

>> @@ -733,8 +735,11 @@
>>         for local p in $(all-property-sets)
>>         {
>>             local r = [ generate-really $(p) ] ;
>> -            usage-requirements = [ $(usage-requirements).add $(r[1]) ] ;
>> -            result += $(r[2-]) ;
>> +            if $(r)
>> +            {
>> +                usage-requirements = [ $(usage-requirements).add $(r[1])
>> ] ;
>> +                result += $(r[2-]) ;
>> +            }
>>         }
> 
> So, this code allows a dependency to emit a warning, produce nothing, and
> still go on. 

Yea, seems that way.

> It seems to be that if any dependency fails to build then
> dependent's build should be aborted immediately.

If by "aborted" you mean that it should print a warning and skip 
building the dependent's target? Then yes. How can a target be made to skip?

> I still don't understand why *failure* to build a target should become a
> warning.

Because skipping unbuildable targets has been the expected behavior of 
Boost.Build from the start. When users ask for something to get built it 
should build as much as it can and only reports problems at the end. But 
that's not really an argument, but an excuse. The real reason is that we 
don't want to force artificial barriers on building what we think are 
incorrect configurations. That just frustrates new users who might get 
fed up with an uncooperative build system. And it frustrates experienced 
users because it will prevent them from doing things that they know will 
work.

> So, now call to 'generate' can return nothing, just emitting a warning. I
> think lots of generators are not quite prepared for that.

Yes, it happens. They need to get fixed. It seems perfectly plausible 
that one might not generate anything, abstractly speaking.

> We already see a
> case where generator in python.jam suffers a hard crash due to this.

Yes, and I'll go fix that.

> In
> general, if you ask generators.generate to produce target of type WHATEVER,
> you expect it to do just that, or fail.

Returning nothing is a failure. It's just not aborting, without letting 
you handle the error, as the code previously operated.

> If you add a third option -- build
> nothing -- you either need to use a special return code,

Returning and empty list, i.e. nothing, is a special return code. It 
means the call was unable to satisfy your request.

> or check that all
> callers will properly react to such "nothing" return.

Yes.

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