On 12/04/2013 05:48 PM, Steven Watanabe wrote:
AMDG
On 12/04/2013 08:04 AM, John Maddock wrote:
1) I checked out modular Boost as per https://svn.boost.org/trac/boost/wiki/TryModBoost 2) Changed libs/multiprecision to the develop branch also as per https://svn.boost.org/trac/boost/wiki/TryModBoost 3) Added some pending changes from the old SVN Trunk that I didn't commit before the changeover. 4) Ran the tests and everything failed, even though it was passing on SVN :-(
The issue was that the headers under boost/ were now *copies* of the last release and no longer pointers to the new "develop" code. Interestingly some of the hard links were updated when I ran bjam, but apparently not all :-(
Running bjam -a fixes the issue, but it's a very easy trap for the unwary.... John.
And another thing....
Ran "bjam -a headers" from the root directory to force the headers to be rebuilt, and the tests now build and pass OK... except that's a mistake because I see that old test results that depend on those headers were *not* rebuilt. So you need to bjam -a from the libs/mylib/test directory as well whenever you change branches :-(
The reason that this is failing is probably that the timestamps on some of the headers that you copied in were older than the timestamps on the original.
Some thoughts: Assuming we have changed b2 headers to prefer symlink for individual files: Then, in the cases where hardlinks are still used by b2 headers, does it not make sense for b2 headers to always, unconditionally fix all hardlinks -- all the time...? Maybe even a post checkout/reset hook in git where the b2 headers command is allowed to fail with a warning only. On platforms where copy is still used by b2 headers, forced unconditional copy would trigger redundant rebuild and would make no sense. However with a content change detection based condition for the copy, forced copy may make a lot of sense. Maybe even better if it is possible to also set filetime on the copy to the same as the original. I do not think we should attempt to do this in both directions, as it complicates too much to be worth it -- so this would not fix all potential issues with copies, but maybe the more surprising ones that are not self inflicted by editing files directly in the boost folders. -- Bjørn