Re: [v2] Overuse of response files?

From: David Abrahams (dave_at_[hidden])
Date: 2005-05-04 11:48:53

Vladimir Prus <ghost_at_[hidden]> writes:

> On Tuesday 03 May 2005 16:56, David Abrahams wrote:
>
>> > Funny thing is, .rsp stays there if compilation is successful, and
>> > gets deleted automatically by bjam if compilation fails - the opposite
>> > of the desired behavior.
>>
>> The right answer is to do it the way we did in BBv1 (and I don't know
>> why it was changed): 
>
> IIRC, the current response file implementation was done by you ;-)

Are you sure? Wow, I must be getting old to have forgotten that.

>> make the .rsp file into a separate Jam target on 
>> which the result of the compilation depends. If you want to get rid
>> of the .rsp, you can do something like:
>>
>> cl @whatever.rsp && del /q whatever.rsp
>
> I guess the problem is that response file are treated as explicit targets by 
> V2 -- say the msvc.link generator is declared as producing EXE and RSP.
> That's the reason why RSP is removed when link fails.
>
> I see two approaches:
> 1. Make RSP more 'hidden' -- create the target inside actions like "msvc.link" 
> and don't tell V2 about it. But then how will .rsp be removed?
>
> 2. Grab response file support from Matt Armstrong's branch of
> Perforce Jam. 

3. Do what I was suggesting and make RSP less 'hidden': 

>> make the .rsp file into a separate Jam target on 
>> which the result of the compilation depends. 

What was wrong with that suggestion? Then RSP construction becomes
its own build step.

> It allows to write this:
>
> actions response something
> {
> foo @@(-I $(foo))
> }
>
> foo on all = /usr/include ;
>
> something all ;
>
> which produce
>
> something all
>
> foo @/tmp/jam6Pavg0
>
> ======================================================================
> contents of response file /tmp/jam6Pavg0
> -I /usr/include
> ----------------------------------------------------------------------
> /bin/sh: line 2: foo: command not found
>
>
> So, on error the content of response file is printed, but the file
> is removed. On success, the file is silently removed. The content
> of file is also included in "bjam -n" output.

Not bad.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com