On 12/3/2013 5:22 PM, Gavin Lambert wrote:
On 4/12/2013 02:24, Quoth Beman Dawes:
This can be fixed by running 'b2 headers' again, but this isn't something that should be relied on - people use other build tools. I also wonder if there's a possibility that 'b2 headers' will choose the wrong file.
Soft links also have other advantages, they make it clear which module the header file came from, and it's more immediately obvious that file is linked - especially in graphical tools.
I have no objection to changing to symlinks as the default behavior.
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.
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.
Would it be possible to link only at the whole-directory level, rather than individual files? I think behaviour is much more stable and desirable that way (and it should fix the make-timestamp issue too). To support this, the top-level headers could be owned by the main repository, and (where not already) just be a thin redirect into the "real" headers in the library's linked subdir.
It would mean a bit of restructuring for some of the older libraries, but that's probably a good thing overall for modularisation.
Certainly this could be done, but I see no necessity for it if symlinks are used, other than a possibly better design of some header file locations. 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.