Le 14/01/15 18:10, Raffi Enficiaud a écrit :
Please also note that there is a clash in the new and old timer API:
http://www.boost.org/development/tests/develop/developer/output/Sandia-clang...
It is impossible to use the old and new API at the same time, as there is a namespace in the old API and a class in the new API with the same name. In boost.test we chose to use the new one and drop support for the old one. This was of course before we discovered that so many problem raised.
I made the changes in boost.geometry, I am preparing a pull request for addressing these issues. Some other libraries also suffer from this apparently: - asio: looks like linking at the same time to shared and static version of system, might be generated by the changes in boost.test (I have to look further) - atomic: link missing - circular_buffer: link missing - lockfree: same as asio - numeric/ublas: link missing - pool: maybe the same as asio - tr1 : unclear what is happening here - regex: link missing - random: link missing
The problems seen on geometry/extension do not seem to be produced by the changes in boost.test: http://www.boost.org/development/tests/develop/developer/geometry-extensions...
BTW, it is hard to see the problems created by a range of commits. How to proceed? For instance, there are problems in boost.icl http://www.boost.org/development/tests/develop/developer/output/Sandia-clang... and I do not know if they were provoked by the changes in boost.test.
Tests in geometry/test/robustness/overlay/linear_areal do not compile on my machine. Also there is an indirect inclusion of boost.timer from ./include/boost/geometry/algorithms/detail/overlay/assign_parents.hpp ./include/boost/geometry/algorithms/detail/overlay/overlay.hpp
which produces a clash in the use of boost.timer.
I suggest you to : * rollback your changes related to Boost.Timer, this should make all the libraries to work as before. * create a branch on which you move to the new Timer interface and you maybe need to link to (it would be preferable to don't need it). * Announce the breaking change on this ML (yes there is a breaking change if the user needs to link to Boost.Timer and didn't needed it before). * If the breaking change is accepted, propose PR for each one of the libraries :( I understand that this is more work than breaking all the users code, but at the end you will gain. HTH, Vicente P.S. I don't know what is the state of the Boost.Test develop branch, but if I were you (I'm not) I would follow the advice given by others in other threads: * Rename the develop branch to a feature branch. * Create a develop branch from the master branch. * Fix the major issues on the develop branch in parallel with the development of the new big feature. * When the feature is ready, merge it to develop and then to master.