[jamming] Problem with header file scanning and updates
matt at lickey.com
Tue Feb 11 08:01:17 PST 2003
Vladimir Prus <ghost at cs.msu.su> writes:
>> 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).
Yes we are thinking along the same lines. I haven't thought this idea
out, but it sure sounds like it could make dealing with generated
header files and grist more friendly.
More information about the jamming