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.