From: David Abrahams (dave_at_[hidden])
Date: 2005-05-12 21:09:18
Vladimir Prus <ghost_at_[hidden]> writes:
> On Wednesday 11 May 2005 23:03, David Abrahams wrote:
>> >> is printed on the error.
>> >> What do you think?
>> > If .rsp file is printed in the log and then deleted, in order to
>> > re-run one would have to restore the deleted .rsp file by copying its
>> > contents from the log. This works, although it's not uniform with
>> > unix-based process (just copy and re-run).
>> > On the other hand, if .rsp file is never deleted, then the command
>> > line from the log is reusable at any time.
>> > I would vote for printing the contents of .rsp, so that all flags are
>> > visible in the log, and keeping it intact, so that the compile/link
>> > command are reusable at any time later, similar to unix builds.
>> What do we need to do in order to resolve this? Have we got an
>> acceptable plan? This is really a critical problem for me.
> We still need to decide what to be done. Options:
> 1. Grab Matt's code, optionally modifying them so that response files
> are not deleted when command fails.
Making core changes to bjam seems like a drastic step to take just to
solve this problem.
> 2. Modify V2 so that
> - The RSP file is not listed in the target types of generators
> - Each action creates RSP file from sources and makes binary
> depend on RSP, so that RSP is not removed.
I like #2, in principle.
> I attach a prototype implementation that implements this idea for
> msvc.compile.c++ action, and would appreciate if you try it.
I'll give it a shot.
> If the behaviour if fine we can made the change for other rules and
> I'm still not sure which approach is best, but don't care very much
> either way.
Can you think of any reason at all to prefer #1?
-- Dave Abrahams Boost Consulting www.boost-consulting.com
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