John Maddock wrote:
Rene Rivera wrote:
A tangent... I can't change the default to vary depending on the compiler used. I can only change it depending on the platform one *runs* on. Which may be inappropriate in a cross-compile context.
Could you provide some rationale for why those specific variants? Maybe I'm just confused as to why release and debug, and not just debug if you are trying to satisfy the "default" IDE. (note, I'm not an "IDE" person, at least as IDE's are currently defined by the industry)
snipped... BTW, while it is technically possible to use the one of the release runtimes in a debug build with msvc, almost no one does that - the IDE makes it rather tricky to do, and in my experience it often causes hard to track down issues - not least because it confounds the expectations of any other non-Boost libraries that autolink.
Even the above which you cite is prone to problems. Recently I was using the release build of ImageMagick DLLs for VC, which I built from source, against a debug version of a program I created using the same version of VC, and ImageMagick crashed when I had to pass to ImageMagick some dynamically allocated data. When I looked at Dependency Walker naturally I saw two versions of the VC RTLs and I suspect the crash had to do with the fact that the release and debug versions of the RTL do not understand each other's dynamically allocated memory ( the debug version may be sticking in data which allows closer checking of valid dynamically allocated areas ). Once I synched up my versions so that the debug version of my application was using the debug version of the same ImageMagick DLLs, there were no problems. So to back you up further, and whether it is the case with most other compilers I do not necessarily know, but using VC libraries has to be absolutely in synch with each other or else problems will occur and the end-user is asking for trouble. I actually believe that the default build for Boost Build for the end-user, upon downloading Boost and following the basic Boost Build instructions, should be to automatically build all variants of a library for a particular compiler, and only if the end-user wants to limit the variants to build should he have clear documentation which tells him how to build some subset or single variant of a particular Boost library for a particular compiler. Needless to say the instructions for the latter should be clear and easy to understand and find. If the end-user does not want all variants, then he should read the documentation and find out how to limit himself. It is MUCH safer to build all variants by default, even if the build takes significantly longer, than to hear endless questions from end-users to Boost programmers, who have much better things to do than fielding them, about why their library is not linking with the end-user's module, only to find that the end-user never built the correct library for his use because the default was to build a different variant.