Subject: Re: [boost] [Test][Thread] Regression since 9 December?
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2015-01-14 14:35:32
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:
> 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:
> 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
> 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
> Also there is an indirect inclusion of boost.timer from
> 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
* If the breaking change is accepted, propose PR for each one of the
I understand that this is more work than breaking all the users code,
but at the end you will gain.
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
* 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk