[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] RFC: using Ninja in more CMake-based packages
From:       Andrew Savchenko <bircoph () gentoo ! org>
Date:       2015-06-21 6:55:38
Message-ID: 20150621095538.a45f0ea9414b8ed3e353175a () gentoo ! org
[Download RAW message or body]


Hi!

On Sun, 7 Jun 2015 17:08:57 +0200 Michał Górny wrote:
> Hello, developers.
> 
> As you probably know already, CMake sucks a lot. One of its more sucky
> features is that it generates Makefiles that fail a lot. In particular,
> they fail at verbose build logs that are cluttered with useless CMake
> intermediate commands and hard to read. But also they sometimes
> deadloop hard in faulty dependency scanning [1].
> 
> Those two issues can be solved by switching CMake to use Ninja instead
> of make. As you may know, Ninja is the fancy building tool that is
> faster and much harder to use than make. However, it integrates with
> CMake much better and with less hackery. In particular, the verbose
> build log is free of useless CMake percentage printing output and other
> non-sense, and contains only real build commands. It also gets
> dependency scanning right.
> 
> Sadly, there are two problems with using Ninja:
> 
> 1) it will not work with some packages,
> 
> 2) it introduces an extra dep (on Ninja).
> 
> The first issue is a bit complex. Sometimes the problem lies in CMake
> itself (not all CMake magic works in Ninja for some reason), sometimes
> in the project (relying on Makefile stuff), sometimes in the ebuild.
> For example, with Ninja you can't do '-C subdirectory' to run targets
> from a specific subdirectory. So, we can't force Ninja everywhere.
> 
> The second issue is a bit easier. GNU make is part of @system, ninja
> would be considered an extra package being installed. Do we consider it
> fine to require it randomly? Or do we need to justify the extra dep by
> benefits of building a particular package with Ninja? Is sane verbose
> build log a good enough benefit?
> 
> So, what do you think? Should I start switching random packages to
> Ninja whenever it works?
> 
> Oh, and this would be done via something like:
> 
>   : ${CMAKE_MAKEFILE_GENERATOR:=Ninja}
> 
> before inherit line. To respect user forcing another generator, and to
> get deps right.

Sounds great. IMO default value should be determined per-package:
if upstream recommends Ninja (or there is a good testing with
Ninja), then set it, otherwise emake.

Any progress here? The only package in tree which allows user to
select cmake backend is llvm-9999.

Best regards,
Andrew Savchenko

[Attachment #3 (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]