---Original Message--- On Thursday, 26 July 2018 at 08:35, [email protected] wrote:
> From: David Seifert <[email protected]> > > * 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 +1 fwiw, I've been testing this in an overlay branch and it seems to work fine so far (no ninja related errors on those packages I rebuilt).
