Boost.Build requirements to exclude GCC 5
Outcome is now into Boost, and is being tested nightly: Docs in BoostDoc theme: https://www.boost.org/doc/libs/develop/libs/outcome/doc/html/index.html Regression matrix: https://www.boost.org/development/tests/develop/developer/outcome.html One problem is how to exclude from testing GCC 5 which Outcome cannot support due to GCC 5's incorrect parsing of variable templates in nested template classes [1], so I need some sort of Boost.Build project requirement which explicitly excludes GCC 5. Unfortunately, GCC 5 appears to Boost.Config as fully implementing C++ 14, so this is not straightforward. What might work is to specify a requirement for one of the library items at https://github.com/boostorg/config/blob/develop/checks/Jamfile.v2 which we know for a fact libstdc++ 5 does not implement, but libstdc++ 6 does. However, clang with libstdc++ 5 would then be excluded incorrectly, as clang does not have this parsing bug. I guess ideally speaking Boost.Config gains a new test testing for this specific compiler parsing bug. But it seems a bit much to ask for this just for Outcome. Guidance is sought! Niall [1]: https://www.boost.org/development/tests/develop/developer/output/teeks99-02-...
On Mon, Jan 14, 2019 at 2:35 PM Niall Douglas via Boost < boost@lists.boost.org> wrote:
I guess ideally speaking Boost.Config gains a new test testing for this specific compiler parsing bug. But it seems a bit much to ask for this just for Outcome.
One option is to use the Predef checks < https://www.boost.org/doc/libs/release/doc/html/predef/check_utilities.html#predef.check_utilities.using_with_boost_build>. Another option is to implement a check program of your own. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net
Rene Rivera wrote:
On Mon, Jan 14, 2019 at 2:35 PM Niall Douglas via Boost < boost@lists.boost.org> wrote:
I guess ideally speaking Boost.Config gains a new test testing for this specific compiler parsing bug. But it seems a bit much to ask for this just for Outcome.
One option is to use the Predef checks https://www.boost.org/doc/libs/release/doc/html/predef/check_utilities.html#.... Another option is to implement a check program of your own.
Would it be possible to make `<toolset>gcc-5:<build>no` match `toolset=gcc`, major version 5, any minor version? At present, it requires an exact version match, which isn't very convenient. Similarly, <toolset>gcc-4.6 should match f.ex. gcc-4.6.2.
I guess ideally speaking Boost.Config gains a new test testing for this specific compiler parsing bug. But it seems a bit much to ask for this just for Outcome.
One option is to use the Predef checks < https://www.boost.org/doc/libs/release/doc/html/predef/check_utilities.html#predef.check_utilities.using_with_boost_build>. Another option is to implement a check program of your own.
So, stitching together from your linked docs, something like (untested): project : requirements [ requires cxx14_variable_templates cxx14_constexpr ] [ predef-require "BOOST_GCC == 0" or "BOOST_GCC_VERSION >= 60000" ] <define>BOOST_TEST_MODULE=Outcome <library>../../test/build//boost_unit_test_framework ; ??? Niall
On 14/01/2019 21:05, Niall Douglas via Boost wrote:
I guess ideally speaking Boost.Config gains a new test testing for this specific compiler parsing bug. But it seems a bit much to ask for this just for Outcome.
One option is to use the Predef checks < https://www.boost.org/doc/libs/release/doc/html/predef/check_utilities.html#predef.check_utilities.using_with_boost_build>. Another option is to implement a check program of your own.
So, stitching together from your linked docs, something like (untested): [snip]
After an amount of trial and error, I came up with: [ predef-require "!BOOST_COMP_GNUC" or "BOOST_COMP_GNUC >= 6.0" ] Note that the documentation for Predef does not say that the above syntax works - I had to dig into the jam source and inspect the temporary files generated by Predef to figure out the above. Predef's documentation ought to mention that the "!" operator is supported for detecting undefinedness, as comparing equal to 0 does not work as expected due to "0" being expanded into BOOST_VERSION_NUMBER(0,0,0) which did not test to true when the compiler was MSVC. It also ought to explain how version strings in the Build checks are parsed into BOOST_VERSION_NUMBER(...), because my first "obvious" five attempts yielded malformed C. Anyway, looks like we have a solution. Thanks for the help. Niall
AMDG On 1/14/19 1:34 PM, Niall Douglas via Boost wrote:
Outcome is now into Boost, and is being tested nightly:
Docs in BoostDoc theme: https://www.boost.org/doc/libs/develop/libs/outcome/doc/html/index.html
Regression matrix: https://www.boost.org/development/tests/develop/developer/outcome.html
One problem is how to exclude from testing GCC 5 which Outcome cannot support due to GCC 5's incorrect parsing of variable templates in nested template classes [1], so I need some sort of Boost.Build project requirement which explicitly excludes GCC 5.
Unfortunately, GCC 5 appears to Boost.Config as fully implementing C++ 14, so this is not straightforward.
You can use predef for compiler version checks. https://www.boost.org/doc/html/predef/check_utilities.html
What might work is to specify a requirement for one of the library items at https://github.com/boostorg/config/blob/develop/checks/Jamfile.v2 which we know for a fact libstdc++ 5 does not implement, but libstdc++ 6 does. However, clang with libstdc++ 5 would then be excluded incorrectly, as clang does not have this parsing bug.
There's nothing stopping you from writing a check for this bug yourself: obj test_gcc_5_bug : test_gcc_5_bug.cpp ; # fails to compile on gcc 5 ... [ check-target-builds test_gcc_5_bug : : <build>no ]
I guess ideally speaking Boost.Config gains a new test testing for this specific compiler parsing bug. But it seems a bit much to ask for this just for Outcome.
Guidance is sought!
In Christ, Steven Watanabe
participants (4)
-
Niall Douglas -
Peter Dimov -
Rene Rivera -
Steven Watanabe