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-04 01:30:59

On 12/04/2013 05:05 AM, Gavin Lambert wrote:
> 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.

neither solution is fail safe for all scenarios.  Developers need to be 
aware that header changes *shall* go in the libs/*/inblude/boost/... 
structure.  The links are for convenience of build tools, debuggers, 
etc. and for the accidental edit you do when you IDE take you there.

I would be surprised if current solution creates many issues used this 
way.  However I believe using symlinks is more robust, so we should 
change current order of preference in b2 headers from:

symlink dir
hardlink file
symlink file
copy

to prefer:

symlink dir
symlink file
hardlink file
copy

>> 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.

+1

> 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.

I don't see much chance for a text editor to do the wrong thing here. 
If it did, you will get the same effect as with a copy of the header -- 
the first clean build would overwrite your changes.

--
Bjørn