Trying to build kdevelop with a few compiler options of my choosing (-O3 -g, basically), I discovered that the build system won't allow this. Whatever I try, I always find additional flags (-O2, sometimes -O0 and/or -fno-inline) later on the final compiler command lines that undo at least some of my own flags. Reproducible: Always Steps to Reproduce: What I tried: -DCMAKE_CXX_FLAGS_RELEASE or -DCMAKE_CXX_FLAGS_RELWITHDEBINFO on the cmake commandline; those flags in an initial script loaded with -C; ditto *_INIT flags; changing the flags in CMakeCache.txt . Actual Results: additional flags (-O2, sometimes -O0 and/or -fno-inline) later on the final compiler command lines that undo at least some of my own flags. Expected Results: a compiler command line that reflects my settings in that they're appended to the default list. Setting the required/default options at the beginning of the list makes no difference if the user does not specify his/her own flags, and won't override them. CMake is uninviting enough for non-savvy users to start experimenting with options incompatible with KDE and filing bug reports afterwards, I think ... I understand that cmake is supposed to use CMAKE_CXX_FLAGS when CMAKE_BUILD_TYPE=None (or unspecified), and while that seems to be true, something still adds -O2 -g (etc; the standard RelWithDebInfo flags) to the end of the compiler flags list. Kevin Funk suggested that this is due to settings in FindKDE4Internal.cmake, but I'm not perfectly sure about that. A changed order of the flags in that file does not show up in my generated .make files, and also FindKDE4Internal.cmake has -O2 for Release instead of the -O3 that I get in CMakeCache.txt . I know that KDE4 is in maintenance mode, but this seems to be something that could benefit a lot of people who are "stuck" on KDE4 (and possibly on older hardware on which optimal optimisation is more crucial than on the latest and greatest hardware). IMHO the KF5 build system would also benefit from rethinking the way standard compiler arguments are set in the various cmake files. I'm perfectly willing to look into this, but would require some pointers to get me started.
No feedback on this, not even a "works as intended"?
Well the problem's that buildsystem bugs are automatically assigned to Alex, who's hasn't had much free time lately -- I guess you'd be able to get more feedback in kde-core-devel@ or the kde-buildsystem@. This is basically the same as bug 338151.
Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone!
I have to conclude this is an intentional cmake "feature" (or bug, depending on how you look at things). There's a workaround, used by Debian in its deb build system (and now also by MacPorts): use a custom (NOT pre-defined) CMAKE_BUILD_TYPE. Doing that will let cmake use CFLAGS, CXXFLAGS etc. without prepending or appending anything to them. I'll file new tickets if ever I discover that the ECM append options that should users should be able to override for their builds.