[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
(details are at the bottom of

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