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