Re: [BBv2] fix for response file regeneration

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
be
> 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
build;
* 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
response file.

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.

- Reece