Reminder about links when running b2 headers
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. 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. 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.
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.
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 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. In Christ, Steven Watanabe
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.
On 12/24/2013 10:49 PM, Edward Diener wrote:
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.
I think we have all reached the conclusion symbolic links are best if they work on the system. But for now there is some caution of making changes to this while so many other changes need to be be confirmed to work first.
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.
He did not say it works that way now. He said you will not need a headers_wadmin target to make it work.
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.
It will be. -- Bjørn
AMDG On 12/24/2013 02:15 PM, Bjørn Roald wrote:
On 12/24/2013 10:49 PM, Edward Diener wrote:
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.
He did not say it works that way now.
It is what I meant. It worked for me the last time I tried it.
He said you will not need a headers_wadmin target to make it work.
In Christ, Steven Watanabe
On 12/25/2013 12:55 AM, Steven Watanabe wrote:
AMDG
On 12/24/2013 02:15 PM, Bjørn Roald wrote:
On 12/24/2013 10:49 PM, Edward Diener wrote:
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.
He did not say it works that way now.
It is what I meant. It worked for me the last time I tried it.
OK I guess you did not say what I read then :-) I am not sure what you tested, but I am pretty sure Edward refer to using symbolic links for individual files rather than hard links. Not symbolic links for directories where that can be used. The latter work as it should. I have not tested but will be surprised if symbolic links for single files works on Windows7, even as user with privileges to make symbolic links. Likewise for any other system where b2 detect both types of links are supported. Hard links are preferred for single files unless that has been changed without me noticing. -- Bjørn
On 12/24/2013 07:23 PM, Bjørn Roald wrote:
On 12/25/2013 12:55 AM, Steven Watanabe wrote:
AMDG
On 12/24/2013 02:15 PM, Bjørn Roald wrote:
On 12/24/2013 10:49 PM, Edward Diener wrote:
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.
He did not say it works that way now.
It is what I meant. It worked for me the last time I tried it.
OK I guess you did not say what I read then :-)
I am not sure what you tested, but I am pretty sure Edward refer to using symbolic links for individual files rather than hard links. Not symbolic links for directories where that can be used. The latter work as it should.
You are correct. When I tried it under Windows7, even with administrative rights, the symbolic links for directories were implemented but for individual files I ended up with hard links. Subsequently after doing a 'git pull' and 'git submodule update' from the superproject I tried '.\b2 headers' again with the same result. So unless it has been changed fairly recently '.\b2 headers' doe not create symbolic links for individual files.
participants (3)
-
Bjørn Roald -
Edward Diener -
Steven Watanabe