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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk