AMDG On 05/10/2012 08:48 PM, Bjørn Roald wrote:
Algorithm looks good to me as far as what to create when a missing link is detected.
Whether you have captured the rest of what should be there it is not clear to me. My ignorance of the details of bjam and Boost.Build, and thus my understanding of the effect of your patches does not allow me to understand in a glance. So I ask instead.
Does your solution provide proper functioning build graph including the derived forward header links or files?
I haven't tested it, so it probably doesn't. It should just be a matter of adding any dependencies that I've forgotten. It looks like I need to add dependencies for hardlinks and copies. sym-links don't need the dependency, since they're guaranteed to be correct as long as they exist. The include scanner does work correctly with generated headers, so no source should be built before the headers that it depends on.
Symbolic and hard links are services of the file system and when set up correctly, they should work transparently to the build system as though it looks at the source files.
bjorn@frodo2:/tmp/linkjunk$ touch a <snip>
note the time of a_symb is older than the file a after last touch of a. Horror. Does the build graph analysis handle this correctly. Note also that hard links are OK.
stat returns information on the target of the link, so it should be okay. I haven't checked what happens on Windows, yet.
Cleanup of derived forwarding headers and links when source are moved or deleted is a bit more tricky than support to create them. Any hope of support for this?
Given that multiple directories are being merged, we have no way of knowing that any extra files aren't from a source that exists but didn't happen to be mentioned in the current build. With directory sym-links, this shouldn't be much of a problem, though. Anyway, the extra links should be harmless and it's easy enough to delete and regenerate the entire directory once in a while.
A side note: A really smart build system should detect changes in content of the source files, not just a forward motion of file time. But this is probably both costly and a very fundamental change. I think lack of such a feature may bite us more with modularized boost as it is simpler to change a parts in your build graph to an earlier versions without realizing the need for clean builds.
It's not as costly as you might think, since the include scanner already reads in most of the source files, so the IO cost is already incurred. I'll consider this after I get around to updating HCACHE to work better with Boost.Build. In Christ, Steven Watanabe