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 already.
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.
Great!
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. Stefan