From: Vladimir Prus (ghost_at_[hidden])
Date: 2006-11-22 14:34:56
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".
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk