Boost.test failures in develop

newer
[regression] new runner missing in...

Aparna Kumta

1 Oct 2015 1 Oct '15

3:35 a.m.

Compiling with Oracle Solaris Studio on sparc-S2 platform with -library=stlport4, I see the following failure in the develop branch: "CC" -library=stlport4 -xO4 -mt -erroff=%none -m32 -KPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_CHRONO_DYN_LINK=1 -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_TEST_DYN_LINK=1 -DBOOST_TIMER_DYN_LINK=1 -DNDEBUG -D__typeof__=__typeof__ -I".." -c -o "/export/home/b_dev/results/boost/bin.v2/libs/test/build/sun/release/stdlib-sun-stlport/threading-multi/unit_test_parameters.o" "../libs/test/src/unit_test_parameters.cpp" "../boost/test/utils/runtime/errors.hpp", line 75: Error: Templates can only declare classes or functions. "../boost/test/utils/runtime/errors.hpp", line 86: Error: Templates can only declare classes or functions. "../boost/test/utils/runtime/errors.hpp", line 124: Error: ")" expected instead of "&&". "../boost/test/utils/runtime/errors.hpp", line 133: Error: ")" expected instead of "&&". "../boost/test/utils/named_params.hpp", line 69: Error: Unexpected type name "Rest" encountered. "../boost/test/utils/named_params.hpp", line 69: Error: Unexpected ":" found. "../boost/test/utils/named_params.hpp", line 205: Error: Unexpected type name "Rest" encountered. "../boost/test/utils/named_params.hpp", line 205: Error: operator, is not defined. "../boost/test/utils/named_params.hpp", line 205: Error: "," expected instead of ";". ... Compilation aborted, too many Error messages. It seems that the code contains rvalue reference and hence the compiler is not able to build it in C++03 mode. This seems to be a recent change preventing building of libboost_unit_test_framework.a and hence causing several tests to fail. Thanks, Aparna

Show replies by date

Gennadiy Rozental

1 Oct 1 Oct

6:47 a.m.

Aparna Kumta writes:

...

It seems that the code contains rvalue reference and hence the compiler is not able to build it in C++03 mode.

Why do you want to use C++03 mode? Gennadiy

Adam Wulkiewicz

10:39 a.m.

Gennadiy Rozental wrote:

...

Aparna Kumta writes:

...
It seems that the code contains rvalue reference and hence the compiler is not able to build it in C++03 mode. Why do you want to use C++03 mode?

Test is failing from various reasons with any compiler without C++11 support. See e.g.: http://www.boost.org/development/tests/develop/developer/geometry.html Regards, Adam

Barend Gehrels

7:25 p.m.

Op 1-10-2015 om 12:39 schreef Adam Wulkiewicz:

...

Gennadiy Rozental wrote:

...
Aparna Kumta writes:

...
It seems that the code contains rvalue reference and hence the compiler is not able to build it in C++03 mode. Why do you want to use C++03 mode?

Test is failing from various reasons with any compiler without C++11 support. See e.g.: http://www.boost.org/development/tests/develop/developer/geometry.html

Oops, this is looking very very bad now. The matrix was all green (except for just a few boxes) until one or a few weeks ago. Gennadiy, can you fix or revert this change as soon as possible? Thanks, Barend

Gennadiy Rozental

9:02 p.m.

Adam Wulkiewicz writes:

...

Gennadiy Rozental wrote:

...
Aparna Kumta writes:

...
It seems that the code contains rvalue reference and hence the compiler is not able to build it in C++03 mode. Why do you want to use C++03 mode?

Test is failing from various reasons with any compiler without C++11 support. See e.g.: http://www.boost.org/development/tests/develop/developer/geometry.html

It is almost 2016. How much longer do we plan to test against c++03? I'm with Bjarne here: it is time to move to c++11 enabled world - we all going to be better for it. I'll see if anything obvious can be fixed. Gennadiy

Adam Wulkiewicz

9:53 p.m.

New subject: [test] Boost.test failures in develop

Gennadiy Rozental wrote:

...

Adam Wulkiewicz writes:

...
Gennadiy Rozental wrote:

...
Aparna Kumta writes:

...
It seems that the code contains rvalue reference and hence the compiler is not able to build it in C++03 mode. Why do you want to use C++03 mode? Test is failing from various reasons with any compiler without C++11 support. See e.g.: http://www.boost.org/development/tests/develop/developer/geometry.html It is almost 2016. How much longer do we plan to test against c++03? I'm with Bjarne here: it is time to move to c++11 enabled world - we all going to be better for it.

In general I agree with you but the reality is that currently all (or nearly all?) Boost libraries support c++03 and there are more c++03 test runners than c++11 ones. Some of our users cannot move to c++11. Are you saying that the support for c++03 in Test was dropped or will be in the near future? If that's the case shouldn't rather another module e.g. Test2 be created instead? Now it's a regression, see the Test matrix: http://www.boost.org/development/tests/develop/developer/test.html. Some other libraries are affected as well.

...

I'll see if anything obvious can be fixed.

Thanks! Regards, Adam

Gennadiy Rozental

4 Oct 4 Oct

6:53 a.m.

New subject: [test] Boost.test failures in develop

Adam Wulkiewicz writes:

...

In general I agree with you but the reality is that currently all (or nearly all?) Boost libraries support c++03 and there are more c++03 test runners than c++11 ones.

