Re: [v2] Overuse of response files?

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
> toolsets.
>
> 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