Following the upstream LLVM discussion [1], it seems that we ought not to be using custom build type but instead resetting the default flags for standard build types. Right now you could avoid that by setting CMAKE_BUILD_TYPE but it immediately means bringing all the initial problems back. As a first step towards it, it would probably make sense to add default flag reset for the specified CMAKE_BUILD_TYPE. [1]:https://reviews.llvm.org/D26579
IRC update: we are also using CMAKE_BUILD_TYPE to enable some Gentoo-specific behavior in CMake modules. We should probably move to using a dedicated control variable instead, since ebuild authors aren't really expecting CMAKE_BUILD_TYPE to e.g. affect the Python version used. We may also need to look for other uses of CMAKE_BUILD_TYPE. My idea so far: 1. Add a dedicated variable to CMake modules, OR it with CMAKE_BUILD_TYPE, 2. start defining the variable in cmake-utils.eclass, 3. add cleanup for standard CMAKE_BUILD_TYPE values in cmake-utils.eclass. In other words, work towards making standard values of CMAKE_BUILD_TYPE useful in the builds while keeping the old value working reliably and the default. We could look into changing the default in the next EAPI.
Historically, we were setting CMAKE_BUILD_TYPE to None (empty) to achieve the same effect. However, it was insufficient to handle buildsystems that have: if (NOT CMAKE_BUILD_TYPE) set(CMAKE_BUILD_TYPE Debug) or set(CMAKE_CXX_FLAGS "some -Ox") endif () While we already sed-out set(CMAKE_BUILD_TYPE..), the other one we don't touch as we don't know the intention (and we don't parse set(CMAKE_<lang>_FLAGS to get to know it). So it was proposed to simply set CMAKE_BUILD_TYPE explicitly to something unknown and bypass entirely CMAKE_BUILD_TYPE logic. As for defaults flag reset for each build type, should we start sed-ing out all set(CMAKE_<lang>_FLAGS_<build_type> ..) just in case or it's no longer our intention to override whatever people (in ex. LLVM) _append_ to compiler/linker params?
Don't do random seds like that. 1. You can accidentally break something. 2. Most of the time, the appending happens in some deep random subfile it won't affect anyway.
