Re: [gentoo-dev] RFC: using Ninja in more CMake-based packages

[Andrew Savchenko]

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