From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-05-03 09:25:50
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 ;-)
> 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.
It allows to write this:
actions response something
foo @@(-I $(foo))
foo on all = /usr/include ;
something all ;
contents of response file /tmp/jam6Pavg0
/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.
One downside is that with this patch it's not possible to redirect output of
bjam to a bat file, and then run that file. I'm also not sure that Boost
regression testing tools will be happy with the extra output.
The patch is not so big, so I can integrate it quickly. Comments?
-- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build V2: http://boost.org/boost-build2
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