Fwd: Re: Boost.Threads and Regression Testing

From: William Kempf (williamkempf_at_[hidden])
Date: 2002-02-27 11:28:13

I've been trying to add Boost.Threads to the regression testing system in 
$(BOOST_ROOT)/status, and it's brought up some issues with the build system. 
I've been conversing with David on this one, but he suggested we move the 
discussion to here, so...

>From: "David Abrahams" <david.abrahams_at_[hidden]>
>Reply-To: "David Abrahams" <david.abrahams_at_[hidden]>
>To: "William Kempf" <williamkempf_at_[hidden]>
>Subject: Re: Boost.Threads and Regression Testing
>Date: Tue, 26 Feb 2002 21:19:25 -0500
>
>
>----- Original Message -----
>From: "William Kempf" <williamkempf_at_[hidden]>
>To: <david.abrahams_at_[hidden]>
>Sent: Tuesday, February 26, 2002 1:25 PM
>Subject: Boost.Threads and Regression Testing
>
>
> > I'd really like to include Boost.Threads in the regression testing. 
>Have
> > you put any thought into how this could work? I've tried the following,
>but
> > receive an error.
> >
> > run libs/thread/test/test_thread.cpp <lib>libs/thread/build/boost_thread
> > <dll>libs/thread/build/boost_threadmon
> > : #args
> > : #input-files
> > : #requirements
> > <include>$(BOOST_ROOT)
> ^^^^^^^^^^^^^^^^^^^^^^
>Shouldn't need this part, it's added automatically

This is nice to know. Is it true only for the status/Jamfile or is this now 
a feature in all Jamfiles in Boost?

> > <runtime-link>static/dynamic
> ^^^^^^^^^^^^^^
>Can't use this form in requirements specification. What's your intention, 
>to
>say that it can be built both ways? In that case, you can just leave it 
>out.

Then which variant does it choose to use?

> > <threading>multi
> > ;
> >
> > The error is:
> >
> > No compatible subvariant found for:
> > <status!C:!home!boost!libs!thread!build>libb
> > oost_thread.lib
>
>I'm pretty sure that's because it's trying to find a subvariant whose
><runtime-link> setting is static/dynamic. That shouldn't work ;-)

But it does in the actual Jamfiles for the projects. Why should it not work 
here?

> > I assume it can't figure out whether to use debug or release?
>
>No, debug is the default BUILD setting.

It might be important to regression test stuff with both BUILD settings. 
For example, the VC++ compiler does some special "magic things" in debug 
builds, such as initialize all pointers to special values. Occasionally 
this can result in bugs that occur in release builds that don't occur in 
debug builds. Of course, this is a regression test and not a unit test, so 
maybe you should just ignore what I said... ;).

> > I'm not sure
> > how to specify this so it will work. Boost.Threads appears to be the
>first
> > test that requires linking to a library in order to test.
>
>I tried this, and found a bug in the status/Jamfile which I fixed. I also
>added your tests. It doesn't link, but I'm sure you can figure that one 
>out.

Actually, no, that's proving a bit vexing and I *think* it's still a build 
system problem. When I run using jam -d+2 to see what's going on I see the 
error as:

link /nologo /DEBUG 
/PDB:"..\status\bin\test_thread.test\msvc\debug\runtime-link-dynamic\threading-multi\test_thread.pdb" 

/out:"..\status\bin\test_thread.test\msvc\debug\runtime-link-dynamic\threading-multi\test_thread.exe" 
/LIBPATH:C:\PROGRA~1\MICROS~4\VC98\lib 
@"..\status\bin\test_thread.test\msvc\debug\runtime-link-dynamic\threading-multi\test_thread.CMD"

libboost_thread.lib(tss.obj) : error LNK2001: unresolved external symbol 
__imp__on_thread_exit
..\status\bin\test_thread.test\msvc\debug\runtime-link-dynamic\threading-multi\test_thread.exe 
: fatal error LNK1120: 1 unresolved externals

on_thread_exit() is a method from the boost_threadmon.dll so it appears that 
the build system isn't linking against the DLL's import library. Sure 
enough, looking at the contents of test_thread.CMD shows the following:

"..\status\bin\test_thread.test\msvc\debug\runtime-link-dynamic\threading-multi\test_thread.obj"
"..\libs\thread\build\bin\libboost_thread.lib\msvc\debug\runtime-link-dynamic\threading-multi\libboost_thread.lib"

Despite the <dll> specification the boost_threadmon.dll's import library 
isn't being linked. Curiously, there is output indicating that the DLL was 
built because of the <dll> specification, however.

>I killed the bogus <runtime-link>static/dynamic in your requirements 
>section
>(perhaps you'd like that in the default-BUILD, but we don't have a
>default-BUILD section for test targets in status/Jamfile. Maybe we should
>fix this).

I think it's important to regression test every variant of the library. 
Debug/release variants are a little debatable, but other variants can mean 
very drastic differences in test results. Which runtime we use is something 
that may, indeed, change the behavior of tests.

Bill Kempf

_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com