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