I do not believe so. By my count about 10 out of 50 are c++03. Some of our users cannot move to c++11.

...

Are you saying that the support for c++03 in Test was dropped or will be in the near future?

At some near point in a future. I do not have resources to maintain two branches of the library. Older releases are there forever. Anyone interested in c++03 compatible version can download it without ny problems.

...

If that's the case shouldn't rather another module e.g. Test2 be created instead?

Who is going to support old module? I do not have c++03 compatible setup anywhere. IMO, we need to make a boost wide decision to stop making c++03 workarounds. There is no reason to develop new code, which is bound to c++03 compatibility. Anyone interested in old code can use older releases of boost.

Andrey Semashev

9:18 a.m.

New subject: [test] Boost.test failures in develop

On 04.10.2015 09:53, Gennadiy Rozental wrote:

...

Adam Wulkiewicz writes:

...
In general I agree with you but the reality is that currently all (or nearly all?) Boost libraries support c++03 and there are more c++03 test runners than c++11 ones.

I do not believe so. By my count about 10 out of 50 are c++03.

There are 118 directories in libs, each of them roughly correspond to a library. Out of them, from the top of my head, only Boost.Context2 and Boost.VMD strictly do not support C++03. There are 36 Jamfiles that indicate dependency on Boost.Test.

...

...
Are you saying that the support for c++03 in Test was dropped or will be in the near future?

At some near point in a future. I do not have resources to maintain two branches of the library. Older releases are there forever. Anyone interested in c++03 compatible version can download it without ny problems.

This makes Boost.Test unsuitable for testing Boost libraries that support C++03 (currently - nearly all). Are you suggesting to start porting tests from Boost.Test to another testing framework?

Gennadiy Rozental

9:59 a.m.

New subject: [test] Boost.test failures in develop

Andrey Semashev writes:

...

On 04.10.2015 09:53, Gennadiy Rozental wrote:

...
Adam Wulkiewicz writes:

...
In general I agree with you but the reality is that currently all (or nearly all?) Boost libraries support c++03 and there are more c++03

test

...

...
...
runners than c++11 ones.

I do not believe so. By my count about 10 out of 50 are c++03.

There are 118 directories in libs, each of them roughly correspond to a library. Out of them, from the top of my head, only Boost.Context2 and Boost.VMD strictly do not support C++03. There are 36 Jamfiles that indicate dependency on Boost.Test.

I was counting runners, not libraries. Majority of these are c++11 enabled

...

...
...
Are you saying that the support for c++03 in Test was dropped or will

...

...
...
in the near future?

At some near point in a future. I do not have resources to maintain two branches of the library. Older releases are there forever. Anyone interested in c++03 compatible version can download it without ny problems.

This makes Boost.Test unsuitable for testing Boost libraries that support C++03 (currently - nearly all). Are you suggesting to start porting tests from Boost.Test to another testing framework?

No need. We'll figure something out. I hope we just decide to forget about c++03 in near future (by 'we' I mean boost community). Why would you fight for maintaining the compatibility? Many people do not have access to these compilers anymore. I, for example, pretty much will have to use develop branch to test compilation and tests. Gennadiy

Rob Stewart

5 Oct 5 Oct

8:51 a.m.

New subject: [test] Boost.test failures in develop

On October 4, 2015 5:59:16 AM EDT, Gennadiy Rozental wrote:

...

Andrey Semashev writes:

...
This makes Boost.Test unsuitable for testing Boost libraries that support C++03 (currently - nearly all). Are you suggesting to start porting tests from Boost.Test to another testing framework?

No need. We'll figure something out. I hope we just decide to forget about c++03 in near future (by 'we' I mean boost community). Why would you fight for maintaining the compatibility? Many people do not have access to these compilers anymore. I, for example, pretty much will have to use develop branch to test compilation and tests.

Where's your data on the number of people with and without access to "these compilers"? GCC and Clang require options to enable C++11/4, or at least did in fairly recent versions. That means changing a flag enables C++03 mode. Note also that many corporate users cannot yet switch to C++11 for many reasons, and they are often required to justify the use of Boost, which is easier to do as a while than one library at a time. The result of the foregoing is that many Boost libraries continue to support C++03 either by maintaining separate versions or through conditional compilation. Maintenance of an old version can mean nothing more than adjusting to changes in core libraries. Note that arguing that users can use older versions of Boost is unhelpful since that denies those users access to new libraries, or fixes to current libraries, even if those libraries support C++03. The choice to support C++03 lies with the library maintainer(s). The consequences of dropping that support may be good or bad and will vary with each library. For Boost.Test, doing so means that any Boost library that continues to support C++03 will have to switch to another test framework. Many have already made that switch, of course, for various reasons. The decision is yours. ___ Rob (Sent from my portable computation engine)

Adam Wulkiewicz

10:49 a.m.

New subject: [test] Boost.test failures in develop

Gennadiy Rozental wrote:

...

Adam Wulkiewicz writes:

...
In general I agree with you but the reality is that currently all (or nearly all?) Boost libraries support c++03 and there are more c++03 test runners than c++11 ones. I do not believe so. By my count about 10 out of 50 are c++03.

I'm not sure what you're counting, probably you're looking at the Test failures here: http://www.boost.org/development/tests/develop/developer/test.html I'm counting the yellow columns here: http://www.boost.org/development/tests/develop/developer/geometry.html Those failures are all caused by the changes in Test, I should rather say "regression". Correct me if I'm wrong but isn't the Test passing in more cases than Geometry only because -std=c++11 flag is defined in a Jamfile: https://github.com/boostorg/test/blob/develop/test/Jamfile.v2#L34 which is altering runners' setups and introducing a bias into the results?

