Recommend dropping test coverage on msvc-7.1 and msvc-8.0
MSVC 7.1 and MSVC 8.0 are currently listed as "tested" in the Boost 1.65.1 release notes however there are a lot of projects that do not seem to support them well, if at all: http://www.boost.org/development/tests/master/developer/issues.html <http://www.boost.org/development/tests/develop/developer/issues.html> It looks like a large number of libraries will no longer build properly against them based on this report. I'm not sure what the procedure is to come to an agreement to drop a compiler in a release, but it looks like we should consider dropping msvc-7.1 and msvc-8.0. These are very old compilers for Windows development. Dropping them would also allow folks to more easily focus on failures in this report to make sure a release is as clean as possible and simplify the test matrix a little bit. Appveyor only supports back to Visual Studio 2010 at this point, so our ability to get pre-commit checks on compilers before msvc-10.0 is solely based on maintainer effort. I suspect this effort is no longer justified based on the age of the compilers. Thanks - Jim
On 14 October 2017 at 14:41, James E. King, III via Boost < boost@lists.boost.org> wrote:
... but it looks like we should consider dropping msvc-7.1 and msvc-8.0. These are very old compilers for Windows development.
Although I understand my opinion is not even worth 2 Cents and feel like Cato The Elder must have felt, I'll put them [2 Cents] in anyway. I think Boost should only support MSVC-versions, that are supported by Microsoft. Unsupported versions have un-supported c-run-time-libraries and are hencefort a danger for the planet. It would also start to simplify things a bit (probably a lot) going forward as we are expecting MSVC to be fully compliant (including the preprocessor (good news Edward!)) bar bugs, somewhere in the first half of 2018. Just to conclude: "Carthago delenda est". degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798
On Sat, Oct 14, 2017 at 8:29 AM, degski via Boost <boost@lists.boost.org> wrote:
On 14 October 2017 at 14:41, James E. King, III via Boost < boost@lists.boost.org> wrote:
... but it looks like we should consider dropping msvc-7.1 and msvc-8.0. These are very old compilers for Windows development.
Although I understand my opinion is not even worth 2 Cents and feel like Cato The Elder must have felt, I'll put them [2 Cents] in anyway.
I think Boost should only support MSVC-versions, that are supported by Microsoft. Unsupported versions have un-supported c-run-time-libraries and are hencefort a danger for the planet.
It would also start to simplify things a bit (probably a lot) going forward as we are expecting MSVC to be fully compliant (including the preprocessor (good news Edward!)) bar bugs, somewhere in the first half of 2018.
Just to conclude: "Carthago delenda est".
degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798
I'm not sure whether that is too aggressive or not, but I would have no objection to it. I went back and looked up some EOS dates for Visual Studio releases using: https://support.microsoft.com/en-us/lifecycle/search Visual Studio 2005: 2008-JAN-08 (last support pack; no extended support offered) Visual Studio 2008: 2009-OCT-13 (last support pack; no extended support offered) Visual Studio 2010: 2012-APR-10 (last support pack; no extended support offered) --- Visual Studio 2012: 2023-JAN-10 (extended support ends) Visual Studio 2013: 2024-APR-09 (extended support ends) Visual Studio 2015: 2025-OCT-14 (extended support ends) Visual Studio 2017: 2027-APT-13 (extended support ends) Folks are still able to use older boost releases with older compilers to continue supporting their older applications... - Jim
James E. King, III wrote:
Visual Studio 2005: 2008-JAN-08 (last support pack; no extended support offered) Visual Studio 2008: 2009-OCT-13 (last support pack; no extended support offered) Visual Studio 2010: 2012-APR-10 (last support pack; no extended support offered)
Nope, that's Microsoft Visual Studio 2005 Service Pack 1: 12/4/2016 (RIP) Microsoft Visual Studio 2008 Service Pack 1: 4/10/2018 Microsoft Visual Studio 2010 Service Pack 1: 7/14/2020 Appveyor still has msvc-9.0, does it not? It seems to work for me.
On 14 October 2017 at 16:26, Peter Dimov via Boost <boost@lists.boost.org> wrote:
James E. King, III wrote:
Visual Studio 2005: 2008-JAN-08 (last support pack; no extended support
offered) Visual Studio 2008: 2009-OCT-13 (last support pack; no extended support offered) Visual Studio 2010: 2012-APR-10 (last support pack; no extended support offered)
Nope, that's
Microsoft Visual Studio 2005 Service Pack 1: 12/4/2016 (RIP) Microsoft Visual Studio 2008 Service Pack 1: 4/10/2018 Microsoft Visual Studio 2010 Service Pack 1: 7/14/2020
Appveyor still has msvc-9.0, does it not? It seems to work for me.
Bikeshedding is cool, no discussion. But, I would like to ask you, in your (tomorrow's) perfect world, which versions of MSVC do *you* think should be supported in boost, taking into account older boost releases are available for people/companies that are of the opinion that AC-electricity is very dangerous and feel a car is very different from a horse? degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798
degski wrote:
Bikeshedding is cool, no discussion.
That's not bikeshedding. It was you who suggested using EOL dates. If you're going to use EOL dates, one would think you'd need to know what these dates actually are.
But, I would like to ask you, in your (tomorrow's) perfect world, which versions of MSVC do *you* think should be supported in boost, ...
Dropping 7.1 and 8.0 seems entirely reasonable to me, even though I don't know what specifically do you mean by "supported in boost". (I still test locally on msvc-8.0, but don't require support from others.)
On Sat, Oct 14, 2017 at 9:26 AM, Peter Dimov via Boost < boost@lists.boost.org> wrote:
James E. King, III wrote:
Visual Studio 2005: 2008-JAN-08 (last support pack; no extended support
offered) Visual Studio 2008: 2009-OCT-13 (last support pack; no extended support offered) Visual Studio 2010: 2012-APR-10 (last support pack; no extended support offered)
Nope, that's
Microsoft Visual Studio 2005 Service Pack 1: 12/4/2016 (RIP) Microsoft Visual Studio 2008 Service Pack 1: 4/10/2018 Microsoft Visual Studio 2010 Service Pack 1: 7/14/2020
Appveyor still has msvc-9.0, does it not? It seems to work for me.
They do; how come that information didn't come up on Microsoft's own search link? Thanks for providing the correct information. - Jim
On 10/14/2017 8:29 AM, degski via Boost wrote:
On 14 October 2017 at 14:41, James E. King, III via Boost < boost@lists.boost.org> wrote:
... but it looks like we should consider dropping msvc-7.1 and msvc-8.0. These are very old compilers for Windows development.
Although I understand my opinion is not even worth 2 Cents and feel like Cato The Elder must have felt, I'll put them [2 Cents] in anyway.
I think Boost should only support MSVC-versions, that are supported by Microsoft. Unsupported versions have un-supported c-run-time-libraries and are hencefort a danger for the planet.
It would also start to simplify things a bit (probably a lot) going forward as we are expecting MSVC to be fully compliant (including the preprocessor (good news Edward!)) bar bugs, somewhere in the first half of 2018.
Microsoft has "promised" to fix their broken preprocessor so many times, without actually doing so, that one more "promise" means nothing. I do not test locally with msvc-7.1 or earlier, but I do test occasionally with msvc-8.0, although it does have more problems than msvc-9.0 on up.
Just to conclude: "Carthago delenda est".
degski
On 14 October 2017 at 18:05, Edward Diener via Boost <boost@lists.boost.org> wrote:
Microsoft has "promised" to fix their broken preprocessor so many times, without actually doing so, that one more "promise" means nothing.
Lighten up! Get a good BIB in SB, enjoy and forget about the past. MS is not just bug-fixing, they are re-arranging the deck-chairs (C++17, re-writing the PP and 1 -> 2-phase lookup a.o.), it's said to be done by (they said before) mid 2018 (they never said stuff like that before, mind you)... degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798
On 10/14/2017 11:52 AM, degski via Boost wrote:
On 14 October 2017 at 18:05, Edward Diener via Boost <boost@lists.boost.org> wrote:
Microsoft has "promised" to fix their broken preprocessor so many times, without actually doing so, that one more "promise" means nothing.
Lighten up! Get a good BIB in SB,
BIB in SB ? BMRMSPOTATIAAALUAAHCB. ( Believe me regarding MS promises of this and that I am about as "lightened" up as a human could be. )
enjoy and forget about the past. MS is not just bug-fixing, they are re-arranging the deck-chairs (C++17, re-writing the PP and 1 -> 2-phase lookup a.o.), it's said to be done by (they said before) mid 2018 (they never said stuff like that before, mind you)...
Wowie, zowie, ain't we lucky, but I am not holding my breath about it. Getting back to seriousness and the OP, I think it has always been fairly well understood that a particular Boost library can drop support for older, unsupported compilers if it deems that appropriate, but that it should usually deprecate that change first in one release before it goes ahead and does it in the subsequent release. This is no different in how it is usually handled than any other potentially code-breaking change within a Boost library.
degski
On 14 October 2017 at 12:41, James E. King, III via Boost <boost@lists.boost.org> wrote:
It looks like a large number of libraries will no longer build properly against them based on this report. I'm not sure what the procedure is to come to an agreement to drop a compiler in a release, but it looks like we should consider dropping msvc-7.1 and msvc-8.0. These are very old compilers for Windows development. Dropping them would also allow folks to more easily focus on failures in this report to make sure a release is as clean as possible and simplify the test matrix a little bit.
They can now be marked as unusable from your very own repo, I haven't documented it yet, but an example that does that: https://github.com/boostorg/contract/blob/develop/meta/explicit-failures-mar... That will grey out the results in the test matrix, making it easier to read, and there's no need to drop the test results for anyone who finds them useful.
On Sat, Oct 14, 2017 at 9:02 AM, Daniel James via Boost < boost@lists.boost.org> wrote:
On 14 October 2017 at 12:41, James E. King, III via Boost <boost@lists.boost.org> wrote:
It looks like a large number of libraries will no longer build properly against them based on this report. I'm not sure what the procedure is to come to an agreement to drop a compiler in a release, but it looks like
we
should consider dropping msvc-7.1 and msvc-8.0. These are very old compilers for Windows development. Dropping them would also allow folks to more easily focus on failures in this report to make sure a release is as clean as possible and simplify the test matrix a little bit.
They can now be marked as unusable from your very own repo, I haven't documented it yet, but an example that does that:
https://github.com/boostorg/contract/blob/develop/meta/ explicit-failures-markup.xml
That will grey out the results in the test matrix, making it easier to read, and there's no need to drop the test results for anyone who finds them useful.
Thanks that is useful! I'm still concerned about limiting the scope of reasonable testing effort and compiler support to reduce the amount of maintenance and test matrix systems for the project overall. It seems fairly clear from those test matrix results that msvc-7.1 and msvc-8.0 are no longer healthily supported by many libraries, and as previously stated both of those compiler suites are past end of support. I think that result matrix is most useful when it doesn't have that many things in it, so folks can focus on closing down a release. I'm not sure if graying out the items will help identify problem spots. If there was a way to filter out certain toolset identifiers, on the page, that might solve that problem. - Jim
On 10/14/17 6:09 AM, James E. King, III via Boost wrote:
Thanks that is useful! I'm still concerned about limiting the scope of reasonable testing effort and compiler support to reduce the amount of maintenance and test matrix systems for the project overall. It seems fairly clear from those test matrix results that msvc-7.1 and msvc-8.0 are no longer healthily supported by many libraries, and as previously stated both of those compiler suites are past end of support.
I think that result matrix is most useful when it doesn't have that many things in it, so folks can focus on closing down a release. I'm not sure if graying out the items will help identify problem spots. If there was a way to filter out certain toolset identifiers, on the page, that might solve that problem.
The current test matrix has a number of issues. First of all it doesn't display differences by variant, linkage, C++ version in a coherent and organized way. I made an attempt to address this with library_status described here http://www.boost.org/doc/libs/1_54_0/tools/regression/doc/library_status.htm... But what I would really like is to see our testing matrix upgraded to a testing results database and browser cube. So one would do something like: library_status -columns compilers=... or all, variant,linkage ... rows test or library_status -columns tests rows compilers ... or whatever I would also like to be able to easily post the result run from any machine, including my desktop to the common results database regardless if they were generated by boost build, CMake or even some other homebrew setup. That is, I would like to see test results posting design decoupled from any particular build system. Of course this would be a very ambitious project. On the upside, we have a lot of the pieces done or partly done or residing in current components like regression.py . Robert Ramey
On Sat, Oct 14, 2017 at 6:41 AM, James E. King, III via Boost < boost@lists.boost.org> wrote:
MSVC 7.1 and MSVC 8.0 are currently listed as "tested" in the Boost 1.65.1 release notes however there are a lot of projects that do not seem to support them well, if at all:
http://www.boost.org/development/tests/master/developer/issues.html <http://www.boost.org/development/tests/develop/developer/issues.html>
It looks like a large number of libraries will no longer build properly against them based on this report. I'm not sure what the procedure is to come to an agreement to drop a compiler in a release, but it looks like we should consider dropping msvc-7.1 and msvc-8.0. These are very old compilers for Windows development. Dropping them would also allow folks to more easily focus on failures in this report to make sure a release is as clean as possible and simplify the test matrix a little bit.
Appveyor only supports back to Visual Studio 2010 at this point, so our ability to get pre-commit checks on compilers before msvc-10.0 is solely based on maintainer effort. I suspect this effort is no longer justified based on the age of the compilers.
Thanks - Jim
It seems like there is a big gap between 7.1 and 8.0 in terms of support. It looks like there are only a handful of libraries that have failures in 8.0 that then pass in >13.0. On the other hand, 7.1 has a lot of libraries (maybe the majority) with additional failures. Indeed when doing the binary builds with each release, there have been a lot of failures since 1.45 and I haven't included it in any binary releases since then. On the other hand, 8.0 still builds successfully for all the libraries that we build binaries for. That said, I've been expecting that any day now we'll have issues building something or other for 8.0 and 9.0...if that happens I'll stop building the binary releases for them at that time. The real problem with saying that a version isn't supported is deciding which one. Some libraries probably work back with Visual Studio 6.0! On the other hand, some of the new libraries only work with the very latest versions...excluding some that are still supported by Microsoft. Maybe an explanation that support is actually on a per-library basis and not something determined at the boost project level would be good to add to the documentation. Tom
On 10/14/17 4:41 AM, James E. King, III via Boost wrote:
It looks like a large number of libraries will no longer build properly against them based on this report. I'm not sure what the procedure is to come to an agreement to drop a compiler in a release, but it looks like we should consider dropping msvc-7.1 and msvc-8.0.
There is no procedure. For that matter there is no communal procedure to decide which libraries should be tested either. Basically, Boost is (still) a free country, anyone can test whatever they want and post the results. There is no agreement necessary. Robert Ramey
On Sat, Oct 14, 2017 at 8:33 AM, Robert Ramey via Boost <boost@lists.boost.org> wrote:
There is no procedure. For that matter there is no communal procedure to decide which libraries should be tested either. Basically, Boost is (still) a free country, anyone can test whatever they want and post the results.
Not completely related but I have observed that while Boost has amazing facilities for introducing new libraries (the formal review process) there is nothing for gracefully retiring old libraries. Or for that matter old toolchains.
On 10/14/17 8:37 AM, Vinnie Falco via Boost wrote:
On Sat, Oct 14, 2017 at 8:33 AM, Robert Ramey via Boost
Not completely related but I have observed that while Boost has amazing facilities for introducing new libraries (the formal review process)
there is nothing for gracefully retiring old libraries. Or I have a solution to this - as described part of my boost 2.0 talk. But the world isn't ready for me to start flogging it yet.
for that matter old toolchains.
My point is that selection of toolchains to support and test is upto the library maintainer. There is not communal agreement necessary.
On Sat, Oct 14, 2017 at 12:33 PM, Robert Ramey via Boost < boost@lists.boost.org> wrote:
On 10/14/17 8:37 AM, Vinnie Falco via Boost wrote:
On Sat, Oct 14, 2017 at 8:33 AM, Robert Ramey via Boost
Not completely related but I have observed that while Boost has
amazing facilities for introducing new libraries (the formal review process)
there is nothing for gracefully retiring old libraries. Or
I have a solution to this - as described part of my boost 2.0 talk. But the world isn't ready for me to start flogging it yet.
for that matter old toolchains.
My point is that selection of toolchains to support and test is upto the library maintainer. There is not communal agreement necessary.
That would be far too confusing to consumers of the boost library set. Each release of the boost library set should have a standard set of compilers that are tested. If maintainers of each library want to support more compilers, that is acceptable and should be documented in the library docs. If maintainers of each library want to support less compilers, that would not be acceptable. In terms of potentially dropping msvc-7.1, my original suggestion was for the next whole release cycle. - Jim
On Sat, Oct 14, 2017 at 12:39 PM, James E. King, III via Boost <boost@lists.boost.org> wrote:
If maintainers of each library want to support more compilers, that is acceptable and should be documented in the library docs. If maintainers of each library want to support less compilers, that would not be acceptable.
Nonsense. The collection is tested against many C++ implementations, but Hana for example only supports a very small subset of those C++ implementations. That is completely fine. We don't require library authors to support all the implementations that the collection is tested against. Glen
James E. King, III wrote:
On Sat, Oct 14, 2017 at 12:33 PM, Robert Ramey via Boost < boost@lists.boost.org> wrote:
My point is that selection of toolchains to support and test is upto the library maintainer. There is not communal agreement necessary.
That would be far too confusing to consumers of the boost library set.
"Would be" is not the appropriate tense here as the above describes the status quo, which has been in place for decades now.
Each release of the boost library set should have a standard set of compilers that are tested.
We had the concept of "release compilers" at one point, which was the subset of the matrix in which failures were considered critical obstacles to doing a release; but we seem to have dropped that now. To get back to your unspoken question, I think that you can with clear conscience drop msvc-7.1 and msvc-8.0 as supported compilers for the Format library.
On Sat, Oct 14, 2017 at 1:03 PM, Peter Dimov via Boost < boost@lists.boost.org> wrote:
James E. King, III wrote:
On Sat, Oct 14, 2017 at 12:33 PM, Robert Ramey via Boost < boost@lists.boost.org> wrote:
My point is that selection of toolchains to support and test is upto the
library maintainer. There is not communal agreement necessary.
That would be far too confusing to consumers of the boost library set.
"Would be" is not the appropriate tense here as the above describes the status quo, which has been in place for decades now.
Each release of the boost library set should have a standard set of
compilers that are tested.
We had the concept of "release compilers" at one point, which was the subset of the matrix in which failures were considered critical obstacles to doing a release; but we seem to have dropped that now.
To get back to your unspoken question, I think that you can with clear conscience drop msvc-7.1 and msvc-8.0 as supported compilers for the Format library.
Actually my intention was not to discuss this just for the format library - but for all libraries. There shouldn't be a need to support msvc-7.1 by any library at stated it is past support and I don't think it's worth anybody spending time dealing with it in development or in test at this point. Good points on my nonsense argument from before about not supporting all the versions listed in the release notes. Perhaps additional wording in the release notes would be appropriate, indicating that while a compiler may be part of the boost regression suite, that does not indicate compatibility with every library, so consult documentation for each library for specific limitations. Specifically I am looking at the "Compilers Tested" section. While msvc-7.1 is technically tested, most libraries don't pass. - Jim
James E. King, III wrote:
Actually my intention was not to discuss this just for the format library - but for all libraries. There shouldn't be a need to support msvc-7.1 by any library at stated it is past support and I don't think it's worth anybody spending time dealing with it in development or in test at this point.
The reason we have an msvc-7.1 tester in the matrix is that Ion Gaztañaga cares enough (or cared enough - don't how how strongly he feels about it now) to run it. Having msvc-7.1 tested does not necessarily create any obligation on part of library maintainers to support it; whoever wants to, can.
On Sat, Oct 14, 2017 at 5:25 PM, Peter Dimov via Boost < boost@lists.boost.org> wrote:
James E. King, III wrote:
Actually my intention was not to discuss this just for the format library
- but for all libraries. There shouldn't be a need to support msvc-7.1 by any library at stated it is past support and I don't think it's worth anybody spending time dealing with it in development or in test at this point.
The reason we have an msvc-7.1 tester in the matrix is that Ion Gaztañaga cares enough (or cared enough - don't how how strongly he feels about it now) to run it. Having msvc-7.1 tested does not necessarily create any obligation on part of library maintainers to support it; whoever wants to, can.
+1 --Beman
On 16/10/2017 3:26, Beman Dawes via Boost wrote:
On Sat, Oct 14, 2017 at 5:25 PM, Peter Dimov via Boost < boost@lists.boost.org> wrote:
James E. King, III wrote:
Actually my intention was not to discuss this just for the format library
- but for all libraries. There shouldn't be a need to support msvc-7.1 by any library at stated it is past support and I don't think it's worth anybody spending time dealing with it in development or in test at this point.
The reason we have an msvc-7.1 tester in the matrix is that Ion Gaztañaga cares enough (or cared enough - don't how how strongly he feels about it now) to run it. Having msvc-7.1 tested does not necessarily create any obligation on part of library maintainers to support it; whoever wants to, can.
I care because my libraries support old compilers. The same happens with older GCCs, it's not a msvc-exclusive problem. I think it would be nice if there was a way (maybe it exists now) to state in the test/build jamfile the minimum supported toolchains (say msvc >= 9.0, gcc >= 4.2) by that library / test. This could allow just avoiding the compilation phase, printing a well-known message. The giant error outputs (which requires a huge amount of CPU and time in my runners) would go away and the matrix could just show something like "unsupported" or just avoid showing that column. Best, Ion
Ion Gaztañaga wrote:
I think it would be nice if there was a way (maybe it exists now) to state in the test/build jamfile the minimum supported toolchains (say msvc >= 9.0, gcc >= 4.2) by that library / test.
There is! There are, three of them. One, you can use the Config build requirement feature: http://www.boost.org/doc/libs/1_65_1/libs/config/doc/html/boost_config/build... as I've done here: https://github.com/boostorg/mp11/blob/develop/test/Jamfile#L12 You just have to pick the right set of requirements that include all of the compilers you care about, as sometimes the Config macro is set but you still want to go ahead with the test (f.ex. NO_CXX11_HDR_TYPE_TRAITS on gcc-4.7 in my case.) Two, you can use Predef in the exact same manner, to check any Predef macro: http://www.boost.org/doc/libs/1_65_1/doc/html/predef/check_utilities.html Three, you can just use a built-in Boost.Build feature: project : requirements <toolset>msvc-7:<build>no <toolset>gcc-4.1:<build>no ; This doesn't allow you to compare versions with greater-than, it's just a match, but you could still enumerate whatever you want excluded, and is probably the easiest way to address the msvc-7.1 issue. You can also use all these for a specific test instead of globally, such as f.ex. here: https://github.com/boostorg/vmd/blob/develop/test/Jamfile.v2#L141
On Mon, Oct 16, 2017 at 2:02 PM, Peter Dimov via Boost <boost@lists.boost.org> wrote:
This doesn't allow you to compare versions with greater-than, it's just a match, but you could still enumerate whatever you want excluded, and is probably the easiest way to address the msvc-7.1 issue.
This would require a lot of libs that don't care about msvc-7.1 to do something.. Wouldn't it be simpler to make msvc-7.1 (and 8 and 9) be opt-in instead of opt-out? -- Olaf
On 16/10/2017 14:02, Peter Dimov via Boost wrote:
Ion Gaztañaga wrote:
I think it would be nice if there was a way (maybe it exists now) to state in the test/build jamfile the minimum supported toolchains (say msvc >= 9.0, gcc >= 4.2) by that library / test.
There is! There are, three of them. [...]
Thanks Peter, very interesting and illustrative.
Three, you can just use a built-in Boost.Build feature:
project : requirements <toolset>msvc-7:<build>no <toolset>gcc-4.1:<build>no ;
Toolset name can be defined in user-config.jam so msvc-7 is not a generic solucion, I define in my local regression tests toolsets named like gcc-7.1c++03, gcc-7.1c++14... Maybe an additional feature could be added to filter toolset version with some comparison operator. Just CC'ing Rene in case it's a good idea for future developments. Best, Ion
On Mon, Oct 16, 2017 at 3:11 PM, Ion Gaztañaga <igaztanaga@gmail.com> wrote:
On 16/10/2017 14:02, Peter Dimov via Boost wrote:
Three, you can just use a built-in Boost.Build feature:
project : requirements <toolset>msvc-7:<build>no <toolset>gcc-4.1:<build>no ;
Toolset name can be defined in user-config.jam so msvc-7 is not a generic solucion
But this isn't a generic problem. You want to not run tests for specific toolsets that *testers* run. Hence using the toolset name that testers some times specify seems good enough to me :-)
, I define in my local regression tests toolsets named like gcc-7.1c++03, gcc-7.1c++14... Maybe an additional feature could be added to filter toolset version with some comparison operator. Just CC'ing Rene in case it's a good idea for future developments.
You can already do that.. If you write your own conditional rule and have whatever comparison you want. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
On 16/10/2017 22:34, Rene Rivera via Boost wrote:
On Mon, Oct 16, 2017 at 3:11 PM, Ion Gaztañaga <igaztanaga@gmail.com> wrote:
On 16/10/2017 14:02, Peter Dimov via Boost wrote:
Three, you can just use a built-in Boost.Build feature:
project : requirements <toolset>msvc-7:<build>no <toolset>gcc-4.1:<build>no ;
Toolset name can be defined in user-config.jam so msvc-7 is not a generic solucion
But this isn't a generic problem. You want to not run tests for specific toolsets that *testers* run. Hence using the toolset name that testers some times specify seems good enough to me :-)
I disagree. I want my library or tests not to be built for any toolset that is really MSVC 7.1, I don't want to know every name every tester uses to filter it out (runner or local testing). I understand that I would start checking _MSC_VER macros or using predef, but I guess Boost.Build already knows the version of the toolset, so it might be interesting to use it.
, I define in my local regression tests toolsets named like gcc-7.1c++03, gcc-7.1c++14... Maybe an additional feature could be added to filter toolset version with some comparison operator. Just CC'ing Rene in case it's a good idea for future developments.
You can already do that.. If you write your own conditional rule and have whatever comparison you want.
And how can access to the version of the toolset? the toolset property is the name the user has chosen, the real version of the compiler could not be there, a user can choose gcc-myfavouriteversion as the toolset name. Or am I missing something? Ion
On Mon, Oct 16, 2017 at 4:11 PM, Ion Gaztañaga via Boost < boost@lists.boost.org> wrote:
On 16/10/2017 22:34, Rene Rivera via Boost wrote:
On Mon, Oct 16, 2017 at 3:11 PM, Ion Gaztañaga <igaztanaga@gmail.com> wrote:
On 16/10/2017 14:02, Peter Dimov via Boost wrote:
Three, you can just use a built-in Boost.Build feature:
project : requirements <toolset>msvc-7:<build>no <toolset>gcc-4.1:<build>no ;
Toolset name can be defined in user-config.jam so msvc-7 is not a generic solucion
But this isn't a generic problem. You want to not run tests for specific toolsets that *testers* run. Hence using the toolset name that testers some times specify seems good enough to me :-)
I disagree. I want my library or tests not to be built for any toolset that is really MSVC 7.1, I don't want to know every name every tester uses to filter it out (runner or local testing). I understand that I would start checking _MSC_VER macros or using predef, but I guess Boost.Build already knows the version of the toolset, so it might be interesting to use it.
I see.. Different story then :-)
, I define in my local regression tests toolsets named like gcc-7.1c++03,
gcc-7.1c++14... Maybe an additional feature could be added to filter toolset version with some comparison operator. Just CC'ing Rene in case it's a good idea for future developments.
You can already do that.. If you write your own conditional rule and have whatever comparison you want.
And how can access to the version of the toolset? the toolset property is the name the user has chosen, the real version of the compiler could not be there, a user can choose gcc-myfavouriteversion as the toolset name. Or am I missing something?
Indeed that is a problem with the current version number. And indeed right now there's no way to get the real version number of the compiler as detected by b2. Although for msvc the version number are fixed and you can't alter them like you can for gcc toolset. I.e. it's always going to be "msvc-7.1". So I created an issue for adding that < https://github.com/boostorg/build/issues/253>. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net
On 16/10/2017 23:35, Rene Rivera via Boost wrote:
Indeed that is a problem with the current version number. And indeed right now there's no way to get the real version number of the compiler as detected by b2. Although for msvc the version number are fixed and you can't alter them like you can for gcc toolset. I.e. it's always going to be "msvc-7.1". So I created an issue for adding that < https://github.com/boostorg/build/issues/253>.
Awesome Rene. Many thanks Ion
On 10/14/2017 12:39 PM, James E. King, III via Boost wrote:
On Sat, Oct 14, 2017 at 12:33 PM, Robert Ramey via Boost < boost@lists.boost.org> wrote:
On 10/14/17 8:37 AM, Vinnie Falco via Boost wrote:
On Sat, Oct 14, 2017 at 8:33 AM, Robert Ramey via Boost
Not completely related but I have observed that while Boost has
amazing facilities for introducing new libraries (the formal review process)
there is nothing for gracefully retiring old libraries. Or
I have a solution to this - as described part of my boost 2.0 talk. But the world isn't ready for me to start flogging it yet.
for that matter old toolchains.
My point is that selection of toolchains to support and test is upto the library maintainer. There is not communal agreement necessary.
That would be far too confusing to consumers of the boost library set. Each release of the boost library set should have a standard set of compilers that are tested. If maintainers of each library want to support more compilers, that is acceptable and should be documented in the library docs. If maintainers of each library want to support less compilers, that would not be acceptable.
I disagree with this simply because it is very possible that a given Boost library will not work at all with a given compiler/version simply because of the deficiencies of that compiler when used by that library. Ideally, yes, Boost as a whole should try to support certain modern compilers/versions across the board. But in practice, for some 130+ libraries this is not tenable.
In terms of potentially dropping msvc-7.1, my original suggestion was for the next whole release cycle.
- Jim
participants (13)
-
Beman Dawes -
Daniel James -
degski -
Edward Diener -
Glen Fernandes -
Ion Gaztañaga -
James E. King, III -
Olaf van der Spek -
Peter Dimov -
Rene Rivera -
Robert Ramey -
Tom Kent -
Vinnie Falco