Edward Diener wrote:
Stefan Slapeta wrote:
Michael Glassford wrote:
Perhaps I missed something, but did you determine why it isn't being built?
Yes, this was the reason for my original posting. If there are no objections, I'll commit these changes. I'm sure the restrictions below just exist for historical reasons (I can't explain either why e.g. a static boost.thread library shouldn't use a dynamic rt).
Despite the fact that other Boost libs have their static libs use a dynamic RTL there is a reason to do otherwise. Many programmers have historically wanted to build a single executable without any shared libraries for their application. This can be done if the static libs used by that executable all use the static RTL. Once one of those static libs uses the dynamic RTL it is no longer possible to do this, and there is no way, using such a library, to build a single executable that can be distributed without any shared libraries.
I am not sure about what exactly you are talking, so I try to clarify: 1) MyApp using static runtime. a) MyApp using static boost lib --> link in: libboost_thread-*-mt-s??-1_32.lib b) MyApp using dynamic boost lib --> probably not a good idea 2) MyApp using dynamic runtime: a) My App using static boost lib --> link in: libboost_thread-*-mt-??-1_32.lib b) MyApp using dynamic boost lib --> link in: boost_thread-*-mt-??-1_32.lib As you can see 1a) is your requested case. But nothing should prevent a user to choose 2a) if she decides. The original observation was that case 2a) isn't currently available. I don't think you are advocationg for not allowing for case 2a) aren't you? BTW.: Only case 1b) will result in using two instances of the RTL lib which is considered bad.
I do not so much mind that other people disagree with me about having static libs use the static RTL and shared libs ( dlls on Windows ) use the dynamic RTL, but I do mind it when others can not understand the simple argument, whether agreed with or not, I have just specified as a reason for doing so.
Most of the recent effort has been to restore exactly what you want. In 1-31 only case 2b) was available with full features.
Of course if Boost does not feel that they have to cater to those wishing to build a single executable without any shared libraries, that is fine with me. I just want to point out that if the default situation is to have static libs use the static RTL and shared libs use the dynamic RTL, developers can get the best of both worlds; either a single monolithic executable or an executable where all libraries are shared, depending on whether they choose to use static libs or shared libs when building their application.
Now they even have a third option too (2a). The whole issue is not about taking away options but to add missing ones. The only question was what are the defaults: When user chooses 1) --> default is 1a) When user chooses 2) --> default is 2a) (altough I would rather like 2b, but this I have been told is against boost standards) Roland