Re: [jamboost] Re: [BBv2] fix for response file regeneration

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-10-20 02:51:56

On Wednesday 19 October 2005 01:15, Reece Dunn wrote:
> 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 ;-)
>
> You are right! $@#£! :(
>
> Looks like it is back to the drawingboard :(.

In fact, there are two related problem.

1. Nothing is rebuild when free properties changes (you add <define>, but V2 
does not rebuild anything).

2. Even if you remove the binary, the response file is not regenerated.

The first problem can be only handled by build signatures -- computing MD5 of 
all build properties, storing them to a file, and forcing rebuild when stored 
MD5 of a file is different. 

The second problem can be solved either by solving the first problem, or 
separately
- by porting the IFUSED builtin from some other jam variant
- by porting the response file support from the same jam variant

That "jam variant" is a branch of Perforce Jam done by Matt Armstrong. Here's 
docs for IFUSED builtin:

The solution presented here is a new built in rule IFUSED. When
called like this:

IFUSED target ;

"target" is marked "ifused".

When Jam decides that a given target is to be built, it now checks
all direct dependents to see if they are marked ifused. If they
are, the ifused dependents are also marked for rebuilding, and
their direct dependents are similarly considered, and so on.

This affords the benefits of marking targets TEMPORARY (that they
will be rebuilt whenever the targets they depend on are rebuilt)
without the negatives (that they get deleted after the build).

In fact, the current version of Matt's branch does not contain this builtin, 
but has support for something like that:

actions whatever
{
@(bla-bla)
}

This causes 'bla-blah' to be written to a temporary file, and the action will
contain @<name-of-the-file>

I recall we had a long discussion about relative merits of those approaches, 
and did not decide anything. There are some usability questions, like 
removing or not removing files when build succeeds, or when it fails.

- Volodya

   

   

>
> - Reece
>
>
>
>
>
> Yahoo! Groups Links
>
>
>

-- 
Vladimir Prus
http://vladimir_prus.blogspot.com
Boost.Build V2: http://boost.org/boost-build2