Re: [BBv2] fix for response file regeneration

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2005-10-20 16:16:27

Vladimir Prus wrote:
> On Wednesday 19 October 2005 01:15, Reece Dunn wrote:
> 
>>Vladimir Prus wrote:
>>
>>>On Tuesday 18 October 2005 12:29, Reece Dunn wrote:
>>>
>>>>A while back, I noted a problem with response files not being
>>>>regenerated when you change properties in the Jamfile on targets that
>>>>failed (leaving the response files behind).
>>
>>Looks like it is back to the drawingboard :(.
> 
> In fact, there are two related problem.
> 
> 1. Nothing is rebuild when free properties changes (you add <define>, but V2 
> does not rebuild anything).
> 
> 2. Even if you remove the binary, the response file is not regenerated.
> 
> The first problem can be only handled by build signatures -- computing MD5 of 
> all build properties, storing them to a file, and forcing rebuild when stored 
> MD5 of a file is different. 
> 
> The second problem can be solved either by solving the first problem, or 
> separately
> - by porting the IFUSED builtin from some other jam variant
> - by porting the response file support from the same jam variant
> 
> That "jam variant" is a branch of Perforce Jam done by Matt Armstrong.
> 
> In fact, the current version of Matt's branch does not contain this builtin, 
> but has support for something like that:
> 
> actions whatever
> {
> @(bla-bla)
> }
> 
> This causes 'bla-blah' to be written to a temporary file, and the action will
> contain @<name-of-the-file>

I *really* like this syntax :). I have the original Jam and Matt's Jam 
sources from Perforce (public.perforce.com Perforce connection) and am 
going to start looking at merging the changes into BJam.

> I recall we had a long discussion about relative merits of those approaches, 
> and did not decide anything. There are some usability questions, like 
> removing or not removing files when build succeeds, or when it fails.

We can get an implementation up and running, then modify it to best suit 
our needs. Having a "native" solution would be a lot better than the 
BBv2 implementation we currently have.

Q: What will happen when we port over to BBpy?

- Reece