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