Boost logo

Boost-Build :

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

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

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
Boost.Build V2:

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at