TODO/DOWANT: 1) Use current working directory instead of ${S} when initializing ${CMAKE_USE_DIR} and ${BUILD_DIR} bug 704524 2) Switch CMAKE_BUILD_TYPE to RelWithDebInfo by default (?) > <asturm> so far we have "Gentoo" in order to not have our make.conf settings > overridden > <soap> (you can do that with RelWithDebInfo too and redefine the default > to our make.conf defaults) > ... > <mgorny> asturm: yes, plz move away from Gentoo build type > <mgorny> that hack is bad 3) Enforce array usage for CMAKE_REMOVE_MODULES_LIST > <asturm> soap: how to do the enforcing of the arraying? > <soap> if [[ $(declare -p CMAKE_REMOVE_MODULES_LIST) != "declare -a"* ]]; then > <soap> but ulm said that is brittle in newer bash or something 4) cmake-multilib.eclass might install 32-bit binaries instead of 64-bit bug 735820
*** Bug 803416 has been marked as a duplicate of this bug. ***
About 2), I think we should not set a build type at all if possible, because build type flags always come after CMAKE_CXX_FLAGS, which then override make.conf settings. Moreover, setting a build type can also have funny behavior with multi-config generators (possible with ninja on Linux too now). Packages that need a build type to be set in order to work can be handled by setting the build type to a default value inside the ebuild, so I think this is not necessary at eclass level. I also agree with mgorny about not using a "Gentoo" build type, because many packages have logic that can only cope with build types coming from the default types from CMake and maybe some custom ones by the package itself.
Testing in kde overlay.
