Ilan really loves NetBeans, and he really wants to be able to debug Rosegarden in an IDE, setting breakpoints, watching variables and so on. Things I barely remember doing myself, to be honest, but things I remember as being convenient and useful.
So the NetBeans team had a look at his issue, and their guy looked at one of our g++ lines and said WTF. They suspect the "NetBeans points at the wrong line" problem is related to problems in general trying to debug optimized binaries. They suggest that it is standard practice to use non-optimized binaries for debugging purposes. I've never paid much attention to any of this sort of thing myself. If Rosegarden compiles and runs, I don't worry about what compiler options got me there. I'm not even sure how to tell if I have an optimized binary or not. What is the precedence of options in g++? Does the first -O2 take precedence over the last -O1? Is this behavior even defined? And for that matter, shouldn't this be -O0 to avoid optimizing for debugging purposes? If I ./configure --enable-debug in a shell with no $CXXFLAGS environment variable defined, I get the CXXFLAGS in the generated Makefile starting out with this: CXXFLAGS := -g -O2 -DDEBUG -DBUILD_DEBUG -DWANT_TIMING -Wall - Woverloaded-virtual -Wextra -Wformat-nonliteral -Wformat-security -Winit-self -Wswitch-enum -O1 -g -pipe \ The string "-g -O2" seems to be the default substitution for CXXFLAGS in configure.ac if there is no environment variable. If I change the environment variable, I change the part of the line quoted above that comes before - DDEBUG. This happens in configure.ac where: CXXFLAGS="$CXXFLAGS $BUILDFLAGS" Leading up to that line, $BUILDFLAGS is either $RELEASEFLAGS or $DEBUGFLAGS, each of which looks sensible enough on its own, and the switching logic appears to work, with $DEBUGFLAGS being used when --enable-debug and $RELEASEFLAGS being used otherwise. So it is the "$CXXFLAGS" in "$CXXFLAGS $BUILDFLAGS" potentially throwing a spanner in the works here. If we just remove that and have: CXXFLAGS="$BUILDFLAGS" Then the Makefile generates with either: (release build) CXXFLAGS := -DNDEBUG -DBUILD_RELEASE -DNO_TIMING -g0 -O2 -Wall -pipe \ (debug build) CXXFLAGS := -DDEBUG -DBUILD_DEBUG -DWANT_TIMING -Wall -Woverloaded- virtual -Wextra -Wformat-nonliteral -Wformat-security -Winit-self -Wswitch- enum -O1 -g - This seems cleaner, but removes the option to specify individual preferences in the CXXFLAGS environment variable. In truth, I'm not sure how much of an issue that is. I happen to have a CXXFLAGS environment variable in the environment I normally have in place while doing development work, but I don't remember why it's there, and have no idea if changing the options at the head end of this string actually accomplishes anything anyway. Thinking in general, it's probably a good idea if we all use the same options for release or debug builds, so unless there's some pressing reason this needs to be configurable through an environment variable (strong inescapable tradition, necessary to build on Orange Rabbit Linux or BSD or something, etc.) I wouldn't miss it if we removed that. Then it seems it might be reasonable to use -O0 instead of -O1, unless maybe we use -O1 because that level of optimization is some established compromise that is not supposed to affect debugging. I really don't know anything about any of these issues, and have no real opinions. I'm just passing this all along for consideration and scrutiny. Maybe our build system is broken, and maybe none of these eyebrow raising things actually cause problems. I just don't know. -- D. Michael McIntyre ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Rosegarden-devel mailing list [email protected] - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
