[jamming] Problem with header file scanning and updates

Vladimir Prus ghost at cs.msu.su
Mon Feb 10 21:56:00 PST 2003


Matt Armstrong wrote:
> So your UicR rule will create a target something like <a!b!c>base.hpp.
> 
> However, Jambase by default does not grist header files found during
> the header scan phase.  So Jam will scan derived.cpp and find
> 
>     #include "base.hpp"
> 
> and create a base.hpp target.
> 
> So you end up with <a!b!c>base.hpp and base.hpp -- two Jam targets
> that reference the same file.
> 
> The first time you run Jam, base.hpp is not modified on disk yet, so
> derived.cpp is not out of date (Jam does not realize base.hpp and
> <a!b!c>base.hpp are the same file).  The second time, Jam notices that
> base.hpp is newer than derived.cpp and recompiles derived.cpp.

[...]

> I wish there were an option 4)
> 
> 4) Modify jam itself such that all targets that are bound to the same
>    file on disk automatically have an Includes dependency amongst
>    themselves (since anybody depending on one of them will want to
>    depend on all of them).

In boost.jam we solve the same problem by introducing SEARCH_FOR_TARGET 
builtin. You give a list of paths and a target name to it, and if there's
target already bound to one of paths and with the same name, it returns that
target.
(details are at the bottom of
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/tools/build/boost_build_v2.html?rev=HEAD&content-type=text/html
)

Your idea looks way simpler! On the other hand, I'm not sure it will work as 
is. Assume you're looking for file "parser.h" in directories "a", "b" and "c".
There's <b>parser.h, bound to "b/parser.h" via LOCATE. The standard file 
search won't care about that another target, and will declare "parser.h" as 
unfound. I think's it needed that search mechanism look if there are other 
targets bound to the same location, and stop here (adding include dependencies
are you describe).

- Volodya








More information about the jamming mailing list