Why do we build debug variants of our compiled libraries?
Looking at the Jamfiles for Signals, Python, and the other libraries in Boost that have compiled parts that users link against, I'm wondering why we create so many variants by default. Why would a user want to link against the debug version of Signals, for instance? The only reason I imagine would be to debug Signals, but I should hope that the average user does not need to debug that code. If I dig around /usr/lib and /usr/local/lib on my Mac, I only find optimized libraries: nobody else seems to bother building debug variants, so why should we? Anyway, my recommendation is that we stop building debug variants of compiled libraries by default. It's easy for the user to build them if they are really required. Doug
Anyway, my recommendation is that we stop building debug variants of compiled libraries by default. It's easy for the user to build them if they are really required.
There is one exception: if you're using VC++ or some other compiler that ships with multiple runtimes, then you *must* link against a Boost lib that's built against the same runtime as your application is using (probably a debug runtime during development). Of course on Linux (and probably most Unix variants) this is a non-issue. John.
Doug Gregor wrote:
Looking at the Jamfiles for Signals, Python, and the other libraries in Boost that have compiled parts that users link against, I'm wondering why we create so many variants by default. Why would a user want to link against the debug version of Signals, for instance? The only reason I imagine would be to debug Signals, but I should hope that the average user does not need to debug that code.
If I dig around /usr/lib and /usr/local/lib on my Mac, I only find optimized libraries: nobody else seems to bother building debug variants, so why should we?
Anyway, my recommendation is that we stop building debug variants of compiled libraries by default. It's easy for the user to build them if they are really required.
As others have said, its no problem not building debug versions of libraries by default as long as there is some documented way to accomplish it for end-users of Boost who want to have debug builds. When I use any compiler, I like to sync up debug versions of modules with the other debug versions of modules, if they are present, and even a debug version of the RTL. I do not think VC is the only Windows compiler which gives headaches if this is not done since I recall having equal headaches with Borland also in the past although I no longer remember why this happened and what the circumstances were. Also as complicated as some of the Boost code is it is still good to be able to step into it if necessary. I know when I have worked on my Regular Expression Component Library, built on top of John Maddock's regex++, I was thankful I could step into the code, particularly as I made my own enhancements to some of it. Because of this it is important that Boost users be able to build debug versions of Boost implementations that have libraries, but I do not regard it as important that the default Boost build process build those debug versions. But please document how debug versions can be built as bjam is still terra incognita for many lazy ( ie. those who do not have the energy to study bjam ) programmers like me.
participants (3)
-
Doug Gregor -
Edward Diener -
John Maddock