Re: [jamboost] Re: [v2] Overuse of response files?

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-05-13 00:33:11

On Friday 13 May 2005 06:09, David Abrahams wrote:
> 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.

Well, response files are a core feature of a build system after all.

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

Ok.

> > 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?

Well, one reason is that the current implementation of response file uses 
the 'print.jam' module to generate response file, and that module is pretty 
complex. But maybe this does not matter unless we run in performance 
problems.

- Volodya

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