RE: [boost] Why do we build debug variants of our compiled libraries?
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Doug Gregor Sent: Wednesday, March 23, 2005 8:23 AM To: Boost mailing list Subject: [boost] Why do we build debug variants of our compiled
Some thoughts below 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?
[Brian Braatz Writes:] At least when I use signals (and other libraries) I always build against the debug for development. While I may not be debugging signals specifically, I may be wanting to see: 1- Signal calls on the call stack in my IDE 2- How my code is using signals - i.e. the focus is on MY code, but being able to step in and out of the signals stuff *=(or any boost lib for that matter) helps me see how my code is working WITH it 3- You may recall I am the same guy who occasionally begs\whines\offers to wash your car FOR: some kind of metadata in signals, I the reason is when you use this lib extensively, you may have a hard time figuring out WHERE something came from. Occasionally, I step into signals and look at the internal data to figure out where the slot came from
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
[Brian Braatz Writes:] Are you just talking about when you do a bjam build of boost (or specific lib)? I use the debug from this mode, but would be happy to change my script to pass in an extra param. The NICE thing about the "build everything" model is it is a catch all for peoples usage.
On Mar 23, 2005, at 12:37 PM, Brian Braatz wrote:
At least when I use signals (and other libraries) I always build against the debug for development. While I may not be debugging signals specifically, I may be wanting to see: 1- Signal calls on the call stack in my IDE 2- How my code is using signals - i.e. the focus is on MY code, but being able to step in and out of the signals stuff *=(or any boost lib for that matter) helps me see how my code is working WITH it
Interesting... I typically wish that library calls did not show up, but I use libraries very different from signals in my day-to-day programming.
3- You may recall I am the same guy who occasionally begs\whines\offers to wash your car FOR: some kind of metadata in signals, I the reason is when you use this lib extensively, you may have a hard time figuring out WHERE something came from. Occasionally, I step into signals and look at the internal data to figure out where the slot came from
I remember :)
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
[Brian Braatz Writes:] Are you just talking about when you do a bjam build of boost (or specific lib)? I use the debug from this mode, but would be happy to change my script to pass in an extra param.
Just the defaults. When the user types "bjam" I don't see why they should get debug versions (except with MSVC; thanks John!). If they want debug versions, they can of course use -sBUILD=debug to get them.
The NICE thing about the "build everything" model is it is a catch all for peoples usage.
The down side is that it takes _forever_ to build Boost, when most people don't need 3/4 of what is built (e.g., they'll use release-mode dynamic Xor static libs, but not both). Doug
Doug Gregor wrote:
Just the defaults. When the user types "bjam" I don't see why they should get debug versions (except with MSVC; thanks John!). If they want debug versions, they can of course use -sBUILD=debug to get them.
Runtime linkage and debugging information are two different things and may be set sepeartely (I'm pretty sure John knows this - but some other readers may not. "Debug version" is ambiguous for Windows).
participants (3)
-
Brian Braatz -
Doug Gregor -
Tobias Schwinger