...

Some of our users cannot move to c++11.

This is the reason why Test should support c++03, isn't it?

...

...
Are you saying that the support for c++03 in Test was dropped or will be in the near future? At some near point in a future. I do not have resources to maintain two branches of the library. Older releases are there forever. Anyone interested in c++03 compatible version can download it without ny problems.

Boost libraries authors cannot do that. Are you saying that the regression testing should always use e.g. Test master branch even in develop? I believe it's not that simple. Or that all Boost libraries supporting c++03 should not use Test anymore?

...

...
If that's the case shouldn't rather another module e.g. Test2 be created instead? Who is going to support old module? I do not have c++03 compatible setup anywhere. I was thinking about leaving the old Test nearly unmaintained so it could be used by the libraries the same way as in the past. Some of the authors already have choosen to do it (except I'm not sure about the "unmaintained" part) because the new interface of a library was designed (e.g. Signals, Spirit, MPL). And you could work on a new version requireing c++11 in a separate module. And I'm not saying that the entirely new code should be written. You could copy the content of the Test and just build on top of it in this new module.

...

IMO, we need to make a boost wide decision to stop making c++03 workarounds. There is no reason to develop new code, which is bound to c++03 compatibility. Anyone interested in old code can use older releases of boost. This is not reasonable since it'd require from the user to manually replace only the Boost.Test code with some older version released in the past or stop using Test. Everything the libraries authors are dealing with now could more or less be an issue for the users.

By "workarounds", do you mean conditionally-enabled features? You'll always have some workarounds/#ifdefs, if not for c++03 then for c++11, c++14, etc. Regards, Adam

Gennadiy Rozental

8:35 p.m.

New subject: [test] Boost.test failures in develop

Adam Wulkiewicz writes:

...

...
I do not believe so. By my count about 10 out of 50 are c++03.

I'm not sure what you're counting,

I count configuration running c++11 capable compilers. gcc 4.8 is c++11 capable regardless if decide to test in in c++03 mode or not.

...

...
There is no reason to develop new code, which is bound to c++03 compatibility. Anyone interested in old code can use older releases of boost. This is not reasonable since it'd require from the user to manually replace only the Boost.Test code with some older version released in the past or stop using Test. Everything the libraries authors are dealing with now could more or less be an issue for the users.

My claim was: there is little reason for user bound to c++03 to upgrade to new version of boost in a first place.

...

By "workarounds", do you mean conditionally-enabled features? You'll always have some workarounds/#ifdefs, if not for c++03 then for c++11, c++14, etc.

That's true, but problem grows exponentially once you try to maintain some combination of c++03, c++11, c++14, c++17 (and so on) code. At some point code becomes unreadable and thus very difficult to maintain. Gennadiy

Andrey Semashev

8:54 p.m.

New subject: [test] Boost.test failures in develop

On 05.10.2015 23:35, Gennadiy Rozental wrote:

...

Adam Wulkiewicz writes:

...
...
There is no reason to develop new code, which is bound to c++03 compatibility. Anyone interested in old code can use older releases of boost. This is not reasonable since it'd require from the user to manually replace only the Boost.Test code with some older version released in the past or stop using Test. Everything the libraries authors are dealing with now could more or less be an issue for the users.

My claim was: there is little reason for user bound to c++03 to upgrade to new version of boost in a first place.

This is not true. We don't do point releases, so bug fixes can be either obtained by upgrading to a newer Boost release or by patching the old Boost locally. We may not like it, our users most probably don't like it, but that's how things are currently. Until this changes, users will have a very valid reason to upgrade to every new Boost release. Let alone the new features, which may still be desired in C++03 user's code.

Adam Wulkiewicz

9:50 p.m.

New subject: [test] Boost.test failures in develop

Gennadiy Rozental wrote:

...

Adam Wulkiewicz writes:

...
...
I do not believe so. By my count about 10 out of 50 are c++03. I'm not sure what you're counting, I count configuration running c++11 capable compilers. gcc 4.8 is c++11 capable regardless if decide to test in in c++03 mode or not.

Only if by saying "c++11 capable" you have in mind that it has an _experimental_ support of nearly all of the features of c++11. You forget about a fact that the user must want to enable the support for them. There are users which cannot afford compiling the code using an unstable compiler. Which btw means that the runner's setup shouldn't be altered in a Jamfile. If a runner desires to test Boost passing specific compiler flags he should be able to do it. We should at least be honest and say that Test doesn't work if compiled against the default STD version supported by a compiler.

...

...
...
There is no reason to develop new code, which is bound to c++03 compatibility. Anyone interested in old code can use older releases of boost. This is not reasonable since it'd require from the user to manually replace only the Boost.Test code with some older version released in the past or stop using Test. Everything the libraries authors are dealing with now could more or less be an issue for the users. My claim was: there is little reason for user bound to c++03 to upgrade to new version of boost in a first place.

This is so untrue. I don't know how the majority of the industry works but at least in a part I know about the reality looks different than you think. Believe it or not but there are companies which are bound to c++03 simply because they're shipping some major version of a product on a particular OS comming with a specific compiler. And in the same time they want the latest Boost features and bugfixes so they're compiling against develop branch of a library.

...

...
By "workarounds", do you mean conditionally-enabled features? You'll always have some workarounds/#ifdefs, if not for c++03 then for c++11, c++14, etc. That's true, but problem grows exponentially once you try to maintain some combination of c++03, c++11, c++14, c++17 (and so on) code. At some point code becomes unreadable and thus very difficult to maintain.

It's obvious that there is an additional maintenance cost when more is supported. To be perfectly clear. I have nothing against Test dropping the support for c++03. It's up to the library author or maintainer what he will do with the library. My point is that this is a breaking change, a regression, and that there should at least be some planning involved, an announcement on the list that the support will be dropped so everyone would be able to prepare accordingly. Preferably a solution for those who don't want to use the new version or at least a clear declaration that there is not and there will be no such solution followed by some period of time when the libraries could drop the Test dependency, at least in those libraries which have a maintainer. Since we already have a rather unpleasant announcement behind us it's a good time for planning and a clear declaration. "I won't fix Test and simply move to c++11" would be ok too. Anything that allows to do some planning. Regards, Adam

Raffi Enficiaud

6 Oct 6 Oct

9:11 a.m.

New subject: [test] Boost.test failures in develop

Le 05/10/15 23:50, Adam Wulkiewicz a écrit :

...

Gennadiy Rozental wrote:

Only if by saying "c++11 capable" you have in mind that it has an _experimental_ support of nearly all of the features of c++11. You forget about a fact that the user must want to enable the support for them. There are users which cannot afford compiling the code using an unstable compiler.

Which btw means that the runner's setup shouldn't be altered in a Jamfile. If a runner desires to test Boost passing specific compiler flags he should be able to do it. We should at least be honest and say that Test doesn't work if compiled against the default STD version supported by a compiler.

We will fix this.

...

[snip]

This is so untrue. I don't know how the majority of the industry works but at least in a part I know about the reality looks different than you think. Believe it or not but there are companies which are bound to c++03 simply because they're shipping some major version of a product on a particular OS comming with a specific compiler.

It also happened to me, but what works best in that case what is to stick to a specific version and backport the fixes, which is much easier (because selective) than sourcing a new version of boost with hundreds of changes. If they need a new version, they first test if it works for them and increment their version if everything is alright. Companies that heavily depend on a setup do that: they have to control the build environment totally, which means also the specific versions of their dependencies. There is a little bit of a control in production environments, and the desire of upgrading is less important than the overall functional stability of the products.

...

And in the same time they want the latest Boost features and bugfixes so they're compiling against develop branch of a library.

I strongly disagree on the fact that develop branch has some contract with end users. Develop branch has mainly a testing and packaging value wrt. other libraries of boost, so the merges to master are cleaner and the potential coupling of libraries is properly handled. If some end user wants the latest bug fixes from develop branch, it's his choice to have a code that potentially breaks his/her code. I would say it is also the same for master. I believe there is a big release effort at every release of boost to get things done properly, and this effort is not performed in between. Also the bug fixes are hardly announced nor published, and until there is no announcement, there is no commitment from boost side. So it is up to the end users if they want to upgrade from master: they might source a code that might break a contract.

...

[snip]

To be perfectly clear. I have nothing against Test dropping the support for c++03. It's up to the library author or maintainer what he will do with the library. My point is that this is a breaking change, a regression, and that there should at least be some planning involved, an announcement on the list that the support will be dropped so everyone would be able to prepare accordingly. Preferably a solution for those who don't want to use the new version or at least a clear declaration that there is not and there will be no such solution followed by some period of time when the libraries could drop the Test dependency, at least in those libraries which have a maintainer. Since we already have a rather unpleasant announcement behind us it's a good time for planning and a clear declaration. "I won't fix Test and simply move to c++11" would be ok too. Anything that allows to do some planning.

Talking about planning, I would like to know - what is the policy of boost wrt. deprecation warnings? My opinion is that deprecation warnings, either from the compilation perspective or usage (eg. from the command line) is the best way to push the changes on the end user side. But I do not know what boost says about that. On boost.test side, we want to deprecate some headers, function and macros, as well as runtime arguments. - apart from public announcement of deprecation, is there currently any other way or good practice for making changes to the public API? - if there is a deprecation, what is the amount of time before the deprecated feature is dropped, in terms of releases or years? Is boost clear on that or is it on the hands of the library maintainers? I think it would be good to unify this. Best, Raffi

Adam Wulkiewicz

9:27 a.m.

New subject: [test] Boost.test failures in develop

Raffi Enficiaud wrote:

...

Le 05/10/15 23:50, Adam Wulkiewicz a écrit :

...
[snip]

This is so untrue. I don't know how the majority of the industry works but at least in a part I know about the reality looks different than you think. Believe it or not but there are companies which are bound to c++03 simply because they're shipping some major version of a product on a particular OS comming with a specific compiler.

It also happened to me, but what works best in that case what is to stick to a specific version and backport the fixes, which is much easier (because selective) than sourcing a new version of boost with hundreds of changes. If they need a new version, they first test if it works for them and increment their version if everything is alright.

Companies that heavily depend on a setup do that: they have to control the build environment totally, which means also the specific versions of their dependencies. There is a little bit of a control in production environments, and the desire of upgrading is less important than the overall functional stability of the products.

...
And in the same time they want the latest Boost features and bugfixes so they're compiling against develop branch of a library.

I strongly disagree on the fact that develop branch has some contract with end users. Develop branch has mainly a testing and packaging value wrt. other libraries of boost, so the merges to master are cleaner and the potential coupling of libraries is properly handled. If some end user wants the latest bug fixes from develop branch, it's his choice to have a code that potentially breaks his/her code.

I would say it is also the same for master. I believe there is a big release effort at every release of boost to get things done properly, and this effort is not performed in between. Also the bug fixes are hardly announced nor published, and until there is no announcement, there is no commitment from boost side. So it is up to the end users if they want to upgrade from master: they might source a code that might break a contract.

Maybe I shouldn't use develop branch in my example, sorry for confusion. My point is that there are users out there who are forced to compile against c++03 and the latest Boost version. Or as in the example going even beyond this. <snip> Regards, Adam

Stephen Kelly

6:27 p.m.

New subject: [test] Boost.test failures in develop

Raffi Enficiaud wrote:

...

Develop branch has mainly a testing and packaging value wrt. other libraries of boost, so the merges to master are cleaner and the potential coupling of libraries is properly handled.

I'm very interested in this! How is potential coupling of libraries handled? Thanks, Steve.

Jürgen Hunold

7 Oct 7 Oct

10:20 a.m.

New subject: [test] Boost.test failures in develop

Hi Raffi, Am Dienstag, 6. Oktober 2015, 11:11:16 schrieb Raffi Enficiaud:

...

Talking about planning, I would like to know

- what is the policy of boost wrt. deprecation warnings? My opinion is that deprecation warnings, either from the compilation perspective or usage (eg. from the command line) is the best way to push the changes on the end user side. But I do not know what boost says about that. On boost.test side, we want to deprecate some headers, function and macros, as well as runtime arguments.

Most libraries use deprecation warnings like #if defined(__GNUC__) || defined(_MSC_VER) # pragma message("NOTE: Use of this header (boost/type_traits/broken_compiler_spec.hpp) is deprecated") #endif at least for whole headers. A simple grep for "DEPRECATION" reveals several libraries using conditional compilation, too.

...

- apart from public announcement of deprecation, is there currently any other way or good practice for making changes to the public API?

Besides a fat warning in the header, no. Modern compilers support "__declspec(deprecated)" and "__declspec(deprecated(message))" mechanism. Adding support for this to Boost.Config would allow to deprecate single functions etc. That is the way Qt does handle deprecation.

...

- if there is a deprecation, what is the amount of time before the deprecated feature is dropped, in terms of releases or years? Is boost clear on that or is it on the hands of the library maintainers? I think it would be good to unify this.

As usual, a maintainer decision. I'd like to have 3 release (aka 1 year) as minimum. Longer periods don't really make sense, as the user base is divided into an "update early" and an "update only in emergency/feature need" partitions. And for the latter even 5 years might be too short... Just my 0.02€ And by the way, can you publish the "boost_run_test" CMake function used in Boost.Test? This would make adapting my own CMake rules easier. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold@gmx.eu ! Germany

Raffi Enficiaud

12:29 p.m.

New subject: [test] Boost.test failures in develop

Le 07/10/15 12:20, Jürgen Hunold a écrit :

...

Hi Raffi,

Most libraries use deprecation warnings like

#if defined(__GNUC__) || defined(_MSC_VER) # pragma message("NOTE: Use of this header (boost/type_traits/broken_compiler_spec.hpp) is deprecated") #endif

at least for whole headers. A simple grep for "DEPRECATION" reveals several libraries using conditional compilation, too.

Hi Jürgen, Thank you for those information. Maybe also transforming the warning into an error after some increment of release...

...

...
- apart from public announcement of deprecation, is there currently any other way or good practice for making changes to the public API?

Besides a fat warning in the header, no. Modern compilers support "__declspec(deprecated)" and "__declspec(deprecated(message))" mechanism. Adding support for this to Boost.Config would allow to deprecate single functions etc. That is the way Qt does handle deprecation.

I was expecting some support in boost.config for that for having it clean, but apparently there is nothing.

...

...
- if there is a deprecation, what is the amount of time before the deprecated feature is dropped, in terms of releases or years? Is boost clear on that or is it on the hands of the library maintainers? I think it would be good to unify this.

As usual, a maintainer decision. I'd like to have 3 release (aka 1 year) as minimum. Longer periods don't really make sense, as the user base is divided into an "update early" and an "update only in emergency/feature need" partitions. And for the latter even 5 years might be too short...

Ok thanks.

...

And by the way, can you publish the "boost_run_test" CMake function used in Boost.Test? This would make adapting my own CMake rules easier.

This is an old unmaintained CMakeLists.txt that I should remove at some point. I believe this is pointing to the boost-cmake project. I have my own though, see the branch topic/CMakelist-txt (or commit 8fac3b6 on develop). Raffi

Barend Gehrels

1 Oct 1 Oct

9:55 p.m.

Op 1-10-2015 om 23:02 schreef Gennadiy Rozental:

...

Adam Wulkiewicz writes:

...
Gennadiy Rozental wrote:

...
Aparna Kumta writes:

...
It seems that the code contains rvalue reference and hence the compiler is not able to build it in C++03 mode. Why do you want to use C++03 mode? Test is failing from various reasons with any compiler without C++11 support. See e.g.: http://www.boost.org/development/tests/develop/developer/geometry.html It is almost 2016. How much longer do we plan to test against c++03? I'm with Bjarne here: it is time to move to c++11 enabled world - we all going to be better for it.

You cannot just drop (if I'm correct it is dropped without even any notice) c++03 from your Boost.Test library which is used by many libraries which indeed stilll do support c++03. It is still widely used and even though it is indeed time to change, that will still take much time.

...

I'll see if anything obvious can be fixed.

Good, thanks! Regards, Barend

Gennadiy Rozental

4 Oct 4 Oct

7:58 a.m.

Barend Gehrels writes:

...

You cannot just drop (if I'm correct it is dropped without even any notice) c++03 from your Boost.Test library which is used by many libraries which indeed still do support c++03.

IMO anything is dropped automatically as soon as developers do not have access to the testing environment. IMO, practically, most boost developers already in a situation where c++03 testing is not easily available or require unnecessary large effort to maintain (if your code written using C++11 feature, implementing these in C++03 compatible manner can be rather time consuming). At the moment I am looking for possibility to completely disable parts of the framework in C++03 mode. Sooner or later it will not be possible anymore (for example, to make UTF thread safe I might need c++11 features across the board).

...

It is still widely used

Do you have any data confirming this?

...

and even though it is indeed time to change, that will still take much time.

Why? It is just boost community decision: we do not implement c++03 workarounds in a new code anymore. Old code is still available in older releases. Gennadiy

Rob Stewart

9:54 a.m.

On October 4, 2015 3:58:33 AM EDT, Gennadiy Rozental wrote:

...

Barend Gehrels writes:

...
You cannot just drop (if I'm correct it is dropped without even any notice) c++03 from your Boost.Test library which is used by many libraries which indeed still do support c++03.

IMO anything is dropped automatically as soon as developers do not have access to the testing environment. IMO, practically, most boost developers already in a situation where c++03 testing is not easily available or require unnecessary large effort to maintain (if your code written using C++11 feature, implementing these in C++03 compatible manner can be rather time consuming).

At the moment I am looking for possibility to completely disable parts of the framework in C++03 mode. Sooner or later it will not be possible anymore (for example, to make UTF thread safe I might need c++11 features across the board).

Boost.Test should not drop C++03 support until all Boost libraries using it drop C++03 support, period. There is no hardship on Boost.Test maintainers to continue that support, though it may limit advancements. Doing otherwise forces the adoption of another test framework. If there are insufficient testing resources to ensure C++03 coverage, then Boost may decide to drop C++03 support or may reallocate testing resources. Either way, that isn't the Boost.Test maintainers' call, if Boost.Test is to remain viable. ___ Rob (Sent from my portable computation engine)

Robert Ramey

1 Oct 1 Oct

10:33 p.m.

On 10/1/15 2:02 PM, Gennadiy Rozental wrote:

...

Adam Wulkiewicz writes:

...

It is almost 2016. How much longer do we plan to test against c++03? I'm with Bjarne here: it is time to move to c++11 enabled world - we all going to be better for it.

We're going to test against whatever testers want to test against. And testers are going test against what testers use. It can't be any other way. Maybe what you want to suggest is that we include a little metadata in each library indicated the C++ revision requirements so that the test system can automatically skip those libraries which the tester doesn't want or is not able to test against. The column for that tester just wouldn't appear when not relevant. Robert Ramey

Gennadiy Rozental

4 Oct 4 Oct

8:03 a.m.

Robert Ramey writes:

...

Maybe what you want to suggest is that we include a little metadata in each library indicated the C++ revision requirements so that the test system can automatically skip those libraries which the tester doesn't want or is not able to test against. The column for that tester just wouldn't appear when not relevant.

The the worst idea. We can also check corresponding tags on all dependant libraries and indicate which one is not available in target configuration. It would also be nice to have an ability to specify which release of the dependency I want to build against. unit_test_framework:master - will indicate master branch, unit_test_framework:develop - develop branch. unit_test_framework:1.59.0 - corresponding tag. I believe we spoke about this at some point, but with git move everything else seem to be forgotten. Gennadiy

Tom Kent

3 Oct 3 Oct

1:05 a.m.

On Thu, Oct 1, 2015 at 4:02 PM, Gennadiy Rozental wrote:

...

Adam Wulkiewicz writes:

...
Gennadiy Rozental wrote:

...
Aparna Kumta writes:

...
It seems that the code contains rvalue reference and hence the

compiler

...
...
...
is not able to build it in C++03 mode. Why do you want to use C++03 mode?

Test is failing from various reasons with any compiler without C++11 support. See e.g.: http://www.boost.org/development/tests/develop/developer/geometry.html

It is almost 2016. How much longer do we plan to test against c++03? I'm with Bjarne here: it is time to move to c++11 enabled world - we all going to be better for it.

I'll see if anything obvious can be fixed.

I'm all for libraries that only support C++11 going forward and even investigating phasing out support from existing libraries. However, the test library will have to be one of the last ones to stop supporting C++03 compilers because as long as there are other C++03 libraries in boost, it will still have to support testing them. Unfortunately I know lots of places that are still using msvc-8.0, so I don't see that full move happening any time soon :-( Tom

Andrzej Krzemienski

9:08 a.m.

2015-10-03 3:05 GMT+02:00 Tom Kent :

...

On Thu, Oct 1, 2015 at 4:02 PM, Gennadiy Rozental wrote:

...
Adam Wulkiewicz writes:

...
Gennadiy Rozental wrote:

...
Aparna Kumta writes:

...
It seems that the code contains rvalue reference and hence the

compiler

...
...
...
is not able to build it in C++03 mode. Why do you want to use C++03 mode?

Test is failing from various reasons with any compiler without C++11 support. See e.g.: http://www.boost.org/development/tests/develop/developer/geometry.html

It is almost 2016. How much longer do we plan to test against c++03? I'm with Bjarne here: it is time to move to c++11 enabled world - we all going to be better for it.

I'll see if anything obvious can be fixed.

I'm all for libraries that only support C++11 going forward and even investigating phasing out support from existing libraries. However, the test library will have to be one of the last ones to stop supporting C++03 compilers because as long as there are other C++03 libraries in boost, it will still have to support testing them.

Another option for C++03 libraries is to use lightweight_test instead: http://www.boost.org/doc/libs/1_59_0/libs/core/doc/html/core/lightweight_tes... Regards, &rzej

Gennadiy Rozental

4 Oct 4 Oct

8:10 a.m.

Tom Kent writes:

...

Unfortunately I know lots of places that are still using msvc-8.0, so I don't see that full move happening any time soon

Why would we want to wait for some places using 12 year old compiler? More importantly who is going to maintain the code for it? If they want to stick with older compiler, they can stick with older boost release. Gennadiy

Robert Ramey

5:37 p.m.

On 10/4/15 1:10 AM, Gennadiy Rozental wrote:

...

Tom Kent writes:

...
Unfortunately I know lots of places that are still using msvc-8.0, so I don't see that full move happening any time soon

Why would we want to wait for some places using 12 year old compiler? More importantly who is going to maintain the code for it? If they want to stick with older compiler, they can stick with older boost release.

I think this betrays a difference in what Boost or what Boost should be. To some, it seems that "The Boost Libraries" is sort of like a product like windows, or Clang or whatever - a large piece of code with lots of facets which is accepted/rejected as a whole. This is what most of us deal with in our day jobs so it seems natural to look at Boost this way. This view leads to coupling among libraries, requirements for coordination on testing policies, and things like that. I don't think this is a good think I think a better way to look at Boost is a collection of more loosely coupled software components. The only coupling is to a minimal set of of practices and requirements: Compatiblity with C++, Formal Review, directory structure, and documentation requirements. In this view, there is no place for requiring a specific library for testing, requiring that some particular version of C++ not be supported. I have no problems with the current setup as regards the serialization library - a library which has more stringent requirements than most in the support of older code, platforms and data sets. I use a) Xcode/CLang with C++11 enabled for development as it's very convenient for this. b) I use my own version lightweight test as it's enough for my needs and I've found it simpler and more stable than other systems. I haven't changed any code in it for ten years!. A big problem in using boost test on the test matrix is that one is testing my development code with boost test development code so when the later has some issue, it spills over into my domain - and I already have my hands full. c) I have my whole boost development tree to set to master branch so I'm testing against the next release. Only the serialization submodule is set to develop (or a feature branch). d) Almost most all code is C++11/C++03 agnostic. e) Some code is C++11+ specific. This is conditioned with BOOST_NO... macros. Some tests are conditioned on these macros as well. f) After I get clean results with Xcode/CLang C++11 I test with GCC with C++03 selected. Tweak the library to address any test failures then upload to development branch of the repository. This is a simple effective system which has worked well for me and I believe for the wide variety of users of the serialization libraries. It is not particularly difficult or time consuming to maintain - given the size and complexity of the library itself. Notice that it does NOT result in maintaining two versions of the library. A very small portion of the code is conditional. I don't think can or should try to impose requirements/prohibitions on supporting old libraries from the top down. It isn't a requirement, but it it can't be prohibited either. If the author of Boost.Test feels he can't support older compilers, that's his decision of course. But he should be aware it's going to cut his "market share" and encourage the usage of alternatives. Robert Ramey

Gennadiy Rozental

5 Oct 5 Oct

8:20 p.m.

Robert Ramey writes:

...

I think a better way to look at Boost is a collection of more loosely coupled software components. The only coupling is to a minimal set of of practices and requirements: Compatiblity with C++, Formal Review, directory structure, and documentation requirements. In this view, there is no place for requiring a specific library for testing, requiring that some particular version of C++ not be supported.

For this we need a process of independent boost.XXX library version-ing and release procedures/schedule.

...

c) I have my whole boost development tree to set to master branch so I'm testing against the next release. Only the serialization submodule is set to develop (or a feature branch).

