> I believe it's -tused you're referring to, isn't it?
Yep.
> Maybe you're planning to build two tests?
I already am, see for example: libs/config/test/has_pthread_ma_st_fail.cpp
and libs/config/test/has_pthread_ma_st_pass.cpp
John Maddock
http://ourworld.compuserve.com/homepages/john_maddock/
> That sounds like a smart move. It should be easy enough if we can
> encode that feature into the toolsets. Can you take care of that part
> of the job? If so, it would be very easy for me to update testing.jam
> and we'd be done.
Not easily, I don't currently have access to those compilers (a
> > the problem remains, if we have a "compile-fail" test, the failure
> > may be delayed until link time if the compiler does link-time
> > template instantiation. The reason we're not seeing this cropping
> > up in the current tests, is that the compilers that were exhibiting
> > that behaviour
> I intentionally changed it because it seemed as though a test which
> was supposed to fail to link, but which fails to compile should not be
> deemed a success. I think I did this by analogy with run-fail, where
> we were masking some actual compile-time failures which should not
> have been reg
>
> That test seems to not compile. A test that is supposed to not link
> fails if it doesn't even get to the link stage.
>
> Why is this test labelled link-fail?
> I don't know. Jeremy?
That's not the meaning of the original link-fail test: we started off with
compile-fail, but because some com
I notice from the Win32 regression test results that all compilers are
listed as failing the static_assert_test_fail_8 "link-fail" test. Yet when
I look at the actual Jam output they are actually *passing* the test. Any
ideas what's going on?
John Maddock
http://ourworld.compuserve.com/homepages
