[gentoo-dev] [PATCH 1/2] cmake-utils.eclass: Make ninja default backend in EAPI >= 7

[gentoo-dev] [PATCH 1/2] cmake-utils.eclass: Make ninja default backend in EAPI >= 7

[soap]

From: David Seifert <soap@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

[gentoo-dev] [PATCH 2/2] cmake-utils.eclass: Enable BUILD_SHARED_LIBS by default in EAPI >= 7

[soap]

From: David Seifert <soap@gentoo.org>

* Many upstreams build static libraries by default, as this is
  simpler for distribution. Developers can still override this
  variable if required.

  Examples:
  https://github.com/pezmaster31/bamtools/blob/master/CMakeLists.txt#L64
---
 eclass/cmake-utils.eclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
index ed81426ddcc..f180c8c3d7d 100644
--- a/eclass/cmake-utils.eclass
+++ b/eclass/cmake-utils.eclass
@@ -623,6 +623,7 @@ cmake-utils_src_configure() {
 	if [[ ${EAPI} != [56] ]]; then
 		cat >> "${common_config}" <<- _EOF_ || die
 			SET (CMAKE_INSTALL_DOCDIR "${EPREFIX}/usr/share/doc/${PF}" CACHE PATH "")
+			SET (BUILD_SHARED_LIBS ON CACHE BOOLEAN "")
 		_EOF_
 	fi
 
-- 
2.18.0

Re: [gentoo-dev] [PATCH 2/2] cmake-utils.eclass: Enable BUILD_SHARED_LIBS by default in EAPI >= 7

[Andreas Sturmlechner]

---Original Message---
On Thursday, 26 July 2018 at 08:35, soap@gentoo.org wrote:

> From: David Seifert <soap@gentoo.org>
> 
> * Many upstreams build static libraries by default, as this is
>   simpler for distribution. Developers can still override this
>   variable if required.
> 
>   Examples:
>   https://github.com/pezmaster31/bamtools/blob/master/CMakeLists.txt#L64
> ---
>  eclass/cmake-utils.eclass | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
> index ed81426ddcc..f180c8c3d7d 100644
> --- a/eclass/cmake-utils.eclass
> +++ b/eclass/cmake-utils.eclass
> @@ -623,6 +623,7 @@ cmake-utils_src_configure() {
>  	if [[ ${EAPI} != [56] ]]; then
>  		cat >> "${common_config}" <<- _EOF_ || die
>  			SET (CMAKE_INSTALL_DOCDIR "${EPREFIX}/usr/share/doc/${PF}" CACHE PATH "")
> +			SET (BUILD_SHARED_LIBS ON CACHE BOOLEAN "")
>  		_EOF_
>  	fi
>  
> -- 
> 2.18.0

works for me.

Re: [gentoo-dev] [PATCH 1/2] cmake-utils.eclass: Make ninja default backend in EAPI >= 7

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2088 bytes --]

W dniu czw, 26.07.2018 o godzinie 08∶35 +0200, użytkownik
soap@gentoo.org napisał:
> From: David Seifert <soap@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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [gentoo-dev] [PATCH 1/2] cmake-utils.eclass: Make ninja default backend in EAPI >= 7

[Andreas Sturmlechner]

---Original Message---
On Thursday, 26 July 2018 at 08:35, soap@gentoo.org wrote:

> From: David Seifert <soap@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

+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).

Re: [gentoo-dev] [PATCH 1/2] cmake-utils.eclass: Make ninja default backend in EAPI >= 7

[Mike Gilbert]

On Thu, Jul 26, 2018 at 2:35 AM <soap@gentoo.org> wrote:
>
> From: David Seifert <soap@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.

I just want to bring your attention to this bug comment, which would
indicate a regression in the kitware branch of ninja that I was asked
to merge by the Gentoo cmake maintainers.

https://bugs.gentoo.org/663384#c1

If this comment proves to have the right conclusion, I will likely
revert back to the vanilla upstream codebase until the kitware branch
can be fixed.

This may effect your plans to enable ninja by default, since it will
break any fortran package.

Re: [gentoo-dev] [PATCH 1/2] cmake-utils.eclass: Make ninja default backend in EAPI >= 7

[Andreas Sturmlechner]

On Donnerstag, 13. September 2018 16:25:13 CEST Mike Gilbert wrote:
> This may effect your plans to enable ninja by default, since it will
> break any fortran package.

Not much concerned about that; backend default can be overridden by package, 
should its maintainer find out it breaks by EAPI-7 bump.

Re: [gentoo-dev] [PATCH 1/2] cmake-utils.eclass: Make ninja default backend in EAPI >= 7

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 811 bytes --]

On Thu, 2018-09-13 at 20:55 +0200, Andreas Sturmlechner wrote:
> On Donnerstag, 13. September 2018 16:25:13 CEST Mike Gilbert wrote:
> > This may effect your plans to enable ninja by default, since it will
> > break any fortran package.
> 
> Not much concerned about that; backend default can be overridden by package, 
> should its maintainer find out it breaks by EAPI-7 bump.
> 

...and soon enough we end up tracking packages whose default backend
needed to be changed because the maintainer had to workaround bugs
in a particular ninja version.

Am I the only one who misses the times when programmers made working
software and tried to fix bugs rather than releasing whatever satisfies
some internal use case, and ignoring bugs that didn't affect it?

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [gentoo-dev] [PATCH 1/2] cmake-utils.eclass: Make ninja default backend in EAPI >= 7

[Francesco Riosa]

Il 13/09/18 20:55, Andreas Sturmlechner ha scritto:
> On Donnerstag, 13. September 2018 16:25:13 CEST Mike Gilbert wrote:
>> This may effect your plans to enable ninja by default, since it will
>> break any fortran package.
> Not much concerned about that; backend default can be overridden by package, 
> should its maintainer find out it breaks by EAPI-7 bump.
>
>
FYI there was a similar discussion some time ago, since than ninja has
been the default backend for cmake (desktop system 2k packages), in this
time the following packages had (or still have) problems:

# cmake cannot use ninja if it's not installed...
dev-cpp/gtest cmake-make
dev-util/ninja cmake-make

net-analyzer/icinga2 cmake-make
media-gfx/gmic cmake-make

# ninja: error:
'vendor/scrypt/src/scrypt_original-build/libscrypt_sse2.a', needed by
'src/cryfs-cli/cryfs', missing and no known rule to make it
sys-fs/cryfs cmake-make

# Fortran not supported
sci-libs/blas-reference cmake-make
sci-libs/exodusii cmake-make
sci-libs/lapack-reference cmake-make

# error
dev-libs/appstream cmake-make
kde-plasma/kinfocenter cmake-make
app-doc/doxygen cmake-make
net-irc/quassel cmake-make
kde-apps/libksieve cmake-make