[jamming] Problem with header file scanning and updates
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).
More information about the jamming