Subject: Re: [boost] [modular boost] non-linked headers
From: Edward Diener (eldiener_at_[hidden])
Date: 2013-12-02 20:01:42
On 12/2/2013 7:08 PM, Bjørn Roald wrote:
> On 12/03/2013 12:39 AM, Edward Diener wrote:
>> On 12/2/2013 5:29 PM, Bjørn Roald wrote:
>>> On 12/02/2013 10:45 PM, Edward Diener wrote:
>>>> On Windows after the .\b2 headers step, there are these directories
>>>> under the modular-boost/boost diectory which are not symbolic links:
>>> It is because they have more than one source directory, so a symbolic
>>> link will not do what is needed.
>> Symbolic links can be created to individual files also.
> yes, but b2 headers create hard links rather than symbolic links
> individual files on platforms supporting hardlinks. If you have no
> simple way of checking if you got hardlinks, simply try to modify one to
> see if you have a link or a copy. Windows have had hardlinks since at
> least XP, so if it does not work for you it is a bug I think.
> b2 headers will fall back to copy if that is the only thing supported I
> think, or that is what it should do.
>>> I do not think windows is changing
>>> anything unless you are on a version not supporting symbolic links.
>>> $ find libs -name detail | grep include/boost/detail
>> Just looking at detail we are evidently creating duplicating files
>> rather than creating symbolic links to files.
>> For instance in libs/detail, which is a submodule, we have
>> allocator_utilities.hpp. In boost/detail we have
>> allocator_utilities.hpp. Let us suppose that the
>> libs/detail/allocator_utilities.hpp gets updated in git. When this
>> happens, how is the boost/detail/allocator_utilities.hpp supposed to be
>> updated if it is an entirely separate file ?
> It wan't get updated. And that is a major pain for any platforms that
> don't support links. But links should work on any "normal" development
> host computer these days.
I see now that the boost/detail/allocator_utilities.hpp is a hard link.
Unfortunately Windows doesn't normally indicate hard links either in
Explorer or via the 'dir' command. One must use a shell extension or the
'fsutil hardlink list xxx' command to get that information.
I assume then that git never deletes a file and recreates it with the
same name when the file is updated, else the hardlink would no longer be
pointing to the same file and the purpose of having a hardlink, as
opposed to a symbolic link, would be defeated.