From: David Seifert <s...@gentoo.org> * Using the ninja backend as a default is the only way to massively improve src_compile core utilization, given that it seems unlikely that CMake will ever produce non-recursive Makefiles.
For a benchmark, see: http://www.kaizou.org/2016/09/build-benchmark-large-c-project/ --- eclass/cmake-utils.eclass | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass index e64502b3b9b..ed81426ddcc 100644 --- a/eclass/cmake-utils.eclass +++ b/eclass/cmake-utils.eclass @@ -53,7 +53,8 @@ _CMAKE_UTILS_ECLASS=1 # @DESCRIPTION: # Specify a makefile generator to be used by cmake. # At this point only "emake" and "ninja" are supported. -: ${CMAKE_MAKEFILE_GENERATOR:=emake} +# In EAPI 7 and above, the default is set to "ninja", +# whereas in EAPIs below 7, it is set to "emake". # @ECLASS-VARIABLE: CMAKE_MIN_VERSION # @DESCRIPTION: @@ -112,8 +113,13 @@ esac inherit toolchain-funcs ninja-utils flag-o-matic multiprocessing xdg-utils case ${EAPI} in - 7) ;; - *) inherit eapi7-ver eutils multilib ;; + [56]) + : ${CMAKE_MAKEFILE_GENERATOR:=emake} + inherit eapi7-ver eutils multilib + ;; + *) + : ${CMAKE_MAKEFILE_GENERATOR:=ninja} + ;; esac EXPORT_FUNCTIONS src_prepare src_configure src_compile src_test src_install -- 2.18.0
