From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-12-06 15:05:23
"Roland Schwarz" <roland.schwarz_at_[hidden]> wrote in message
> Stefan Slapeta wrote:
>> # if defined(BOOST_MSVC) || defined(BOOST_INTEL_WIN)
>> //For VC++, choose according to threading library
>> # if defined(_DLL)
>> //Threading library is dll: use Boost.Threads dll
>> # define BOOST_THREAD_USE_DLL
>> # define BOOST_THREAD_DECL __declspec(dllimport)
>> # define BOOST_DYN_LINK
>> # else
>> //Threading library is lib: used Boost.Threads lib
>> # define BOOST_THREAD_USE_LIB
>> # define BOOST_THREAD_DECL
>> # endif
>> # else
>> IMO this sequence is wrong (look at the comments!) because the _DLL
>> macro _DOESN'T_ say that a dll is built!!!! It rather says that a
>> shared runtime is used (I don't know if this was the intention
>> behind this sequence, the comment is wrong anyway).
Depends how you read the comment. By "threading library" above I meant
the VC++ threading library, part of the VC++ runtime library. I can
certainly change the comments (as suggested below) to make this
>> The code as is means that every static rt configuration is linked
>> to a static boost.thread lib and every dynamic rt configuration is
>> linked to boost.thread as dll. I just don't know if there is any
>> rationale behind automatically selecting these combinations.
> I think the problem is of how to deduce how the boost libs should be
> linked in when the user does not explicitely
> specifiy e.g. BOOST_USE_LIB.
> A reasonable default in this case would be then to link in the
> library corresponding to the RTL choice.
This was my intention when I wrote the above.
> The code snippet refers to the default choice doesn't it?
Yes, it chooses a default that can be overridden by #defining
BOOST_THREAD_USE_LIB or BOOST_THREAD_USE_DLL
> # else //Use default
> The comment
> //For VC++, choose according to threading library setting
> should better read
> //For VC++, choose according to C-runtime library setting
> of course.
> Does this make sense?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk