From: Doug Gregor (dgregor_at_[hidden])
Date: 2005-03-23 13:30:24
On Mar 23, 2005, at 12:37 PM, Brian Braatz wrote:
> At least when I use signals (and other libraries) I always build
> 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
> 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
> a hard time figuring out WHERE something came from. Occasionally, I
> 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.
> [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).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk