John Maddock wrote:
Robert Ramey wrote:
I saw this and that's what I was referring to. But I'm not sure whether or not it does it.
Here is another case from the serialization library.
Some compilers don't support wide characters and I would to detect this automatically rather than chasing down all the tool sets on a continuing basis.
So the first thought would be to create test in config like:
test_wide_char_support which would fail if the proper define isn't set.
then the tests which would depend on such support would be invoked conditionally upon the SUCCESSFUL completion of test_wide_char support. This is analogous to the makefile behavior in that a program isn't linked if compilation of any one of its components fails. (I realise that the true dependency is on the existence of an updated *.o file - but the result is the same.
As I read the link below - it doesn't seem to help here.
Yep, the docs didn't seem all that clear to me :-(
BTW the wide character test already exists, all the Boost.Config tests have individual tests in libs/config/test as well as the consolidated tests used in the reports. Take a look at the libs/config/configure script to see how these are used in this context.
So... maybe just try it and see? Or else nag Vladimir :-)
I was thinking about some configure checks for Boost.Build just today. I think that at the minimum, something like this (untested!) should work: compile test_that_compiler_is_good_and_shiny.cpp ; unit-test a : a.cpp : <dependency>test_that_compiler_is_good_and_shiny ; If the compile test fails to compile, then 'a' won't be compiled either. We "only" need to make sure that the first test is not added to regression results as "fail". - Volodya