On Jul 5, 2005, at 7:59 AM, David Abrahams wrote:
Douglas Gregor <doug.gregor@gmail.com> writes:
On Jul 3, 2005, at 5:31 AM, Paul Baxter wrote:
In terms of compiler status, if there really is an issue between debug and release (usually bad compiler optimisations) shouldn't we: a) clearly note in the test report we're in debug or release build (can also be discovered by looking at the build directory name)
b) Actually test a compiler using a reasonable set of optimisations since we're trying to report if a compiler can use Boost in actual builds, not in a no optimisation alternative.
I hadn't realized you were running a release built. It is very important to do (for many reasons), but I think we should add "-release" to the end of the toolset name to indicate what we're doing. Then we can more immediately see what problems are caused by compiler optimizations.
It's also important to check through all of our tests to make sure they're not using "assert" and/or to force NDEBUG to be undefined. Otherwise many of our tests could be passing because they have no code to execute.
Well, we *should* be using BOOST_CHECK, because we want assert()s in library code to disappear for release builds to be sure we haven't put an important side effect in them. Doug