Re: [Boost-build] bjam handling of temps

Subject: Re: [Boost-build] bjam handling of temps
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2017-11-03 17:44:09

AMDG

On 11/03/2017 11:00 AM, Stefan Seefeld via Boost-build wrote:
> On 03.11.2017 12:43, Steven Watanabe via Boost-build wrote:
>> <snip>
>>    Rebuilding when a temporary is present seems to be
>> deliberate, though I'm not quite clear on the logic
>> behind this.
>> #define T_FATE_SPOIL          4       /* >= SPOIL rebuilds parents */
>> #define T_FATE_ISTMP          4       /* unneeded temp target oddly
>> present */
> 
> Yeah, I have wondered about that, too. I think this is manifest in code as 
> https://github.com/boostorg/build/blob/develop/src/engine/make.c#L621-L624, 
> which I have tentatively commented out, as I don't follow the rationale of 
> existing temps being considered tainted. (Quite the opposite, actually: if I 
> keep a temp around, perhaps I'm in the middle of a debug session where I do want 
> to inject code into the otherwise automated process. So I'd rather treat 
> existing "temps" as ordinary (non-temp) targets.)

  That shouldn't be an issue.  An existing temporary file
isn't overwritten.  Only its parents are forcibly updated.
Anyway, I didn't write this and I didn't even know about this
behavior until you pointed it out.  You're guess is as
good as mine, here.  Maybe the purpose of this is just
to make sure that the action that deletes the temp file
is run?

>> Second, TEMPORARY is really designed to be used with the
>> `updated` actions flag:
>>
>> actions piecemeal updated ar {
>>    ar rc $(<) $(>)
>> }
>>
>> TEMPORARY x.o y.o z.o ;
>> ar x.a : x.o y.o z.o ;
>> RmTemps x.a : x.o y.o z.o ;
>>
>> In this case, rebuilding x.a because of one changed source,
>> should not force the other object files to be created.
> 
> Are you saying that TEMPORARY isn't used anywhere else ?

  It's sometimes also used in a linear dependency chain
where the only way for the parent to be out-of-date
is because of the TEMPORARY target.

> What about the case of 
> a library metatarget built from sources, where object files are marked as 
> TEMPORARY ?
> In my original (faber) case, I build a "binary" B from a source B.c and a 
> library L, with a temporary object file B.o being removed after a successful 
> build. If I then touch the library sources L.c, the library is rebuilt, and the 
> binary relinked, but its object file B.o not being recompiled (this is the 
> symptom I narrowed down to the above minimal test case), this fails.
> Are you saying I shouldn't be using the TEMPORARY flag for B.o (et al.) ? How is 
> b2 solving this case ?
> 

  In general, you probably shouldn't be using TEMPORARY in cases
where updating the parent requires the TEMPORARY to be created,
as this tends to cause unnecessary rebuilding.  If you really
need it, the problem can be worked around using REBUILDS B : B.o ;

In Christ,
Steven Watanabe