Unfortunately this is not the way test runners operate

...

d) Almost most all code is C++11/C++03 agnostic.

e) Some code is C++11+ specific. This is conditioned with BOOST_NO... macros. Some tests are conditioned on these macros as well.

In few cases this can work out like this. In many other cases maintaining c++03 compatibility can make library obsolete(I am not talking about my library). C++11/C+14 modern C++ code can and *should* look significantly different, with different API and implementation

...

If the author of Boost.Test feels he can't support older compilers, that's his decision of course. But he should be aware it's going to cut his "market share" and encourage the usage of alternatives.

This statement is conditioned on several big IFs IMO, but I am not going to argue. Gennadiy

Robert Ramey

8:43 p.m.

On 10/5/15 1:20 PM, Gennadiy Rozental wrote:

...

Robert Ramey writes:

...
I think a better way to look at Boost is a collection of more loosely coupled software components. The only coupling is to a minimal set of of practices and requirements: Compatiblity with C++, Formal Review, directory structure, and documentation requirements. In this view, there is no place for requiring a specific library for testing, requiring that some particular version of C++ not be supported.

For this we need a process of independent boost.XXX library version-ing and release procedures/schedule.

It's a question of degree. Libraries can be more or less tightly coupled. I one's library development depends heavily on Boost.Test it's coupled to Boost.Test. Otherwise it's not. I would argue that less coupling is better than more coupling and I think the structure of Boost encourages that.

