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:
detail
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 libs/optional/include/boost/detail libs/detail/include/boost/detail libs/thread/include/boost/detail libs/config/include/boost/detail libs/smart_ptr/include/boost/detail libs/utility/include/boost/detail libs/conversion/include/boost/detail libs/graph/include/boost/detail libs/dynamic_bitset/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.