Visual Studio 2015 Update 3 has removed std::unary_function and std::binary_function
... if you build with /std:c++latest. See https://svn.boost.org/trac/boost/ticket/12586 for an example. Other vendors will be removing these types in C++17 mode in the future (or at least requiring a -D RETAIN_REMOVED_STUFF=1 or something like that) A quick grep for these terms found 153 instances of "std::unary_function" and 118 of "std::binary_function" across several libraries, including accumulators, algorithm, config, container, function, gil, graph, icl, mpi, msm, polygon, ptr_container, serialization, smart_ptr, tr1, unordered, utility - and probably others. I think that we ought to have a boost-wide solution for this (i.e, everyone should solve this the same way). I can think of three possibilities: * Deny, deny, deny: Boost doesn't work with C++17. Not my recommendation. * Since std::unary|binary_function is an empty struct with a set of two (or three) typedefs, just define the typedefs everywhere. Note that the typedefs (result_type, first_argument_type, second_argument_type) were deemed to not be useful in C++17 due to the existence of advanced type traits, etc. * Define a boost:unary_function and boost::binary_function struct that mimics the one that was in namespace std, and change over to use that. * Something else. Comments? -- Marshall
For Boost.Algorithm we can remove all std::unary_function and std::binary_function. I think, we can rewrite sources without these functions.
05.11.2016, 22:22, "Marshall Clow"
... if you build with /std:c++latest.
See https://svn.boost.org/trac/boost/ticket/12586 for an example.
Other vendors will be removing these types in C++17 mode in the future (or at least requiring a -D RETAIN_REMOVED_STUFF=1 or something like that)
A quick grep for these terms found 153 instances of "std::unary_function" and 118 of "std::binary_function" across several libraries, including accumulators, algorithm, config, container, function, gil, graph, icl, mpi, msm, polygon, ptr_container, serialization, smart_ptr, tr1, unordered, utility - and probably others.
I think that we ought to have a boost-wide solution for this (i.e, everyone should solve this the same way).
I can think of three possibilities: * Deny, deny, deny: Boost doesn't work with C++17. Not my recommendation. * Since std::unary|binary_function is an empty struct with a set of two (or three) typedefs, just define the typedefs everywhere. Note that the typedefs (result_type, first_argument_type, second_argument_type) were deemed to not be useful in C++17 due to the existence of advanced type traits, etc. * Define a boost:unary_function and boost::binary_function struct that mimics the one that was in namespace std, and change over to use that. * Something else.
Comments?
-- Marshall
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- С уважением, Зайцев Александр.
On 11/5/16 12:44 PM, Зайцев Александр wrote:
For Boost.Algorithm we can remove all std::unary_function and std::binary_function. I think, we can rewrite sources without these functions.
I'm guessing that could be done for all the libraries. But would that permit the usage of the libraries by those who depend upon C++03 compilers? Robert Ramey
On Sat, Nov 5, 2016 at 1:00 PM, Robert Ramey
On 11/5/16 12:44 PM, Зайцев Александр wrote:
For Boost.Algorithm we can remove all std::unary_function and std::binary_function. I think, we can rewrite sources without these functions.
I'm guessing that could be done for all the libraries. But would that permit the usage of the libraries by those who depend upon C++03 compilers?
I don't think there's anything in boost (or the standard library) that
depends specifically on std::unary_function. (except TR1) Here's the
definition:
template
On 11/05/16 22:21, Marshall Clow wrote:
... if you build with /std:c++latest.
See https://svn.boost.org/trac/boost/ticket/12586 for an example.
Other vendors will be removing these types in C++17 mode in the future (or at least requiring a -D RETAIN_REMOVED_STUFF=1 or something like that)
A quick grep for these terms found 153 instances of "std::unary_function" and 118 of "std::binary_function" across several libraries, including accumulators, algorithm, config, container, function, gil, graph, icl, mpi, msm, polygon, ptr_container, serialization, smart_ptr, tr1, unordered, utility - and probably others.
I think that we ought to have a boost-wide solution for this (i.e, everyone should solve this the same way).
I can think of three possibilities: * Deny, deny, deny: Boost doesn't work with C++17. Not my recommendation. * Since std::unary|binary_function is an empty struct with a set of two (or three) typedefs, just define the typedefs everywhere. Note that the typedefs (result_type, first_argument_type, second_argument_type) were deemed to not be useful in C++17 due to the existence of advanced type traits, etc. * Define a boost:unary_function and boost::binary_function struct that mimics the one that was in namespace std, and change over to use that. * Something else.
Comments?
I'm in favor of replacing the structs with typedefs (i.e. option #2). Although I suspect there are quite a few unmaintained libraries in the list, so we need someone with wide push permissions. If we agree on this approach I'm willing to do this for the libraries I have push rights to (Utility from the list above). For others I can only create PRs. TR1 could require a special approach, since it is supposed to implement TR1, and it does have std::unary|binary_function. Maybe, this particular library should implement those types when they are not available. I also suspect we won't make the switch all at once, so at least 1.63 may get released with those classes still being used. It would be nice to mention that in the release notes and say that one has to do -D RETAIN_REMOVED_STUFF=1 or whatever for now.
On Nov 5, 2016, at 5:01 PM, Andrey Semashev
On 11/05/16 22:21, Marshall Clow wrote:
Other vendors will be removing these types in C++17 mode in the future
A quick grep for these terms found 153 instances of "std::unary_function" and 118 of "std::binary_function" across several libraries
I think that we ought to have a boost-wide solution for this (i.e, everyone should solve this the same way).
I can think of three possibilities: * Deny, deny, deny: Boost doesn't work with C++17. Not my recommendation. * Since std::unary|binary_function is an empty struct with a set of two (or three) typedefs, just define the typedefs everywhere. Note that the typedefs (result_type, first_argument_type, second_argument_type) were deemed to not be useful in C++17 due to the existence of advanced type traits, etc. * Define a boost:unary_function and boost::binary_function struct that mimics the one that was in namespace std, and change over to use that. * Something else.
Comments?
#1 is obviously a non-starter. #3 requires changing the same number of use sites as #2, with the minor one-time advantage of requiring only a trivial search/replace operation, but at the cost of adding a new component.
I'm in favor of replacing the structs with typedefs (i.e. option #2).
I agree. I did this some time ago to my own code (to reduce the length of translation units by not including <functional>) and found the result more readable. Josh
On 11/5/2016 3:21 PM, Marshall Clow wrote:
... if you build with /std:c++latest.
See https://svn.boost.org/trac/boost/ticket/12586 for an example.
Other vendors will be removing these types in C++17 mode in the future (or at least requiring a -D RETAIN_REMOVED_STUFF=1 or something like that)
A quick grep for these terms found 153 instances of "std::unary_function" and 118 of "std::binary_function" across several libraries, including accumulators, algorithm, config, container, function, gil, graph, icl, mpi, msm, polygon, ptr_container, serialization, smart_ptr, tr1, unordered, utility - and probably others.
I think that we ought to have a boost-wide solution for this (i.e, everyone should solve this the same way).
I can think of three possibilities: * Deny, deny, deny: Boost doesn't work with C++17. Not my recommendation. * Since std::unary|binary_function is an empty struct with a set of two (or three) typedefs, just define the typedefs everywhere.
What do you mean by "define the typedefs everywhere" ?
Note that the typedefs (result_type, first_argument_type, second_argument_type) were deemed to not be useful in C++17 due to the existence of advanced type traits, etc. * Define a boost:unary_function and boost::binary_function struct that mimics the one that was in namespace std, and change over to use that. * Something else.
Comments?
On Sat, Nov 5, 2016 at 5:38 PM, Edward Diener
On 11/5/2016 3:21 PM, Marshall Clow wrote:
... if you build with /std:c++latest.
See https://svn.boost.org/trac/boost/ticket/12586 for an example.
Other vendors will be removing these types in C++17 mode in the future (or at least requiring a -D RETAIN_REMOVED_STUFF=1 or something like that)
A quick grep for these terms found 153 instances of "std::unary_function" and 118 of "std::binary_function" across several libraries, including accumulators, algorithm, config, container, function, gil, graph, icl, mpi, msm, polygon, ptr_container, serialization, smart_ptr, tr1, unordered, utility - and probably others.
I think that we ought to have a boost-wide solution for this (i.e, everyone should solve this the same way).
I can think of three possibilities: * Deny, deny, deny: Boost doesn't work with C++17. Not my recommendation. * Since std::unary|binary_function is an empty struct with a set of two (or three) typedefs, just define the typedefs everywhere.
What do you mean by "define the typedefs everywhere" ?
Everywhere we derive from std::unary_function or std::binary_function,
manually define "result_type", "first_argument_type", etc.
Like this:
Change:
template<typename T>
struct plus: binary_function
On 11/5/2016 10:52 PM, Marshall Clow wrote:
On Sat, Nov 5, 2016 at 5:38 PM, Edward Diener
wrote: On 11/5/2016 3:21 PM, Marshall Clow wrote:
... if you build with /std:c++latest.
See https://svn.boost.org/trac/boost/ticket/12586 for an example.
Other vendors will be removing these types in C++17 mode in the future (or at least requiring a -D RETAIN_REMOVED_STUFF=1 or something like that)
A quick grep for these terms found 153 instances of "std::unary_function" and 118 of "std::binary_function" across several libraries, including accumulators, algorithm, config, container, function, gil, graph, icl, mpi, msm, polygon, ptr_container, serialization, smart_ptr, tr1, unordered, utility - and probably others.
I think that we ought to have a boost-wide solution for this (i.e, everyone should solve this the same way).
I can think of three possibilities: * Deny, deny, deny: Boost doesn't work with C++17. Not my recommendation. * Since std::unary|binary_function is an empty struct with a set of two (or three) typedefs, just define the typedefs everywhere.
What do you mean by "define the typedefs everywhere" ?
Everywhere we derive from std::unary_function or std::binary_function, manually define "result_type", "first_argument_type", etc.
Like this:
Change:
template<typename T> struct plus: binary_function
{ T operator() (const T& x, const T& y) { return x + y } }; to:
template<typename T> struct plus { typedef T first_argument_type; typedef T second_argument_type; typedef T result_type; T operator() (const T& x, const T& y) { return x + y } };
Thanks ! Sounds like the obvious choice.
-- Marshall
Am 05.11.2016 um 20:21 schrieb Marshall Clow:
... if you build with /std:c++latest.
A quick grep for these terms found 153 instances of "std::unary_function" and 118 of "std::binary_function" across several libraries, including accumulators, algorithm, config, container, function, gil, graph, icl, mpi, msm, polygon, ptr_container, serialization, smart_ptr, tr1, unordered, utility - and probably others.
The full list of libraries that need to be modified to run the test suite with /std:c++latest is this: accumulators, algorithm, asio, assign, bimap, bind, config, container, core, date_time, detail, function, functional, fusion, gil, graph, heap, icl, interprocess, intrusive, iostreams, iterator, lambda, locale, lockfree, move, msm, parameter, phoenix, polygon, pool, ptr_container, python, random, range, regex, serialization, signals, signals2, smart_ptr, spirit, statechart, test, typeof, wave, winapi, xpressive Library tr1 is dropped outright. This covers all stuff that is affected by the removal of deprecated features: namespace tr1, adapters, binders, random_shuffle, and auto_ptr I've made the required changes for 1.62 and I'm in the process of applying those changes to 1.63. In many cases it is sufficient to simply drop the function binders, in some cases other parts of the libraries rely on the tr1 protocol. All of this stuff is on GitHub: https://github.com/DanielaE Each affected library has a branch 'feature/remove-deprecated' I can send out PRs to library authors interested in that and help working on a converged Boost-wide solution Ciao Dani
Library tr1 is dropped outright.
Right, use of those interfaces is mandated by TR1, if you want to still use Boost.TR1, better use a C++03 compiler - that's what it's for.
This covers all stuff that is affected by the removal of deprecated features: namespace tr1, adapters, binders, random_shuffle, and auto_ptr
I've made the required changes for 1.62 and I'm in the process of applying those changes to 1.63. In many cases it is sufficient to simply drop the function binders, in some cases other parts of the libraries rely on the tr1 protocol.
All of this stuff is on GitHub: https://github.com/DanielaE Each affected library has a branch 'feature/remove-deprecated' I can send out PRs to library authors interested in that and help working on a converged Boost-wide solution
Please do file some PR's, that would be most useful, Thanks, John.
On 11/6/2016 1:14 AM, Daniela Engert wrote:
Am 05.11.2016 um 20:21 schrieb Marshall Clow:
... if you build with /std:c++latest.
A quick grep for these terms found 153 instances of "std::unary_function" and 118 of "std::binary_function" across several libraries, including accumulators, algorithm, config, container, function, gil, graph, icl, mpi, msm, polygon, ptr_container, serialization, smart_ptr, tr1, unordered, utility - and probably others.
The full list of libraries that need to be modified to run the test suite with /std:c++latest is this:
accumulators, algorithm, asio, assign, bimap, bind, config, container, core, date_time, detail, function, functional, fusion, gil, graph, heap, icl, interprocess, intrusive, iostreams, iterator, lambda, locale, lockfree, move, msm, parameter, phoenix, polygon, pool, ptr_container, python, random, range, regex, serialization, signals, signals2, smart_ptr, spirit, statechart, test, typeof, wave, winapi, xpressive
Library tr1 is dropped outright.
This covers all stuff that is affected by the removal of deprecated features: namespace tr1, adapters, binders, random_shuffle, and auto_ptr
I've made the required changes for 1.62 and I'm in the process of applying those changes to 1.63. In many cases it is sufficient to simply drop the function binders, in some cases other parts of the libraries rely on the tr1 protocol.
All of this stuff is on GitHub: https://github.com/DanielaE Each affected library has a branch 'feature/remove-deprecated' I can send out PRs to library authors interested in that and help working on a converged Boost-wide solution
A number of changes require c++11 support so you can't just blindly introduce such changes for libraries which also support c++03.
I seem to recall when I used boost::iterator::transform_iterator (which requires a UnaryFunction in its template argument), if I did not derive from std::unary_function I got a bunch of compile errors. This is because some part of the iterator implementation is looking for those nested types. So while the transform_iterator implementation itself does not depend on std::unary_function, it does depend on some or all of those types being present. I'm not sure if this affects the discussion taking place here or not, or what changes are needed if any - apologies if it is noise.
Am 06.11.2016 um 15:51 schrieb Edward Diener:
On 11/6/2016 1:14 AM, Daniela Engert wrote:
Am 05.11.2016 um 20:21 schrieb Marshall Clow:
... if you build with /std:c++latest.
I can send out PRs to library authors interested in that and help working on a converged Boost-wide solution
A number of changes require c++11 support so you can't just blindly introduce such changes for libraries which also support c++03.
As the maintainer of our in-house Boost distribution I have the freedom to do so, and I have no other choice but to make boost work with recent versions of msvc and /std:c++latest. I am perfectly aware of the fact that changes to make this happen may clash with c++03 and the possible lack of features introduced with c++11. Therefore I am sending out PRs for people to see what changes are required as bare minimum in a c++11 environment. Based upon that we may mull over c++03 compatible changes if needed. One note: my /std:c++latest-capable version of 1.62 passed the full test suite when compiled with vc14 update 3 in the same way as the Boost master test matrix showed (well, with fewer test failures in some cases). And I always run the test suite in all four combinations of 32/64 bit and debug/release mode to monitor the different outcomes that become apparent when doing so. Ciao Dani
On 11/6/2016 10:31 AM, Daniela Engert wrote:
Am 06.11.2016 um 15:51 schrieb Edward Diener:
On 11/6/2016 1:14 AM, Daniela Engert wrote:
Am 05.11.2016 um 20:21 schrieb Marshall Clow:
... if you build with /std:c++latest.
I can send out PRs to library authors interested in that and help working on a converged Boost-wide solution
A number of changes require c++11 support so you can't just blindly introduce such changes for libraries which also support c++03.
As the maintainer of our in-house Boost distribution I have the freedom to do so, and I have no other choice but to make boost work with recent versions of msvc and /std:c++latest. I am perfectly aware of the fact that changes to make this happen may clash with c++03 and the possible lack of features introduced with c++11. Therefore I am sending out PRs for people to see what changes are required as bare minimum in a c++11 environment. Based upon that we may mull over c++03 compatible changes if needed.
My point is that if the Boost library supports c++03 then your PRs will be rejected if the change(s) in them do not take that into account for the relevant changes. As an example if you want to change 'std::auto_ptr' to 'std::unique_ptr' in some library which supports c++03, you need to check whether or not 'std::unique_ptr' is supported for a particular compilation, using the Boost config macro BOOST_NO_CXX11_SMART_PTR. I understand that you have the freedom to dictate what your own in-house Boost distribution supports, but when you create PRs for Boost libraries in general you need to take into account how anybody might use a particular Boost library and not just yourself. With all that said PRs are always appreciated for those who are willing to create them properly.
One note: my /std:c++latest-capable version of 1.62 passed the full test suite when compiled with vc14 update 3 in the same way as the Boost master test matrix showed (well, with fewer test failures in some cases). And I always run the test suite in all four combinations of 32/64 bit and debug/release mode to monitor the different outcomes that become apparent when doing so.
Ciao Dani
Am 06.11.2016 um 16:59 schrieb Edward Diener:
My point is that if the Boost library supports c++03 then your PRs will be rejected if the change(s) in them do not take that into account for the relevant changes.
Edward, I am perfectly aware of this process, thanks for educating me. And I am also perfectly aware that libraries with a c++03 baseline requirement cannot use std::unique_ptr or std::shuffle unconditionally. That said, I am willing to rework my feature branches accordingly before sending out PRs. This will take time because I am doing this in my spare time. But, in cases where I might miss config macros, or where maintaining both std::auto_ptr and std::unique_ptr means littering #if/#then/#else all over the place I will withhold PRs. I just won't do that. Ciao Dani
On 11/6/16 7:31 AM, Daniela Engert wrote:
As the maintainer of our in-house Boost distribution I have the freedom to do so, and I have no other choice but to make boost work with recent versions of msvc and /std:c++latest. I am perfectly aware of the fact that changes to make this happen may clash with c++03 and the possible lack of features introduced with c++11. Therefore I am sending out PRs for people to see what changes are required as bare minimum in a c++11 environment. Based upon that we may mull over c++03 compatible changes if needed.
Since you're doing this work as part of your job (it seems) perhaps you might consider joining the Boost Library Official Maintainer program. This would help your work gain wider usage and perhaps help you and/or your organization. http://www.boost.org/community/official_library_maintainer_program.html Robert Ramey
Am 06.11.2016 um 21:15 schrieb Robert Ramey:
Since you're doing this work as part of your job (it seems) perhaps you might consider joining the Boost Library Official Maintainer program.
Unfortunately, the maintenance of our boost distribution is not part of my job - it is unvoluntary voluntary work in my spare time. That's how things work in small companies :-) Ciao Dani
On 11/06/16 09:14, Daniela Engert wrote:
Am 05.11.2016 um 20:21 schrieb Marshall Clow:
... if you build with /std:c++latest.
A quick grep for these terms found 153 instances of "std::unary_function" and 118 of "std::binary_function" across several libraries, including accumulators, algorithm, config, container, function, gil, graph, icl, mpi, msm, polygon, ptr_container, serialization, smart_ptr, tr1, unordered, utility - and probably others.
The full list of libraries that need to be modified to run the test suite with /std:c++latest is this:
accumulators, algorithm, asio, assign, bimap, bind, config, container, core, date_time, detail, function, functional, fusion, gil, graph, heap, icl, interprocess, intrusive, iostreams, iterator, lambda, locale, lockfree, move, msm, parameter, phoenix, polygon, pool, ptr_container, python, random, range, regex, serialization, signals, signals2, smart_ptr, spirit, statechart, test, typeof, wave, winapi, xpressive
Library tr1 is dropped outright.
This covers all stuff that is affected by the removal of deprecated features: namespace tr1, adapters, binders, random_shuffle, and auto_ptr
I've made the required changes for 1.62 and I'm in the process of applying those changes to 1.63. In many cases it is sufficient to simply drop the function binders, in some cases other parts of the libraries rely on the tr1 protocol.
All of this stuff is on GitHub: https://github.com/DanielaE Each affected library has a branch 'feature/remove-deprecated' I can send out PRs to library authors interested in that and help working on a converged Boost-wide solution
Thank you Daniela for the link. I've incorporated some of your changes into Atomic, Core, Detail, Log, Utility and WinAPI.
Marshall Clow wrote:
A quick grep for these terms found 153 instances of "std::unary_function" and 118 of "std::binary_function" across several libraries, including accumulators, algorithm, config, container, function, gil, graph, icl, mpi, msm, polygon, ptr_container, serialization, smart_ptr, tr1, unordered, utility - and probably others.
Since a number of bind's tests use boost.function, which is under CMT, I'll take care of it (by adding typedefs.)
Since a number of bind's tests use boost.function, which is under CMT, I'll take care of it (by adding typedefs.)
Turns out that boost::function already has the typedefs in addition to the base classes for some reason. But there are two showstoppers in Boost.Test: C:\Projects\boost-git\boost\boost/test/utils/basic_cstring/compare.hpp(79): error C2143: syntax error: missing ',' before '<' and C:\Projects\boost-git\boost\boost/test/impl/framework.ipp(691): error C2039: 'random_shuffle': is not a member of 'std' that need to be fixed in order for most of the tests to even have a chance under c++latest. Boost.Test also required utility/compare_pointees to be fixed, so I did that. function/test/std_bind_cxx98.cpp also fails because of mem_fun and bind1st, and I suppose we need a Config macro to detect their absence. And we also might need a way (Config macro) to detect the absence of std::random_shuffle (or alternatively the presence of std::shuffle.) Should I merge the changes to Bind, Function and Utility to master, or do we wait for the next release for these fixes?
On Sun, Nov 6, 2016 at 4:49 AM, Peter Dimov
Since a number of bind's tests use boost.function, which is under CMT,
I'll take care of it (by adding typedefs.)
Turns out that boost::function already has the typedefs in addition to the base classes for some reason.
But there are two showstoppers in Boost.Test:
C:\Projects\boost-git\boost\boost/test/utils/basic_cstring/compare.hpp(79): error C2143: syntax error: missing ',' before '<'
and
C:\Projects\boost-git\boost\boost/test/impl/framework.ipp(691): error C2039: 'random_shuffle': is not a member of 'std'
that need to be fixed in order for most of the tests to even have a chance under c++latest.
Boost.Test also required utility/compare_pointees to be fixed, so I did that.
function/test/std_bind_cxx98.cpp also fails because of mem_fun and bind1st, and I suppose we need a Config macro to detect their absence.
And we also might need a way (Config macro) to detect the absence of std::random_shuffle (or alternatively the presence of std::shuffle.)
Should I merge the changes to Bind, Function and Utility to master, or do we wait for the next release for these fixes?
My thought is to get them working on develop, let the bots cycle, and then merge to master. (which, as you say, is predicated on fixing Boost.Test first) -- Marshall
On Sun, Nov 6, 2016 at 6:47 AM, Marshall Clow
On Sun, Nov 6, 2016 at 4:49 AM, Peter Dimov
wrote: Should I merge the changes to Bind, Function and Utility to master, or do we wait for the next release for these fixes?
My thought is to get them working on develop, let the bots cycle, and then merge to master. (which, as you say, is predicated on fixing Boost.Test first)
In case I wasn't clear: I think we definitely want these fixes in 1.63.0 -- Marshall
On Nov 6, 2016 9:48 AM, "Marshall Clow"
On Sun, Nov 6, 2016 at 6:47 AM, Marshall Clow
wrote:
On Sun, Nov 6, 2016 at 4:49 AM, Peter Dimov
wrote: Should I merge the changes to Bind, Function and Utility to master, or do we wait for the next release for these fixes?
My thought is to get them working on develop, let the bots cycle, and
then
merge to master. (which, as you say, is predicated on fixing Boost.Test first)
In case I wasn't clear: I think we definitely want these fixes in 1.63.0
+1 --Beman
Marshall Clow wrote:
In case I wasn't clear: I think we definitely want these fixes in 1.63.0
OK, here are the changes for review: Bind: https://github.com/boostorg/bind/commit/60d3e0f4f3f44af38a8c72bc90d89714c913... Function: https://github.com/boostorg/function/commit/c326d30f2875a21da60b476e331f39b7... Smart_ptr: https://github.com/boostorg/smart_ptr/commit/a7fbb0a8415acae2a8507d697653930... Utility: https://github.com/boostorg/utility/commit/ff445c0ecedad0540be832102165ff9cc... https://github.com/boostorg/utility/commit/0f1f793cafb8eca72a05ff842298d0161... (tested locally on g++, clang, msvc various versions, msvc-14.0 c++latest) I think that they are sufficiently low risk that there's no need to wait for the tests to cycle, but I have no problem with waiting, too. :-) For smart_ptr to go all green, functional/hash needs to be fixed as well.
On 6 November 2016 at 23:31, Peter Dimov
For smart_ptr to go all green, functional/hash needs to be fixed as well.
Is there something wrong with this? I haven't got Visual C++, so I might have missed something. https://github.com/boostorg/functional/commit/281e11b2923249869cce3131a41511... I wrote that before this thread, which is why I wrote it as a short term fix. I didn't realise it was going to become an urgent issue a few days before we freeze.
On 11/07/16 10:29, Daniel James wrote:
On 6 November 2016 at 23:31, Peter Dimov
wrote: For smart_ptr to go all green, functional/hash needs to be fixed as well.
Is there something wrong with this? I haven't got Visual C++, so I might have missed something.
https://github.com/boostorg/functional/commit/281e11b2923249869cce3131a41511...
This solution relies on MSVC macros, so it won't work when other compilers remove the deprecated components.
On 7 November 2016 at 08:16, Andrey Semashev
This solution relies on MSVC macros, so it won't work when other compilers remove the deprecated components.
From my email:
I wrote that before this thread, which is why I wrote it as a short term fix
From the commit message:
I'm not sure what the long term solution should be, but hopefully this will work for now.
If that wasn't clear enough, I was just trying to put in a short term fix for this release, so that it can be dealt with properly later. Changing the public inheritance of a class is a breaking change, and we're scheduled to close for beta in two days time.
On 11/07/16 13:02, Daniel James wrote:
On 7 November 2016 at 08:16, Andrey Semashev
wrote: This solution relies on MSVC macros, so it won't work when other compilers remove the deprecated components.
From my email:
I wrote that before this thread, which is why I wrote it as a short term fix
From the commit message:
I'm not sure what the long term solution should be, but hopefully this will work for now.
If that wasn't clear enough, I was just trying to put in a short term fix for this release, so that it can be dealt with properly later. Changing the public inheritance of a class is a breaking change, and we're scheduled to close for beta in two days time.
IMHO, there's no point in a "short term fix" if it's messier and more complicated than a normal fix. I'd either keep the original code for 1.63 or do a proper fix. Removing the base class is formally a breaking change, but I doubt anyone will ever notice. But that's just my opinion.
Andrey Semashev wrote:
IMHO, there's no point in a "short term fix" if it's messier and more complicated than a normal fix.
Well the point is to get code using the headers to compile without errors under /std:c++latest, as this is the practical problem users of Boost are currently facing.
On 11/07/16 15:31, Peter Dimov wrote:
Andrey Semashev wrote:
IMHO, there's no point in a "short term fix" if it's messier and more complicated than a normal fix.
Well the point is to get code using the headers to compile without errors under /std:c++latest, as this is the practical problem users of Boost are currently facing.
I understand the problem, my comment was regarding the solution. Anyway, it works now, that's the important part.
Daniel James wrote:
On 6 November 2016 at 23:31, Peter Dimov
wrote: For smart_ptr to go all green, functional/hash needs to be fixed as well.
Is there something wrong with this? I haven't got Visual C++, so I might have missed something.
https://github.com/boostorg/functional/commit/281e11b2923249869cce3131a41511...
I hadn't updated the superproject when I ran my tests, sorry. Yes, this works. I just tested it with msvc-cxxlatest-14.0. At some point we'll want to use a dedicated Config macro for unary/binary_function, but for now, _HAS_AUTO_PTR_ETC is OK, I suppose.
On 11/7/2016 2:29 AM, Daniel James wrote:
On 6 November 2016 at 23:31, Peter Dimov
wrote: For smart_ptr to go all green, functional/hash needs to be fixed as well.
Is there something wrong with this? I haven't got Visual C++, so I might have missed something.
https://github.com/boostorg/functional/commit/281e11b2923249869cce3131a41511...
I wrote that before this thread, which is why I wrote it as a short term fix. I didn't realise it was going to become an urgent issue a few days before we freeze.
I have been making fixes on the 'develop' branch of various CMT libraries, but I don't think it should be an issue for 1.63 so close to release. In other words I think it too dangerous to push these fixes for 1.63 as it is now scheduled and I don't see why we can't wait for 1.64. While we try to satisfy VC++ end-users because VC++ is a very heavily used compiler I would not compromise the integrity of the release for this issue. If Boost decides to push back the 1.63 release by a few weeks to satisfy this single concern, then I can see trying to push through these changes for 1.63.
On Mon, Nov 7, 2016 at 10:01 AM, Edward Diener
If Boost decides to push back the 1.63 release by a few weeks to satisfy this single concern, then I can see trying to push through these changes for 1.63.
We don't normally push release for "unreleased" toolsets. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
On Mon, Nov 7, 2016 at 10:23 AM, Rene Rivera
On Mon, Nov 7, 2016 at 10:01 AM, Edward Diener
wrote: If Boost decides to push back the 1.63 release by a few weeks to satisfy this single concern, then I can see trying to push through these changes for 1.63.
We don't normally push release for "unreleased" toolsets.
Given the current introduced release build failures caused by attempts to deal with this issue (see here https://circleci.com/gh/boostorg/boost/2190).. I am strongly against trying to rush changes for this issue into master. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
On 7 Nov 2016, at 18:15, Rene Rivera
wrote: On Mon, Nov 7, 2016 at 10:23 AM, Rene Rivera
wrote: On Mon, Nov 7, 2016 at 10:01 AM, Edward Diener
wrote: If Boost decides to push back the 1.63 release by a few weeks to satisfy this single concern, then I can see trying to push through these changes for 1.63.
We don't normally push release for "unreleased" toolsets.
Given the current introduced release build failures caused by attempts to deal with this issue (see here https://circleci.com/gh/boostorg/boost/2190).. I am strongly against trying to rush changes for this issue into master.
Possibly so, but I don't think you can call MSVS 2015 Update 3 an "unreleased" toolset. It is the current latest production version. You might be thinking of MSVS "15" - the successor to 2015 that /is/ still in beta. And yes you wouldn't be the first to remark on the awkward name! Pete
On Mon, Nov 7, 2016 at 2:03 PM, Pete Bartlett
On 7 Nov 2016, at 18:15, Rene Rivera
wrote: On Mon, Nov 7, 2016 at 10:23 AM, Rene Rivera
wrote: On Mon, Nov 7, 2016 at 10:01 AM, Edward Diener
wrote:
If Boost decides to push back the 1.63 release by a few weeks to
satisfy
this single concern, then I can see trying to push through these changes for 1.63.
We don't normally push release for "unreleased" toolsets.
Given the current introduced release build failures caused by attempts to deal with this issue (see here <https://circleci.com/gh/ boostorg/boost/2190>).. I am strongly against trying to rush changes for this issue into master.
Possibly so, but I don't think you can call MSVS 2015 Update 3 an "unreleased" toolset. It is the current latest production version.
You might be thinking of MSVS "15" - the successor to 2015 that /is/ still in beta.
No.. I was thinking of C++17. Which is still unreleased. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
On 11/7/2016 1:15 PM, Rene Rivera wrote:
On Mon, Nov 7, 2016 at 10:23 AM, Rene Rivera
wrote: On Mon, Nov 7, 2016 at 10:01 AM, Edward Diener
wrote: If Boost decides to push back the 1.63 release by a few weeks to satisfy this single concern, then I can see trying to push through these changes for 1.63.
We don't normally push release for "unreleased" toolsets.
Given the current introduced release build failures caused by attempts to deal with this issue (see here https://circleci.com/gh/boostorg/boost/2190).. I am strongly against trying to rush changes for this issue into master.
I did not mean for my stupidity ( or too quick use of one of my editor's features ) to reflect on others. But I agree that tests need to cycle through 'develop' before moving changes to 'master', and my initial response above was to support that viewpoint.
On 11/07/16 22:09, Edward Diener wrote:
I did not mean for my stupidity ( or too quick use of one of my editor's features ) to reflect on others.
<offtopic> I usually make "quick" fixes in something dumb and simple, like mcedit or far. Not only it requires you to type everything through (which forces you to be careful and use copy/paste), it also leaves you uncertain enough afterwards to run the tests. :) </offtopic>
On 11/7/2016 2:19 PM, Andrey Semashev wrote:
On 11/07/16 22:09, Edward Diener wrote:
I did not mean for my stupidity ( or too quick use of one of my editor's features ) to reflect on others.
<offtopic> I usually make "quick" fixes in something dumb and simple, like mcedit or far. Not only it requires you to type everything through (which forces you to be careful and use copy/paste), it also leaves you uncertain enough afterwards to run the tests. :) </offtopic>
I do run tests. My silly error was not caught.
Edward Diener wrote:
I do run tests. My silly error was not caught.
Would you like me to enable Travis CI on iostreams? This consists of adding a .travis.yml file such as this one: https://github.com/boostorg/function/commit/fa2d6be8de606d2f73d02c9d93e74b4c... , enabling the repository on Travis and then on each commit one gets a build job such as this one: https://travis-ci.org/boostorg/function/builds/174517543 which then notifies the committer of the result. Which in this case is negative as I've omitted libs/timer for some reason. Boostdep has failed me again. :-)
On 11/9/2016 10:25 AM, Peter Dimov wrote:
Edward Diener wrote:
I do run tests. My silly error was not caught.
Would you like me to enable Travis CI on iostreams? This consists of adding a .travis.yml file such as this one:
https://github.com/boostorg/function/commit/fa2d6be8de606d2f73d02c9d93e74b4c...
, enabling the repository on Travis and then on each commit one gets a build job such as this one:
https://travis-ci.org/boostorg/function/builds/174517543
which then notifies the committer of the result.
is there any documentation on how to setup a Boost submodule for testing using Travis CI ? I couldn't figure it out from the documentation on the Travis CI site.
Which in this case is negative as I've omitted libs/timer for some reason. Boostdep has failed me again. :-)
Edward Diener wrote:
is there any documentation on how to setup a Boost submodule for testing using Travis CI ?
The procedure is 1. Add a .travis.yml file in the root of the repository. This file describes what Travis should do. 2. Go to https://travis-ci.org/boostorg/iostreams (taking iostreams as an example) and click the Activate button.
On 11/10/2016 4:26 PM, Peter Dimov wrote:
Edward Diener wrote:
is there any documentation on how to setup a Boost submodule for testing using Travis CI ?
The procedure is
1. Add a .travis.yml file in the root of the repository. This file describes what Travis should do.
I do not see anything at https://docs.travis-ci.com/ that gives the details of the .travis.yml file so that I can create an appropriate one for a Boost library. If it exists it is well-hidden on the website.
2. Go to https://travis-ci.org/boostorg/iostreams (taking iostreams as an example) and click the Activate button.
It says it is not an active repository and I do not have sufficient rights. I am not an iostreams Admin so this makes sense.
On Thu, Nov 10, 2016 at 8:39 PM, Edward Diener
On 11/10/2016 4:26 PM, Peter Dimov wrote:
Edward Diener wrote:
is there any documentation on how to setup a Boost submodule for
testing using Travis CI ?
The procedure is
1. Add a .travis.yml file in the root of the repository. This file describes what Travis should do.
I do not see anything at https://docs.travis-ci.com/ that gives the details of the .travis.yml file so that I can create an appropriate one for a Boost library. If it exists it is well-hidden on the website.
You can look at other Boost libraries for examples. Although I'm also working on a general .travis.yml file that any library can use with some common scripts that will eventually integrate with the general Boost test regression results reports. For that you can copy the one from Predef < https://github.com/boostorg/predef/blob/develop/.travis.yml>. Literally copy-paste and minor edits for that one. 2. Go to https://travis-ci.org/boostorg/iostreams (taking iostreams as
an example) and click the Activate button.
It says it is not an active repository and I do not have sufficient rights. I am not an iostreams Admin so this makes sense.
I can turn it on for you whenever you want me to. As I have admin access to all and own the TravisCI general account :-) -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
On 11/10/2016 9:05 PM, Rene Rivera wrote:
On Thu, Nov 10, 2016 at 8:39 PM, Edward Diener
wrote: On 11/10/2016 4:26 PM, Peter Dimov wrote:
Edward Diener wrote:
is there any documentation on how to setup a Boost submodule for
testing using Travis CI ?
The procedure is
1. Add a .travis.yml file in the root of the repository. This file describes what Travis should do.
I do not see anything at https://docs.travis-ci.com/ that gives the details of the .travis.yml file so that I can create an appropriate one for a Boost library. If it exists it is well-hidden on the website.
You can look at other Boost libraries for examples. Although I'm also working on a general .travis.yml file that any library can use with some common scripts that will eventually integrate with the general Boost test regression results reports.
That would be really nice. Thank you ! I understand that CI testing of Boost libraries would have the value of providing immediate automatic testing for 'develop' branch changes, and that is a good thing. If that could be automated for any Boost library it would be great.
For that you can copy the one from Predef < https://github.com/boostorg/predef/blob/develop/.travis.yml>. Literally copy-paste and minor edits for that one.
I will look at it. But I am the wrong person to deal with yet another piece of software that refuses to document itself adequately, such as TravisCI and its .travis.yml file.
2. Go to https://travis-ci.org/boostorg/iostreams (taking iostreams as
an example) and click the Activate button.
It says it is not an active repository and I do not have sufficient rights. I am not an iostreams Admin so this makes sense.
I can turn it on for you whenever you want me to. As I have admin access to all and own the TravisCI general account :-)
I appreciate it. Let me look at whatever it takes to get iostreams to work with TravisCI.
On 11/11/2016 4:41 AM, Peter Dimov wrote:
Edward Diener wrote:
Let me look at whatever it takes to get iostreams to work with TravisCI.
I offered to do it for you in my original message.
I know and I appreciate the offer. I am trying to figure out how it's done myself. But if you already know how to do it and can create the correct .travis.yml file to do it, please go ahead and add that file to iostreams.
Edward Diener wrote:
But if you already know how to do it and can create the correct .travis.yml file to do it, please go ahead and add that file to iostreams.
Added, let's see how it goes.
On 11/11/2016 3:40 PM, Peter Dimov wrote:
Edward Diener wrote:
But if you already know how to do it and can create the correct .travis.yml file to do it, please go ahead and add that file to iostreams.
Added, let's see how it goes.
Thanks !
Edward Diener wrote:
On 11/11/2016 3:40 PM, Peter Dimov wrote:
Edward Diener wrote:
But if you already know how to do it and can create the correct .travis.yml file to do it, please go ahead and add that file to iostreams.
Added, let's see how it goes.
Thanks !
You're welcome. You can watch the job at https://travis-ci.org/boostorg/iostreams/builds/175183220 if Carlsen - Karjakin is not enough entertainment. :-)
On 11/11/2016 5:19 PM, Peter Dimov wrote:
Edward Diener wrote:
On 11/11/2016 3:40 PM, Peter Dimov wrote:
Edward Diener wrote:
But if you already know how to do it and can create the correct >> .travis.yml file to do it, please go ahead and add that file to >> iostreams.
Added, let's see how it goes.
Thanks !
You're welcome.
You can watch the job at
I did not get a notification so I assume I need to change the .travis.yml to notify myself.
if Carlsen - Karjakin is not enough entertainment. :-)
12 games ? Ridiculous ! Oh for the days of real matches rather than this pretense. This is what comes of making chess players rich; the world championship is reduced to a short, money-paying exhibition. O tempora o mores.
Edward Diener wrote:
I did not get a notification so I assume I need to change the .travis.yml to notify myself.
Yes, I suppose. Although according to the Travis docs adding an explicit e-mail address disables the automatic notification to the committer (which now I got as it's my commit). So it's a tradeoff. The OS X build fails one test. Travis delivers the most value when everything passes, as this immediately identifies the commit or pull request that introduces an error; so it would be good if that could be fixed. As far as I can see, BOOST_IOSTREAMS_NO_PRIMARY_CODECVT_DEFINITION needs to be defined but isn't, although I don't know what's the correct macro off which to base this. The darwin testers on boost.org also fail in the same way though, so this could offer some clues. Could be libc++, could just be some versions of it. Either way, hope this is useful as a starting point.
On 11/11/2016 7:08 PM, Peter Dimov wrote:
Edward Diener wrote:
I did not get a notification so I assume I need to change the .travis.yml to notify myself.
Yes, I suppose. Although according to the Travis docs adding an explicit e-mail address disables the automatic notification to the committer (which now I got as it's my commit). So it's a tradeoff.
The OS X build fails one test. Travis delivers the most value when everything passes, as this immediately identifies the commit or pull request that introduces an error; so it would be good if that could be fixed.
How do you get Travis CI to continue the build when a single invocation with just one of the toolsets fails ? Even though clang failed I still want it to try gcc.
As far as I can see, BOOST_IOSTREAMS_NO_PRIMARY_CODECVT_DEFINITION needs to be defined but isn't, although I don't know what's the correct macro off which to base this. The darwin testers on boost.org also fail in the same way though, so this could offer some clues. Could be libc++, could just be some versions of it.
The output says there is a codecvt declaration, but it sounds like it
cannot find a codecvt definition:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__locale:815:86:
note: template is declared here
template
Either way, hope this is useful as a starting point.
To me its guesswork since I do not know what version of clang is being used or what version of libc++ is being used and I cannot tell what I should be checking to turn on BOOST_IOSTREAMS_NO_PRIMARY_CODECVT_DEFINITION.
Edward Diener wrote:
How do you get Travis CI to continue the build when a single invocation with just one of the toolsets fails ? Even though clang failed I still want it to try gcc.
There is no gcc on Travis's OS X images, just Apple clang.
To me its guesswork since I do not know what version of clang is being used or what version of libc++ is being used...
The same error is present here: http://www.boost.org/development/tests/develop/developer/Sandia-darwin-iostr... so you can see the versions here: http://www.boost.org/development/tests/develop/developer/output/Sandia-darwi... This however is not enough to determine whether libc++ supplies a primary definition of codecvt on other configurations. If I had to guess I would test for defined(_LIBCPP_VERSION) && defined(__APPLE__). The root problem, of course, is that the standard does not mandate a primary definition, so the code is simply broken. It should define specializations of codecvt<> instead of trying to supply a primary definition when there isn't one. But there may have been historical reasons to write it that way.
There is no gcc on Travis's OS X images, just Apple clang.
Or rather, there _was_ no gcc on Travis's OS X images when I initially got my first .travis.yml up and running, there may be now.
On 11/12/2016 5:55 AM, Peter Dimov wrote:
Edward Diener wrote:
How do you get Travis CI to continue the build when a single invocation with just one of the toolsets fails ? Even though clang failed I still want it to try gcc.
There is no gcc on Travis's OS X images, just Apple clang.
I am missing something with Travis CI. The iostreams .travis.yml says to run the tests for linux and osx, to run using gcc and clang, and to run just clang on osx. The test then runs on osx with clang, and then none of the other combinations are run at all. That seems pretty poor to me. Surely there must be an easy way on Travis CI to not only control the order of the tests to run but to tell Travis CI to finish running the tests when one of them fails.
To me its guesswork since I do not know what version of clang is being used or what version of libc++ is being used...
The same error is present here:
http://www.boost.org/development/tests/develop/developer/Sandia-darwin-iostr...
so you can see the versions here:
http://www.boost.org/development/tests/develop/developer/output/Sandia-darwi...
OK, I see it. I don't have a Mac and I don't know what version of clang "clang-darwin-4-2-1" refers to, not that it would do any good if I knew <g>.
This however is not enough to determine whether libc++ supplies a primary definition of codecvt on other configurations. If I had to guess I would test for defined(_LIBCPP_VERSION) && defined(__APPLE__).
I can do that. Maybe add a test that just outputs the clang version and libcpp version and then use that specifically after it cycles in the regression tests to define BOOST_IOSTREAMS_NO_PRIMARY_CODECVT_DEFINITION.
The root problem, of course, is that the standard does not mandate a primary definition, so the code is simply broken. It should define specializations of codecvt<> instead of trying to supply a primary definition when there isn't one. But there may have been historical reasons to write it that way.
Edward Diener wrote:
I am missing something with Travis CI. The iostreams .travis.yml says to run the tests for linux and osx, to run using gcc and clang, and to run just clang on osx. The test then runs on osx with clang, and then none of the other combinations are run at all.
If you go to https://travis-ci.org/boostorg/iostreams you'll see that there are two jobs, the first one is the Linux one, with TOOLSET=gcc,clang - it passes. The second one is the OS X one, and it fails. https://travis-ci.org/boostorg/iostreams/builds/175183220 https://travis-ci.org/boostorg/iostreams/jobs/175183221 https://travis-ci.org/boostorg/iostreams/jobs/175183222
If I had to guess I would test for defined(_LIBCPP_VERSION) && defined(__APPLE__).
I can do that. Maybe add a test that just outputs the clang version and libcpp version and then use that specifically after it cycles in the regression tests to define BOOST_IOSTREAMS_NO_PRIMARY_CODECVT_DEFINITION.
_LIBCPP_VERSION is libc++ version 1101 _LIBCPP_VERSION =1101 and clang's version is "Clang version 7.0.2" but I have a hunch that all Apple versions will behave in this way. Not sure about libc++ on other platforms such as Linux.
but I have a hunch that all Apple versions will behave in this way. Not sure about libc++ on other platforms such as Linux.
Yeah, we don't have a tester using libc++ on Linux, but its source is here: http://llvm.org/svn/llvm-project/libcxx/trunk/include/__locale and there's no primary definition. So it's not version specific and not Apple specific.
Edward Diener wrote:
To me its guesswork since I do not know what version of clang is being used or what version of libc++ is being used...
To capture this information from Travis, you can add - ./b2 --verbose-test libs/config/test//config_info toolset=$TOOLSET || true before (or after) - ./b2 libs/iostreams/test toolset=$TOOLSET
On Sat, Nov 12, 2016 at 10:30 AM, Peter Dimov
Edward Diener wrote:
To me its guesswork since I do not know what version of clang is being
used or what version of libc++ is being used...
To capture this information from Travis, you can add
- ./b2 --verbose-test libs/config/test//config_info toolset=$TOOLSET || true
before (or after)
- ./b2 libs/iostreams/test toolset=$TOOLSET
With the scripts Predef is using you can specify which version of Xcode to use. For Travis this means selecting the OSX image to run as they install different VMs for each version. The current default for Travis is Xcode 7.3.1 https://docs.travis-ci.com/user/osx-ci-environment/#OS-X-Version. Which translates to clang 7.0.. The latest version I test is Xcode 7.2 which is clang 7.0.2 < https://travis-ci.org/boostorg/predef/jobs/146713474#L99>. I'm adding the rest of the Xcode, clangs, gcc, and msvcs today to my testing. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
Rene Rivera wrote:
With the scripts Predef is using you can specify which version of Xcode to use.
Yes, what matrix to use is a matter of taste. I use Travis as a quick smoke test so I just run two jobs, one Linux, one OS X. I deliberately keep them at C++03 as this configuration is undertested. If however extensive test coverage is the goal, one can go with a full-blown matrix of g++ versions, OS X images and -std options.
On 11/12/2016 10:30 AM, Peter Dimov wrote:
Edward Diener wrote:
To me its guesswork since I do not know what version of clang is being used or what version of libc++ is being used...
To capture this information from Travis, you can add
- ./b2 --verbose-test libs/config/test//config_info toolset=$TOOLSET || true
before (or after)
- ./b2 libs/iostreams/test toolset=$TOOLSET
Done.
On 11/10/2016 9:05 PM, Rene Rivera wrote:
On Thu, Nov 10, 2016 at 8:39 PM, Edward Diener
wrote: On 11/10/2016 4:26 PM, Peter Dimov wrote:
Edward Diener wrote:
is there any documentation on how to setup a Boost submodule for
testing using Travis CI ?
The procedure is
1. Add a .travis.yml file in the root of the repository. This file describes what Travis should do.
I do not see anything at https://docs.travis-ci.com/ that gives the details of the .travis.yml file so that I can create an appropriate one for a Boost library. If it exists it is well-hidden on the website.
You can look at other Boost libraries for examples. Although I'm also working on a general .travis.yml file that any library can use with some common scripts that will eventually integrate with the general Boost test regression results reports. For that you can copy the one from Predef < https://github.com/boostorg/predef/blob/develop/.travis.yml>. Literally copy-paste and minor edits for that one.
Looking at the .travis.yml in predef, other than the 'notifications:' section, is the file meant to work with any Boost library and travis CI ? Also the appveyor.yml in predef, other than the 'notifications:' section, looks like it is supposed to work with any Boost library for appveyor. Is that also the case ? Or am I supposed to massage the script.py for a different library ( I know Python ) ?
2. Go to https://travis-ci.org/boostorg/iostreams (taking iostreams as
an example) and click the Activate button.
It says it is not an active repository and I do not have sufficient rights. I am not an iostreams Admin so this makes sense.
I can turn it on for you whenever you want me to. As I have admin access to all and own the TravisCI general account :-)
On Fri, Nov 11, 2016 at 10:18 AM, Edward Diener
On 11/10/2016 9:05 PM, Rene Rivera wrote:
On Thu, Nov 10, 2016 at 8:39 PM, Edward Diener
wrote: On 11/10/2016 4:26 PM, Peter Dimov wrote:
Edward Diener wrote:
is there any documentation on how to setup a Boost submodule for
testing using Travis CI ?
The procedure is
1. Add a .travis.yml file in the root of the repository. This file describes what Travis should do.
I do not see anything at https://docs.travis-ci.com/ that gives the details of the .travis.yml file so that I can create an appropriate one for a Boost library. If it exists it is well-hidden on the website.
You can look at other Boost libraries for examples. Although I'm also working on a general .travis.yml file that any library can use with some common scripts that will eventually integrate with the general Boost test regression results reports. For that you can copy the one from Predef < https://github.com/boostorg/predef/blob/develop/.travis.yml>. Literally copy-paste and minor edits for that one.
Looking at the .travis.yml in predef, other than the 'notifications:' section, is the file meant to work with any Boost library and travis CI ? Also the appveyor.yml in predef, other than the 'notifications:' section, looks like it is supposed to work with any Boost library for appveyor. Is that also the case ?
Yes that is the intent. I went under the true and tried plan that the less work someone has to do the more likely they are to do it :-) Although there are other things you can do.. Like remove some of the toolsets being tested. As the list for Predef is maximal for both testing all the options for the CI script and for Prefef which is all about detecting variations in toolsets.
Or am I supposed to massage the script.py for a different library ( I know Python ) ?
I sure hope not. But if you find you need to do that we should discuss what you need so that I, or someone else, can account for it as we move forward with the modular CI testing system. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
On 11/11/2016 10:57 AM, Rene Rivera wrote:
On Fri, Nov 11, 2016 at 10:18 AM, Edward Diener
wrote: On 11/10/2016 9:05 PM, Rene Rivera wrote:
On Thu, Nov 10, 2016 at 8:39 PM, Edward Diener
wrote: On 11/10/2016 4:26 PM, Peter Dimov wrote:
Edward Diener wrote:
is there any documentation on how to setup a Boost submodule for
testing using Travis CI ?
The procedure is
1. Add a .travis.yml file in the root of the repository. This file describes what Travis should do.
I do not see anything at https://docs.travis-ci.com/ that gives the details of the .travis.yml file so that I can create an appropriate one for a Boost library. If it exists it is well-hidden on the website.
You can look at other Boost libraries for examples. Although I'm also working on a general .travis.yml file that any library can use with some common scripts that will eventually integrate with the general Boost test regression results reports. For that you can copy the one from Predef < https://github.com/boostorg/predef/blob/develop/.travis.yml>. Literally copy-paste and minor edits for that one.
Looking at the .travis.yml in predef, other than the 'notifications:' section, is the file meant to work with any Boost library and travis CI ? Also the appveyor.yml in predef, other than the 'notifications:' section, looks like it is supposed to work with any Boost library for appveyor. Is that also the case ?
Yes that is the intent. I went under the true and tried plan that the less work someone has to do the more likely they are to do it :-)
Agreed !
Although there are other things you can do.. Like remove some of the toolsets being tested. As the list for Predef is maximal for both testing all the options for the CI script and for Prefef which is all about detecting variations in toolsets.
I can see the toolsets listed. For the .travis.yml it does not appear that the many of the latest clang and gcc are there. How do you know what toolsets travis CI actually contains for testing ? For gcc 5.1 is pretty old compared to 5.2, 5.3, 5.4, 6.1, 6.2. For clang there exists 3.7, 3.8, and 3.9 which has been officially released. The appveyor.yml does list the major releases of VC++ I usually test against on Windows ( I can also manually test against VS2005 ), but probably compliance from VS2008 and VS2010 should not be expected for many libraries.
Or am I supposed to massage the script.py for a different library ( I know Python ) ?
I sure hope not. But if you find you need to do that we should discuss what you need so that I, or someone else, can account for it as we move forward with the modular CI testing system.
If I don't need to modify it to test other Boost libraries I am fine with it.
Edward Diener wrote:
Looking at the .travis.yml in predef, ...
For an example that is easier to follow, you can look at the .travis.yml of Boost.Function: https://github.com/boostorg/function/blob/develop/.travis.yml The only problematic part there is the manual enumeration of the necessary submodules that comprise the minimal subset needed for testing Function, although I'm working on automating that.
On 11/11/2016 11:54 AM, Peter Dimov wrote:
Edward Diener wrote:
Looking at the .travis.yml in predef, ...
For an example that is easier to follow, you can look at the .travis.yml of Boost.Function:
https://github.com/boostorg/function/blob/develop/.travis.yml
I did look at that. Don't you need an e-mail address for the notifications ?
The only problematic part there is the manual enumeration of the necessary submodules that comprise the minimal subset needed for testing Function, although I'm working on automating that.
Are the 'git submodule init's supposed to te the Boost libraries on which Boost function depends ?
Edward Diener wrote:
https://github.com/boostorg/function/blob/develop/.travis.yml
I did look at that. Don't you need an e-mail address for the notifications ?
Travis automatically sends an e-mail notification to the committer.
Are the 'git submodule init's supposed to te the Boost libraries on which Boost function depends ?
Yes.
On Fri, Nov 11, 2016 at 2:43 PM, Peter Dimov
Edward Diener wrote:
https://github.com/boostorg/function/blob/develop/.travis.yml
I did look at that. Don't you need an e-mail address for the notifications ?
Travis automatically sends an e-mail notification to the committer.
For the Predef use case I included it so people could see it was possible to make it something else that the default quickly. As some libraries have email aliases / lists set up for the group of maintainers for the library. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
On 11/07/16 18:01, Edward Diener wrote:
I have been making fixes on the 'develop' branch of various CMT libraries, but I don't think it should be an issue for 1.63 so close to release. In other words I think it too dangerous to push these fixes for 1.63 as it is now scheduled and I don't see why we can't wait for 1.64. While we try to satisfy VC++ end-users because VC++ is a very heavily used compiler I would not compromise the integrity of the release for this issue. If Boost decides to push back the 1.63 release by a few weeks to satisfy this single concern, then I can see trying to push through these changes for 1.63.
I'd rather have 1.63 released in time but without all the fixes for MSVC. Just my 2 cents. Also, isn't there a way to bring those deprecated components back even in the C++17 mode? A macro or a compiler switch? The standard library still has to have them for C++14 mode, doesn't it?
[Andrey Semashev]
Also, isn't there a way to bring those deprecated components back even in the C++17 mode? A macro or a compiler switch? The standard library still has to have them for C++14 mode, doesn't it?
We support _HAS_AUTO_PTR_ETC=1 and other escape hatches. However, this choice should be made by the programmer-user, not by libraries. Additionally, note that I will be pushing for complete removal of non-Standard features (like the tr1 namespace, etc.) in future versions. STL
On 11/07/16 21:07, Stephan T. Lavavej wrote:
[Andrey Semashev]
Also, isn't there a way to bring those deprecated components back even in the C++17 mode? A macro or a compiler switch? The standard library still has to have them for C++14 mode, doesn't it?
We support _HAS_AUTO_PTR_ETC=1 and other escape hatches. However, this choice should be made by the programmer-user, not by libraries.
The idea is that we can release Boost saying that it currently requires MSVC users to define _HAS_AUTO_PTR_ETC=1. In other words, the topic is not a showstopper problem.
On 11/07/16 02:31, Peter Dimov wrote:
Marshall Clow wrote:
In case I wasn't clear: I think we definitely want these fixes in 1.63.0
OK, here are the changes for review:
Bind:
https://github.com/boostorg/bind/commit/60d3e0f4f3f44af38a8c72bc90d89714c913...
The added main() has no return statement.
Smart_ptr:
https://github.com/boostorg/smart_ptr/commit/a7fbb0a8415acae2a8507d697653930...
Same in test/auto_ptr_rv_test.cpp, too.
participants (15)
-
Andrey Semashev
-
Beman Dawes
-
Daniel James
-
Daniela Engert
-
Edward Diener
-
John Maddock
-
Josh Juran
-
Marshall Clow
-
Pete Bartlett
-
Peter Dimov
-
Rene Rivera
-
Robert Ramey
-
Stephan T. Lavavej
-
Vinnie Falco
-
Зайцев Александр