On 04/06/2018 10:18 AM, Niels Thykier wrote:
On Fri, 06 Apr 2018 10:08:24 -0400 Kyle Edwards
<kyle.edwa...@kitware.com> wrote:
Package: debhelper
Version: 11.1.6
Severity: wishlist

Dear Maintainer,

Large projects which use CMake, such as VTK, take a long time to build
with the Makefile generator, and see significant build time improvements
when being built with the Ninja generator instead. Please consider
adding support for using the Ninja generator with CMake. Perhaps
something like:

$ dh --buildsystem=cmakeninja

I realize this may be tricky given how the buildsystems are implemented
in debhelper. I don't know much about Perl, but if it supports multiple
inheritance, would it be possible to make a class like "cmakebase" and
then have "cmake" and "cmakeninja" inherit from both "cmakebase" and
then "makefile" and "ninja" respectively?


Hi Kyle,

Thanks for the suggestion.

How will debhelper know whether cmake will generate a ninja.build and
not a Makefile?  Is that something debhelper decides 100% (via the -G)
parameter?  Or does the project specify a default in CMakeLists.txt and
debhelper should respect that or ...?

If debhelper decides it: How likely is it that a random CMake project
today will work with ninja instead of make?


CMake developer here (I work at Kitware). The intention of CMake is to generate whatever buildsystem the developer feels most productive with, rather than what the project wants. By default, CMake generates Makefiles on Unix unless you give it a -G parameter. There's not a supported way to set the generator from within CMakeLists.txt, so yes, debhelper would be making that decision with -G. But even in a hypothetical scenario where a project is setting the generator from inside CMakeLists.txt (perhaps through some sort of unsupported hack), current debhelper wouldn't be able to handle that, because it's expecting a Makefile. If we added "cmakeninja", these hypothetical projects which are setting the generator to Ninja could be packaged with cmakeninja.

Ninja has been supported by CMake for a while, and most projects tend to handle it pretty well. That said, some projects are known to not work with Ninja. For those, they can continue to use the classic "cmake" buildsystem, which would still generate makefiles, and then projects that work with Ninja could use "cmakeninja" if they so desire. This change wouldn't impact existing projects unless they explicitly use "cmakeninja", because the "cmakeninja" check would come after the "cmake" check, which would succeed upon finding CMakeLists.txt.


Reply via email to