Boost logo

Boost :

Subject: Re: [boost] [modular boost] non-linked headers
From: Edward Diener (eldiener_at_[hidden])
Date: 2013-12-04 02:45:43

On 12/4/2013 1:30 AM, Bjørn Roald wrote:
> 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.

Users just have to be told that the headers under boost/ are not to be
changed directly as these are all just links to headers in different
libs/. I do not think that is much of an imposition on users of Boost.
Once the headers in boost/ are all symbolic links to headers under
libs/, it is easy enough in the various OSs to find where the "real"
file resides if an end-user wants to make an experimental change.

> 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, gregod at, cpdaniel at, john at