...

...
c) I have my whole boost development tree to set to master branch so I'm testing against the next release. Only the serialization submodule is set to develop (or a feature branch).

Unfortunately this is not the way test runners operate

LOL - That's my point exactly. And it is one of the sources of these problems. If things were run the way I suggest, you could make a temporary mistake in development of Boost.Test which wouldn't ripple though to all the libraries which use it for development testing. It would make your life a lot easier.

...

...
d) Almost most all code is C++11/C++03 agnostic.

e) Some code is C++11+ specific. This is conditioned with BOOST_NO... macros. Some tests are conditioned on these macros as well.

In few cases this can work out like this. In many other cases maintaining c++03 compatibility can make library obsolete(I am not talking about my library). C++11/C+14 modern C++ code can and *should* look significantly different, with different API and implementation

It makes no economic sense to go back and re-write working code to just because there is a new standard. There is no benefit unless one want's to add features. Some might say that it makes maintenance easier - but this is a decision that only a the library maintainer is qualified to make.

...

This statement is conditioned on several big IFs IMO, but I am not going to argue.

Hmmm - there aren't any IFS here:

...

...
If the author of Boost.Test feels he can't support older compilers, that's his decision of course.

Hmmm - I presume agree with this.

...

...
But he should be aware it's going to cut his "market share" and encourage the usage of alternatives.

