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

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.

+1

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

+1

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