Joel de Guzman wrote:
Beman Dawes wrote:
John Maddock wrote:
Beman Dawes wrote:
The changes seem to have broken a lot of other libraries tests. Failures on VC++ 8.0, for example, went from 16 to 150+.
Math and Xpressive where hit hard. This may be tough on John and Eric because both are actively working on their libraries.
Please do whatever is necessary to resolve these problems quickly. Otherwise it would be a lot better to develop on a branch. Right, and TR1 fails with:
compile-c-c++ ..\..\..\bin.v2\libs\tr1\test\test_tr1_include.test\msvc-8.0\debug \threading-multi\test_tr1_include.obj test_tr1_include.cpp ..\..\..\boost/tr1/tuple.hpp(51) : fatal error C1083: Cannot open include file: 'boost/fusion/sequence/adapted/std_pair.hpp': No such file or directory
Which in turn causes most of Boost.Math to fail :-(
So... what do we do to fix this? Obviously I could point to the new header (if you tell me where it is!) but then if we merged to the release branch without *first* merging fusion then it would break all over again - but on the release branch this time.
Double :-(
Ideas? Joel, this sounds bad. If you don't have an immediate fix, please revert you changes.
I intend to fix all the affected libraries, but I reverted anyway. Sorry for messing the build :(
Tell me how to proceed. Is the window for change already closed? If so, I'm sorry I wasn't aware of it.
The window isn't closed for run-of-the-mill code fixes, but it is closed for changes that break other libraries. Breaking changes should be made on a branch. The other affected libraries should also be changed on that branch, and then when local testing looks good the set can be committed to trunk as a single change. That way the trunk remains stable.
There are no changes to the code, just superficial header moves.
From the standpoint of release management, something that causes a platform's error count to jump from 16 to 154 doesn't look "superficial". The point isn't to shutdown major changes to libraries, but rather to use the cheap copies (aka branching) of subversion to keep the trunk stable yet allow change to happen, albeit on a branch. It is to be expected that some changes will be made to the trunk that unexpectedly break other libraries. Part of the rationale for running the smoke tests is to be able to quickly fix (or revert, if appropriate) such breakages. There have been a couple of such cases in the past week where changes broke far more than expected. But I tried not to growl too much at those developers because they quickly fixed whatever the problem was. And there have been a couple of cases where changes broke far more than expected, and the developers didn't seem to be reacting quickly to the breakage. Those are the cases where reverting seemed appropriate, so overall progress could continue while the specific issues got straightened out. --Beman --Beman