Re: [jamboost] Re: [BBv2] fix for response file regeneration

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-10-26 02:19:17

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 @(...)
> > 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 @$(<).rsp ....
}

but in that case we'll hit command line length limitation for the "echo" 
command. What do we gain here?

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.

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 @() 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).

- Volodya

-- 
Vladimir Prus
http://vladimir_prus.blogspot.com
Boost.Build V2: http://boost.org/boost-build2