Re: [jamboost] Re: msvc toolset

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-11-10 02:11:19

Kirill Lapshin wrote:

> One more issue related to this one. Rsp files are not always
> regenerated, leading to errors if you build from different folders.
> Suppose you have a lib foo, and exe foo_test which uses foo. You first
> run clean build, from the root of the project. Then you made change to
> one of the foo sources, change dir to foo, and run build. In this
> scenarion foo.rsp will be regenerated, you'll get foo.lib (though with
> pile of warnings) but foo_test builds with old rsp which has paths
> relative from project root, not foo.

FWIW, V2 has the same problem. I think solution exists: the jam variant from 
Matt Armstrong has an IFUSED builtin, which causes rebuild of rsp files when 
needed. I attach Matt's description of the builtin.

Probably, it would be nice to have that builtin, but as for me, I'm not likely 
to have time for that until V2 going alpha.

- Volodya
 --Boundary-00=_Xozr/GCzzEbbZzg Content-Type: text/plain;
charset="iso-8859-1";
name="ifused.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="ifused.txt"

** "IFUSED" targets

Because the Windows NT shell (cmd.exe) sucks, it is often best to
break up complex operations into many actions. Examples include
creating various response files and linker definition files for
the link step of a compile.

The problem with this is that these files may not always be
rebuilt when necessary. It is difficult to construct a
straightforward chain of actions that guarantees that all the
response files that need to get built whenever the final link
makes use of them.

Stock Jam provides two main ways to accomplish this:

- Mark the response files TEMPORARY and remove them with
RmTemps after the link. This is problematic since removing
them just adds mystery to the final link process for the
typical engineer. People often want to look at the files to
see exactly how the link occurs.

- Perform the final link with several actions that take a list
of the final image and all the response files in $(<). Each
action would build one of the elements in $(<). This is an
obtuse hack that is difficult to explain and maintain.

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).

BUGS:

There is a bug in this implementation that I do not believe will
lead to practical problems. Consider the following set of
dependencies.

d -> b*	(d depends on b*)
c -> b*
b* -> a

Consider b* to be marked "ifused". The current implementation
will correctly rebuild b whenever either d or c is rebuilt.
However, it does not guarantee that BOTH d and c get built
whenever b* is updated. If b* is updated only because it is
ifused, some of its dependents may not be updated. For example,
if c is updated and b* is marked for updated because it is
ifused, then d may not be updated. If d is marked for update
and b* is marked for updated because it is ifused, c may not be
marked for update. I call this a bug since it shouldn't be
necessary to run Jam twice to satisfy all dependencies.

A simple way to work around this is to mark b* with NOTFILE. This
will cause b*'s time stamp to no longer be considered. This is
arguably a reasonable thing to do, since these files are rarely
edited by hand and whenever they are used they are rebuilt.
Another workaround is to mark the final linked image with LEAF,
which will usually has a similar effect of removing b*'s time
stamp from consideration. Another workaround is to avoid having a
IFUSED file with more than one dependent target (this is usually
the case anyway, which is the major reason I don't consider this
problem serious).
 --Boundary-00=_Xozr/GCzzEbbZzg--