From: Stefan Slapeta (stefan_at_[hidden])
Date: 2004-02-19 06:18:47
Michael Glassford wrote:
> So it isn't possible to do this by defining the appropriate macros (on
> the command line, in the IDE settings, by using the appropriate
> #defines before you include the Boost.Thread headers, etc.)? I haven't
> tried this or looked into it at all, I'm just asking what you've tried
I don't see this option out of thread/detail/config.hpp (it's not tested
whether the macro is set already). Anyway, just eliminating the macro
would be a much cheaper solution (manually setting the macro for each
project isn't very easy, either).
> As I said, I plan to look into the feasibility of adding back static
> library support, limiting features as necessary. I'm afraid that until
> I look into it I can't commit to it any more than to say that I would
> really like to have static library support for some of my own
> projects, so I'm motivated to make it work if practical.
> A complicating factor is that I believe some new Boost.Thread features
> (currently existing only in the thread_dev branch in cvs so far,
> though I hope to migrate them to the main branch over the next few
> weeks) require tss support, so a static library that disabled tss
> would have to disable those features as well. I plan to look into this
> further soon.
That's a trade-off boost.thread users have to deal with in the future
[and with NEW features]. The most important thing is that no _existing_
code is broken.
> Though I've only built and used the Win32 version of Boost.Thread so
> far, it sounds as if static library support should at least be aded
> back for non-Win32 platforms, which don't have the dynamic library
> requirement. Is that correct?
I'm not sure if I understood correctly what you mean.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk