From: David Abrahams (dave_at_[hidden])
Date: 2005-05-24 11:12:31
Vladimir Prus <ghost_at_[hidden]> writes:
> 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)
Yes, that would work.
> 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.
I would like to *not* use
&& del foo/bar/a.rsp
as a suffix, but instead do something more like:
if %status% EQU 0 ( del foo/bar/a.rsp )
1. It makes the command line shorter
2. If I want to copy/paste the compilation command, it's easier to
avoid getting the DEL command by mistake.
-- 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