I doubt anyone would dispute this. Robert Ramey

Raffi Enficiaud

7 Oct 7 Oct

11:16 p.m.

Le 05/10/15 22:43, Robert Ramey a écrit :

...

...
...
c) I have my whole boost development tree to set to master branch so I'm testing against the next release. Only the serialization submodule is set to develop (or a feature branch).

Unfortunately this is not the way test runners operate

LOL - That's my point exactly. And it is one of the sources of these problems. If things were run the way I suggest, you could make a temporary mistake in development of Boost.Test which wouldn't ripple though to all the libraries which use it for development testing. It would make your life a lot easier.

This is also what I suggested (I believe), and something we can envision: - cloning out full boost - checking out a particular branch (say "next") of eg. boost.test - running the runner with the source in place (using the --have-source switch) This builds will be triggered only by changes to boost.test[next], so that it will be boost.all against boost.test[next]. This will add several columns to the test dashboard. I think for libraries having a lot of children in the dependency graph, this would be very beneficial.

...

It makes no economic sense to go back and re-write working code to just because there is a new standard. There is no benefit unless one want's to add features. Some might say that it makes maintenance easier - but this is a decision that only a the library maintainer is qualified to make.

In this very case, the changes were also adding features. Best, Raffi

Aparna Kumta

1 Oct 1 Oct

