[debhelper-devel] Bug#895044: debhelper: add support for Ninja with CMake

[Kyle Edwards]

On 04/06/2018 10:18 AM, Niels Thykier wrote:
> On Fri, 06 Apr 2018 10:08:24 -0400 Kyle Edwards
> <kyle.edwards at 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?
>
> Thanks,
> ~Niels

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.

Kyle