Tests that enable <warnings-as-errors>on
Some test suites, for example Pool and Units, use '<warnings-as-errors>on' in their project requirements, to test for a warning-free compilation. Pool, f.ex. has project : requrements <toolset>gcc:<warnings-as-errors>on <toolset>msvc:<warnings-as-errors>on ; (among others.) This, however, is propagated to dependencies, so that in [ run test_threading.cpp : : : <threading>multi <library>/boost/thread//boost_thread ] Boost.Thread is also built with '<warnings-as-errors>on', which fails. (In addition, some other tests also fail because of warnings.) So I tried to use '<warnings-as-errors>off' only for some tests, but I was unable to come up with a syntax that worked. Putting -<toolset>msvc:<warnings-as-errors>on in the test requirements didn't (no effect). <toolset>msvc:<warnings-as-errors>off didn't (conflict). -<warnings-as-errors>on didn't (no effect). -<warnings-as-errors>on <warnings-as-errors>off didn't (no effect). Is there a way to override the project requirements from the run rule?
On Thu, Jan 15, 2015 at 8:50 AM, Peter Dimov
Some test suites, for example Pool and Units, use '<warnings-as-errors>on' in their project requirements, to test for a warning-free compilation.
Pool, f.ex. has
project : requrements <toolset>gcc:<warnings-as-errors>on <toolset>msvc:<warnings-as-errors>on ;
(among others.)
This, however, is propagated to dependencies, so that in
[ run test_threading.cpp : : : <threading>multi <library>/boost/thread//boost_thread ]
Boost.Thread is also built with '<warnings-as-errors>on', which fails. (In addition, some other tests also fail because of warnings.)
So I tried to use '<warnings-as-errors>off' only for some tests, but I was unable to come up with a syntax that worked. Putting -<toolset>msvc:<warnings-as-errors>on in the test requirements didn't (no effect). <toolset>msvc:<warnings-as-errors>off didn't (conflict). -<warnings-as-errors>on didn't (no effect). -<warnings-as-errors>on <warnings-as-errors>off didn't (no effect).
Is there a way to override the project requirements from the run rule?
Don't know... But you could change the build rules for Pool, etc, to only use <warning-as-errors>on when doing the compile only. It means adding build targets for the *.o files for the appropriate tests. Which could be "automated" with a rule local to Pool, etc. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
participants (2)
-
Peter Dimov
-
Rene Rivera