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:
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).
-- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build V2: http://boost.org/boost-build2
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk