From: Reece Dunn (msclrhd_at_[hidden])
Date: 2005-10-18 06:38:06
Vladimir Prus wrote:
> On Tuesday 18 October 2005 12:29, Reece Dunn wrote:
> > A while back, I noted a problem with response files not being
> > regenerated when you change properties in the Jamfile on targets that
> > failed (leaving the response files behind).
> > The attached diff file fixes the issue. The fix it trivial: tell bjam to
> > always generate a response file.
> Won't this cause the executable/library/object that uses response file to
> always relinked/recompiled? If no, I'm very surprised ;-)
I didn't have time to check that, only that the response file was
regenerated. If that is the case... argh!
I don't think it will be a problem:
* If a target does not need rebuilding, it won't get rebuilt;
* If a target has been built, but has been modified since, the target needs
rebuilding and the response file was deleted and gets generated for this
* If a target failed, the response file would not get regenerated so if you
modified the Jamfile, it won't pick up the changes.
This should *only* alter the behaviour of the response file (hence the
$(rsp)). Thus the previous:
TEMPORARY $(rsp) ;
tells bjam that the response file target is a temporary target (for the
lifetime of the action?). This on it's own was not enough to regenerate the
response file in all cases. Thus, by adding:
ALWAYS $(rsp) ;
we are telling bjam that (when a target needs rebuilding) to always call the
response file rule (*not* the exe/lib/obj rule) and thus regenerate the
As I said, I haven't had chance to fully test the patch - I have only
verified that it fixes the response file regeneration problem. I would
verify it, but don't have access to my development machine at the moment. It
should be easy to verify that the fix does not cause a relink/recompile.
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