Re: [Boost-build] Leave target on failure?

Subject: Re: [Boost-build] Leave target on failure?
From: Johan Nilsson (r.johan.nilsson_at_[hidden])
Date: 2010-03-05 15:10:57

"Vladimir Prus" <ghost_at_[hidden]> skrev i meddelandet news:4B912A7B.40307_at_cs.msu.su...
> Johan Nilsson wrote:
> 
>>> I've tried to address this in small steps, and checked in a new
>>> builtin,
>>> PRECIOUS, that prevents removal of a target when update fails.
>>> See:
>>>
>>> https://svn.boost.org/trac/boost/changeset/60157

>>>
>>> Does this help at least half-way? If it mostly works, I'll implement
>>> an indirection to decide if to retain target based on exit code.
>> 
>> I think so (assuming that "clean" removes even PRECIOUS targets, which 
>> it should do). Need to have the indirection implemented and be able to 
>> test it before I can tell for sure. Also, I hope that there will be a 
>> Boost.Build rule that allows this to be used more easily with 
>> Boost.Build level targets (or am I just assuming this will make things 
>> easier)?
> 
> I was hoping no other change would be required. E.g. if you have a custom
> rule/action pair to run your testing tool, you can adjust the rule as follows:
> 
> rule run-tests ( targets * : sources * : properties * )
> {
> PRECIOUS $(targets) ;
> }
> 
> which seems just as good as introducing virtual-target.precious and calling it
> from the generator. What do you think? This is basically up to you, adding
> new rule in virtual-generator is low effort.

Looks ok. I'll have to actually try it out though.


>> As for actually keeping the target based on the exit code, please 
>> consider (such in this case) that the possible exit codes might not be 
>> possible to determine in advance with reasonable effort. It should be 
>> possible to set the exit code as a range, set, or logical/special 
>> expression (such as e.g. NEGATIVE or "< 0"). I guess this could be 
>> implemented by allowing the user to specify a rule used for determining 
>> the PRECIOUS-ness of the target.
> 
> I am thinking that rule is indeed the best way -- as opposed to inventing
> funny syntax.

Agreed, then.

Thanks / Johan