On 2/3/2014 7:44 PM, Gennadiy Rozental wrote:
Vyacheslav Andrejev
writes: Hello Gennadiy,
GR> I do not really want to delve into details of our makesystem.
But you can try to change a couple of symbols in the file I pointed you
to.
It doesn't hurt to try, right?
It does. I am not familiar enough with Boost.Build syntax and in no position to learn it. Regardless I was looking for someone who IS familiar with it to make the change everybody can use.
GR> Really? I did not know that. I used junction.exe and Far to create GR> links both on XP and Win7 and it worked fine for both files and GR> directories.
Really. The name “junction.exe” is taletelling: it creates NTFS junction points, not symbolic links for directories. In contrast to junction points, by default only Administrators can create symbolic links. You can easily check it in the local security policies.
b2 tries to create symbolic links by running mklink /D, that is why I suggested to change /D to /J, which would tell mklink to create junction points, which in turn doesn't require special privileges.
Ok. What prevents us from changing bjam to always use hardlinks for directories?
The issue is not the links to directories. The issue is that there are hardlinks to individual files in the boost subtree using the logic of the current 'b2 headers' when run under Windows. This is a problem because if the original file in the libs directory has been changed, as for example via some 'pull' from Git, the corresponding hardlink still points to the old file. So we have a mismatch which causes errors in testing and Boost development. With a smybolic link to the file rather than a hardlink that particular problem goes away. As for directories we already correctly have symbolic links under Windows. There is no reason to change that. It is the hardlinked individual files which cause problems.