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

Subject: Re: [boost] [modular boost] non-linked headers
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2013-12-03 23:05:42

On 4/12/2013 16:32, Quoth Edward Diener:
>> Would symlinks even solve that issue?  I could be wrong, but I would
>> think that a tool or editor that followed the delete-move pattern would
>> break symlinks just as easily as hardlinks, unless they explicitly
>> followed the symlink to the "real" file and used that path in the
>> delete-move.  (And at least on Windows, most programs are not
>> symlink-aware, partly because links are fairly rare.)
>
> The delete-move pattern does not break symlinks. Since a symlink is only
> a pointer to another full file name, as long as the name remains the
> same after the delete-move the symlink still works correctly.

I was thinking of edits in the location where the symlinks appear to be, 
not where they point to.  Possibly this isn't the scenario that people 
are most worried about though.

>> Although it's true that symlinks are more obvious as such, so that might
>> possibly encourage people to edit the "real" file instead of the linked
>> version.
>
> The grammar above is confusing. If you edit the file by specifying the
> symlink location you are editing the "real" file.

AFAIK, if a symlink-unaware editor/script issues an "rm 
path-user-entered" (or equivalent API as part of a semi-atomic replace) 
then that will delete the symlink if that happens to be what is actually 
at the path-user-entered.  It will not follow the symlink and delete the 
"real" file, and so they'll be left with duplicate unlinked files again. 
  It's only safe if the path-user-entered is the "real" (target) path, 
not the symlink (or if the editor itself or something between the user 
and the editor follows the symlink first).  And hardlinks are not safe 
either way around.  That's what I was referring to above.

> Let's get Modular Boost working correctly for programmers now by
> replacing the "b2 headers" command with one that uses symlinks rather
> than hardlinks. Then if we want to consider header file placement we
> can do that as a further chore in the future.

Definitely.  Making "b2 headers" create symlinks is still probably the 
best option, as that will defend against git updates and *most* user 
edits.  It won't help if users are editing the files directly in boost/ 
(using something that uses the delete-move pattern) but that should be 
the less common case and there probably isn't much that can be done 
about that short of retraining.