Boost logo

Boost :

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".

- Volodya

Boost list run by bdawes at, gregod at, cpdaniel at, john at