Re: [BBv2] fix for response file regeneration

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2005-10-26 06:31:22

Vladimir Prus <ghost <at> cs.msu.su> writes:

> 
> On Tuesday 25 October 2005 00:17, Reece Dunn wrote:
> > David Abrahams wrote:
> > > I like Zbynek's idea. It would look great; almost as though we had
> > > magically fixed the command-line length issue, except that <at> (...)
> > > would appear in actions.
> >
> > I like the idea too, I am just not sure how to implement it. I don't
> > know enough about the BBv2/RSP file internals to remove response files
> > as targets. My initial attempts have failed to retain the current
> > functionality while fixing the regeneration problem :(.
> 
> Jumping late to this discussion, I don't understand what's being proposed. 
> Yes, we can replace the current RSP logic with something like:
> 
> actions compile.c++ 
> {
> echo -I$(INCLUDES) > $(<).rsp
> cl <at> $(<).rsp ....
> }
> 
> but in that case we'll hit command line length limitation for the "echo" 
> command. What do we gain here?

My initial thoughts were to keep the common.response-file rule (or something
similar) to leverage the print.jam code.

> The first question is still: do we retain the rsp files if build fails, so 
> that one can rerun the same compile/link command? If no, there are no 
> problems at all.

I think the consensus is to retain the response file on failure.

> If we want to retain rsp files, we need to regenerate when the target that 
> uses RSP must be rebuilt. There are two choices:
> 
> - The IFUSED builtin (which exactly says that a target should be rebuild
> if it's used by a target that is rebuilt itself)
> - MD5/properties based mechanism to rebuild things.
> - Matt's <at> () syntax, together with non-deletion of rsp files on
> failure. (This will leave rsp files in /tmp, and require windows porting)
> 
> Honestly, I'd prefer the last variant, since response files processing are a 
> bit of mess (just take a look at common.response-file).

I also like the last variant:
* it cleans up the common.response-file code (as you mention);
* it has a very nice syntax :);
* you would most likely get some speed gains as you are not generating the
response files from interpreted code.

However:
* the code is based on PJam, not BJam, so would require some thought when
porting;
* the location of the response files - do we want them in the temporary
folder or do we want to say "response-file ../gcc/release/main.obj.rsp" for
compatibility with current BBv2 code;
* do we want to print out the response file contents like Matt's code.

Dave asked if it were possible to keep the response file logic in the BB code
without adding explicit support for them in bjam, just adding the minimal
functionality to get them working (I presume this would be the IFUSED rule).

I like the idea of importing the IFUSED rule and <at> () syntax, but this is
rapidly going beyond my BB/BJam knowledge. I will try and look into this, but
am not promising anything.

- Reece