7:31 p.m.

On 09/30/15 23:47, Gennadiy Rozental wrote:

...

Aparna Kumta writes:

...
It seems that the code contains rvalue reference and hence the compiler is not able to build it in C++03 mode. Why do you want to use C++03 mode? The change to want to use C++11 mode by default seems to have caused many test failures for compilers that do not use -std=c++11 flag.

Several tests that passed before this change, now fail :-(. Thanks, Aparna

...

Gennadiy

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Raffi Enficiaud

8 Oct 8 Oct

7:18 a.m.

Le 01/10/15 05:35, Aparna Kumta a écrit :

...

Compiling with Oracle Solaris Studio on sparc-S2 platform with -library=stlport4, I see the following failure in the develop branch:

[snip]

It seems that the code contains rvalue reference and hence the compiler is not able to build it in C++03 mode.

This seems to be a recent change preventing building of libboost_unit_test_framework.a and hence causing several tests to fail.

The regressions are getting fixed as the runners are cycling, starting rev superproject[3dbdd6] (see eg. teeks99-01a-Ubuntu14.04-64) http://www.boost.org/development/tests/develop/developer/lockfree.html Reverted the changes without rewriting the history. Best, Raffi

Aparna Kumta

3:09 p.m.

On 10/08/15 00:18, Raffi Enficiaud wrote:

...

Le 01/10/15 05:35, Aparna Kumta a écrit :

...
Compiling with Oracle Solaris Studio on sparc-S2 platform with -library=stlport4, I see the following failure in the develop branch:

[snip]

It seems that the code contains rvalue reference and hence the compiler is not able to build it in C++03 mode.

This seems to be a recent change preventing building of libboost_unit_test_framework.a and hence causing several tests to fail.

The regressions are getting fixed as the runners are cycling, starting rev superproject[3dbdd6] (see eg. teeks99-01a-Ubuntu14.04-64)

http://www.boost.org/development/tests/develop/developer/lockfree.html

Reverted the changes without rewriting the history. Thank you.

Aparna

...

Best, Raffi

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

3321

Age (days ago)

3328

Last active (days ago)

List overview

Download

33 comments

12 participants

participants (12)

Adam Wulkiewicz
Andrey Semashev
Andrzej Krzemienski
Aparna Kumta
Barend Gehrels
Gennadiy Rozental
Jürgen Hunold
Raffi Enficiaud
Rob Stewart
Robert Ramey
Stephen Kelly
Tom Kent