From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 8FFC1138334 for ; Thu, 13 Sep 2018 09:55:14 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 45EDCE0ADA; Thu, 13 Sep 2018 09:55:10 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id E7D6CE0AD1 for ; Thu, 13 Sep 2018 09:55:09 +0000 (UTC) Received: from tux200s.localnet (unknown [80.122.182.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: asturm) by smtp.gentoo.org (Postfix) with ESMTPSA id AAD93335D03 for ; Thu, 13 Sep 2018 09:55:06 +0000 (UTC) From: Andreas Sturmlechner To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [PATCH 1/2] cmake-utils.eclass: Make ninja default backend in EAPI >= 7 Date: Thu, 13 Sep 2018 11:55:01 +0200 Message-ID: <4070615.ndDgQoSst6@tux200s> Organization: Gentoo In-Reply-To: <20180726063501.18702-1-soap@gentoo.org> References: <20180726063501.18702-1-soap@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Archives-Salt: 10fb2220-85ee-4f26-886c-35e408da992b X-Archives-Hash: 55ab670458b15090eef108d5e8b294f5 ---Original Message--- On Thursday, 26 July 2018 at 08:35, soap@gentoo.org wrote: > From: David Seifert > > * 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).