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?
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
