Re: [boost] [modular-boost] "b2 headers" behavior on Windows

Subject: Re: [boost] [modular-boost] "b2 headers" behavior on Windows
From: Edward Diener (eldiener_at_[hidden])
Date: 2014-02-04 01:08:42

On 2/3/2014 7:44 PM, Gennadiy Rozental wrote:
> Vyacheslav Andrejev <mortituris <at> mail.ru> 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.