Re: [jamboost] Fwd: Re: Boost.Threads and Regression Testing

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-02-27 15:20:03

----- Original Message -----
From: "bill_kempf" <williamkempf_at_[hidden]>
>
> The build specifies <runtime-link>static/dynamic.

Where? Not in status/Jamfile...

> > It "worked" by accident. What did it actually do? Nobody wrote code
> > intending to make that do anything sensible.
>
> The documentation mentions this in a few different places.

In no case does the documentation use this form in the requirements section
of a target description. Requirements are meant to be constraints. What does
it mean to "require" static/dynamic?

> Rene also
> just spent several hours getting this to work correctly. It's
> supposed to build multiple subvariants for both static and dynamic
> linking to the runtime.

Only if you do that in the default-BUILD section or in your BUILD variable.

> > Almost none of the tests make sense in release mode, since
> assertions get
> > compiled away.
>
> Assertions get compiled away, but the Boost.Test library still
> reports errors in release builds. I unit test Boost.Threads in both
> release and debug on a regular basis (and I have encountered errors
> in only one in the past). Again, unit testing and regression testing
> are different, so I'm not sure if this applies here.

You can always "jam -sBUILD=release threads" in the status directory to get
that test.

> > You can always make two separate test targets:
> >
> > test-suite threads
> > : [
> > run libs/thread/test/test_thread.cpp
> > <lib>../libs/thread/build/boost_thread
> > <dll>../libs/thread/build/boost_threadmon
> > : : :
> > <runtime-link>static
> > <threading>multi
> > : threads-static
> > ]
> >
> > [
> > run libs/thread/test/test_thread.cpp
> > <lib>../libs/thread/build/boost_thread
> > <dll>../libs/thread/build/boost_threadmon
> > : : :
> > <runtime-link>dynamic
> > <threading>multi
> > : threads-dynamic
> > ]
> > ;
>
> OK, but for builds the <runtime-link>static/dynamic *IS* currently
> documented as the correct way to do this, and it would be better if
> the two behaved in the same manner here.

We're talking at cross-purposes. Does separating the idea of requirements
from the idea of a build-request clear things up at all?

-Dave