2012/10/31 Norbert Thiebaud <nthiebaud@gmail.com>:
On Wed, Oct 31, 2012 at 10:35 AM, Lubos Lunak <l.lunak@suse.cz> wrote:On Wednesday 31 of October 2012, Norbert Thiebaud wrote:On Wed, Oct 31, 2012 at 8:34 AM, Lubos Lunak <l.lunak@suse.cz> wrote:I'd prefer to not bring it back because of a special use case that's already easily doable as it is.Well tinderbox works nicely and easily with an autogen.lastrun associated with a given profile... messing with env variable is not as neat and is just a pain when managing many of these profile... what is the harm of --enable-symbol ?./configure --enable-symbol ./configure CXXFLAGS='-Os -g' Where's the difference in that?note: I think the one that should go is dbgutil... --enable-symbol => release build but with symbols --enable-debug => debug build (with symbol of course) extra feature (dbg-util) => --enable-debug + runtime trigger to activate the 'special' stuffHow exactly do you envision a runtime trigger that activates binary incompatibility? Because that's exactly what makes dbgutil different from debug.then make dbgutil feature not binary incompatible... I'm not c++ expert, but surely there is ways to provide these extra feature without touching the interface. iow having a impl_debug pointer that can be used if not null to do extra stuff... very low cost for release and flexible for debug.. without the binary incompatibility
enable-dbgutil uses the stl debug libraries which are binary incompatibel with the normal stl libraries. I still don't see how the three different switches are confusing: enable-symbol: only add debugging symbols but still with optimization enable-debug: additionally no optimization to make it easier to debug enable-dbgutil: switch to stl debug library + some more stuff (binary incompatible) Maybe I'm missing something but they seem to be separated clearly and each has its own purpose. I think with the argument that you can specify the parameters in the CXXFLAGS we can also remove enable-debug and most likely many more. Regards, Markus