W dniu czw, 26.07.2018 o godzinie 08∶35 +0200, użytkownik s...@gentoo.org napisał: > 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/
For the record, 'core utilization' or speed in general is a poor
argument. You shouldn't have brought it because it will bring
completely unnecessary bikeshed to this thread. Gentoo developers will
argue about it not because it could benefit Gentoo in any way
but because someone is wrong on the Internet!
The primary reason for using Ninja is making verbose build output
readable, in particular getting a lot of pointless nested verbose echos
out of it.
> ---
> 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
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
