marble hard-coding -O3 optimizations

Rex Dieter rdieter at math.unl.edu
Mon Feb 6 14:15:54 UTC 2012


Torsten Rahn wrote:

> However for Marble it's a different case: It can reduce the framerate
> hugely if you compile with Debug mode - last time I checked it was about
> half the speed or less. I don't want to hear people complaining about
> speed just because they use packages that are possibly compiled with Debug
> flags or because they compile it themselves with the Debug flag and are
> unaware of the impact.
> 
> That's why this solution is in place. So far it has worked well for us.
> And I wouldn't like to "fix" it unless there is a real problem. :-)

It's a problem because -O3 overrides what is specified by the 
builder/packager too.  No other core kde app does this, that I'm aware of.

I don't know about other packagers or distros, but mine has some relatively 
strict guidelines and policies I need to follow wrt complilation flags... 
and I'd rather not to have to patch this for eternity. 

For what it's worth, I just discovered this in FindKDE4Internal.cmake:

   set(CMAKE_CXX_FLAGS_RELWITHDEBINFO "-O2 -g -DNDEBUG -DQT_NO_DEBUG")
   set(CMAKE_CXX_FLAGS_RELEASE        "-O2 -DNDEBUG -DQT_NO_DEBUG")
   set(CMAKE_CXX_FLAGS_DEBUG          "-g -O2 -fno-reorder-blocks -fno-
schedule-insns -fno-inline")
   set(CMAKE_CXX_FLAGS_DEBUGFULL      "-g3 -fno-inline")

So, looks like the only case where optimization does not occur by default is 
in the DEBUGFULL case.  If you still insist on optimizing in that case, I'd 
recommend doing something like
   set(CMAKE_CXX_FLAGS_DEBUGFULL      "${CMAKE_CXX_FLAGS_DEBUGFULL} -O3")
instead.  If this is agreeable, I'd be happy to help prepare a patch to 
implement this for your review.

-- rex



More information about the kde-edu mailing list