On 18/06/2014 09:29, Bjørn Roald wrote:
On 06/17/2014 10:46 AM, Peter Dimov wrote:
When I edit in boost/ - which I never do - when I run the tests, b2 then sees the file as modified, but does not update the link in boost/ (the link being newer than the source in include/.)
When I edit in include/ - which is what I do - b2 sees the file as modified and updates the link in boost/ to point to it.
Good! but even if all are fixed, it is not good to have these subtle issues where users have to be careful. Part of the problem is that many tools such as IDE's with built-in symbol browsing, debugers etc. will lead users to those headers they should not edit.
Perhaps b2 could check both timestamps are equal and sync bidirectionally? Copied or hardlinked files should have the same timestamp (not sure about symlinks, but they should probably be ignored anyway since they won't have this issue), and both manually edited or freshly git-updated files should have a newer timestamp than their counterpart (modulo possible 2 second filesystem resolution). The only thing I can envisage possibly tripping this up is if someone untars/unzips a fresh release build over the top of their existing tree, which could potentially have older timestamps than the counterpart files, if the user has been editing them. (Especially if they're using the same release build as previous, to try to revert to originals.) But that seems like a case in which users ought to have cleaned the tree first in any event, and shouldn't be an issue for upgrades, as those have different dir names embedded in the archive. Although I suspect most users using release builds will not run b2 more than once anyway.