
AMDG On 12/02/2013 05:06 PM, Bjørn Roald wrote:
On 12/03/2013 01:48 AM, Daniel James wrote:
On 3 December 2013 00:32, Bjørn Roald
wrote: not sure I understood exactly what you refer to, but I did just test command line concatenation, emacs, gedit, vim. All of them seem to change the file as I expected. What programs do you have in mind?
Git for a start. If you check out a different version of a header it will break the link.
In that case we should use symlinks for sure. The problem here is that the dependency in b2 for the link should catch this in the build, but not if the date stamp move in the wrong direction. IBM cleamake solves this in clearcase views, but we do not have that build tool. Using filetime "greater than" to detect dependency changes is a fundamentally broken hack used by almost all build tools.
I thought that I wrote this to try symlinks first. Anyway, if everyone agrees that the correct behavior is to create a symlink, then it's really easy to change. Go to link.jam, find the rule do-file-link, and switch the order that it checks hard links and symlinks.
As far as I remember symlinks to files are not Supported on windows prior to Vista, how much of a concern should that be? I guess copies are annoying for XP hosts, but not as devious as I see hardlinks could be.
A copy has no advantages over a hard link. - If the source is overwritten in-place, then the hard link is still correct, and there is no problem. - If the source is replaced, then the hard link is left pointing to the original file, and the state is essentially the same as if we had made a copy. In Christ, Steven Watanabe