Subject: Re: [boost] Reminder about links when running b2 headers
From: Edward Diener (eldiener_at_[hidden])
Date: 2013-12-24 16:49:25
On 12/24/2013 11:46 AM, Steven Watanabe wrote:
> AMDG
>
> On 12/24/2013 08:29 AM, Edward Diener wrote:
>> There was already a discussion about why the creation of hard links to
>> individual files in the boost directory is inferior to the creation of
>> symbolic links when the ability to create symbolic links is supported by
>> the OS. As a reminder, if a hard link is created and the submodule file
>> is replaced by git, the hard link will still refer to the old file
>> contents. Thus testing, when it refers to any of the hard linked header
>> files in the boost subdirectory, will go awry if this happens.
>>
>
> This actually depends on the timestamp that git sets
> for the new file. If it always sets the timestamp
> on checkout to the current time, then b2 will update
> the link.
Do you mean that b2 would update the hard links appropriately in the
boost subdirectory if one reruns './b2 headers' ? That is fine for
systems that must use hard links, but in that case the user must know
when to rerun './b2 headers'. That is why symbolic links are the better
solution when available.
>
>> Can we please have this updated at the module boost superproject level
>> by some Boost Build guru so that symbolic links are created when allowed
>> by the OS ? Even if, as on Windows, administrator rights are needed to
>> create symbolic links it seems we could have some b2 headers
>> alternative, aka 'b2 headers_wadmin', which would create symbolic links
>> on Windows for users who have administrator rights. Of course on Linux
>> this is not a problem.
>>
>
> No special target is needed. If you're
> running as an administrator, Boost.Build
> will detect that it can create symlinks.
I assume that you mean that you plan to make it work this way. That
would be great. When I first ran '.\b2 headers' under Windows 7 I had
administrator rights but it still created hard links.
>
>> I realize this might not be easy to do even by a Boost Build expert but
>> unless we want to hear squawks and complaints from Boost
>> developers/end-users using our git/modular boost setup we need to change
>> to symbolic links when possible.
>>
>
> It's easy to do. I just haven't wanted to
> mess with the git repositories until the
> dust settles.
I understand this. I just do not want to see this dropped indefinitely,
since at some point the issue needs to be addressed.