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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-05-24 07:13:19

On Tuesday 17 May 2005 23:35, David Abrahams wrote:
> Vladimir Prus <ghost_at_[hidden]> writes:
> > I attach a prototype implementation that implements this idea for
> > msvc.compile.c++ action, and would appreciate if you try it.
>
> Doesn't work at all. Did you test it? 

Sure, but only in linux with "bjam -n". 

> It creates circular 
> dependencies, among other things. The enclosed works... sort of.
>
> It's really inconvenient and IMO senseless to use response files for
> compiles of single source files. The only purpose is to shorten
> command lines, and when the response file name is likely to be as long
> as the input file name you don't gain anything.

Ah.. here's a catch. One user managed to run out of command line length 
limitations for single file compiles, due to very long list of includes.
What can be do other then always using response files? Only detecting when
response files are needed.

And the most convenient way is core support, so that

actions
{
cl.exe @@($(INCLUDES))
}

will expand to 

cl.exe @some_file.rsp

response file when command line length run of of some limit,
and expand to just

cl.exe $(INCLUDES)

otherwise. But then we're back to question when response files should be 
removed. 

If fact, I think we can solve that question: if we're creating foo/bar/a.exe,
then response file name can be foo/bar/a.rsp, and it won't be deleted if
compile fails. So copy/pasting the failed command will still work. The file 
will be delete after first successfull run. Looks OK to me.

- Volodya

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