Re: [boost] [modular boost] non-linked headers

Subject: Re: [boost] [modular boost] non-linked headers
From: Bjørn Roald (bjorn_at_[hidden])
Date: 2013-12-02 21:44:26

On 12/03/2013 03:02 AM, Beman Dawes wrote:
> On Mon, Dec 2, 2013 at 7:11 PM, Daniel James <daniel_at_[hidden]> wrote:
>
>> On 3 December 2013 00:08, Bjørn Roald <bjorn_at_[hidden]> wrote:
>>>
>>> yes, but b2 headers create hard links
>>
>> It really should use soft links. Most programs don't change files in
>> place, so as soon as such a change is made the two entries will be
>> pointing to different inodes. Which defeats the purpose, since they
>> should always be the same.
>>
>
> I'm missing something. Could you give an example of what you mean by "Most
> programs don't change files in place"? Hard links ensure that a change is
> always seen by both the entries because there is only one underlying file.
> I ran into that with Visual Studio when I tried symlinks and found that as
> a result Visual Studio failed to realize when a dependency had changed.

As you surely know, names of hardlinks are reference counted handles to 
a shared file, kind of like shared_pointers for shared memory.  I think 
the problem is that the perceived shared state could be broken the same 
way the perceived shared state of shared_pointers can if you replace the 
pointer rather than writing to the shared memory,

shared_ptr<int> pa(new int('a'));
shared_ptr<int> another_pa = pa;
shared_ptr<int> pb(new int('b'));
pa = pb;  // *pa == 'b' OK that is what we want, sort of
           // *another_pa != 'b';  // but - ouch

git could e.g. be deleting the old file in the working directory before 
checking out the new version, leaving the header link in limbo - ouch. 
I am not sure how this actually works with git though, but some web hits 
indicate such issues with git in the past.

Symbolic links would likely not have similar problem, because they are a 
reference to the name of the shared file, not the underlying storage.

--
Bjørn