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]>
>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.
> > you put any thought into how this could work? I've tried the following,
> > 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,
>say that it can be built both ways? In that case, you can just leave it
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
> > 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
> > 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
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
link /nologo /DEBUG
libboost_thread.lib(tss.obj) : error LNK2001: unresolved external symbol
: 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:
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
>(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
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.
Chat with friends online, try MSN Messenger: http://messenger.msn.com
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk