I should mention that the top-level Makefile is kept, as is the one to drive the tests. I'm going to look at moving the latter to CMake using CTest.

Thanks @jszakmeister but ultimately the top-level Makefile probably will become a little redundant. At the moment it's essentially a convenience to download and compile libuv and then run cmake. The direction #116 indicates is one where people use whatever they'd normally use with CMake, be that make or ninja. For the time being I'd rather leave the Makefile small, dumb and bare-minimum features.

In summary: I'd rather go in the direction of supporting CMake first and hence Make (or ninja) accidentally rather than hard-coding in a particular build tool.

That being said, if this is controversial or another dev team member wants to re-open, I don't mind revisiting the issue.

No worries. This really didn't add much (just the ability to use Ninja instead of make to conduct the actual build), but that's fine. It's not hard to drive it directly myself. But, I don't see how #116 points in a direction. ISTM that it's still expecting people to drive the top-level with make, and is still baking in that the build will be conducted using make. Perhaps you meant to point at something else? BTW, there is a file(DOWNLOAD ...) capability in CMake that could be used instead of a custom script to fetch the libuv tarball--if you aren't building against the system version.

Perhaps you meant to point at something else?

That PR makes it possible to build neovim without using the top-level Makefile. That's the first step in the direction of removing (or making non-default) said Makefile :). After #116 one does:

$ mkdir build && cd build

and then are free to use cmake -G Ninja .. or cmake -G 'Unix Makefiles' .. as you wish. (Assuming you've already installed libuv somewhere.) This makes the top-level Makefile a convenience but not required. C.f. the homebrew package for neovim which does not use the top-level Makefile and so could just as easily use ninja should they want to.

BTW, there is a file(DOWNLOAD ...) capability in CMake that could be used instead of a custom script to fetch the libuv tarball--if you aren't building against the system version.

That's interesting but the bundled libuv is no longer downloaded separately.

It's worth noting that using ninja does indeed make the build very fast. (About 4 seconds of wall clock.)

rjw57@spica:~/git/neovim/neovim (master)
$ mkdir build; cd build
rjw57@spica:~/git/neovim/neovim/build (master)
$ cmake -G Ninja .. -DCMAKE_PREFIX_PATH=$PWD/../../libuv/dist/                                                                                                                               
-- The C compiler identification is GNU 4.8.1
... [ >8 ] ...
-- Build files have been written to: /home/rjw57/git/neovim/neovim/build
rjw57@spica:~/git/neovim/neovim/build (master)
$ time ninja 
[51/51] Linking C executable bin/nvim

real    0m4.014s
user    0m13.150s
sys     0m1.090s
rjw57@spica:~/git/neovim/neovim/build (master)
$ 

C.f. the homebrew package for neovim which does not use the top-level Makefile and so could just as easily use ninja should they want to.

That was a braino. I meant the AUR package(!)

I see what you're saying. I thought you meant there was some clear direction that was being outlined that would eventually result in the Makefile being dropped. That's the part I don't see. :-) But no worries, there are bigger fish to fry. :-)

And yes, Ninja is pretty awesome. We've been using it on several projects--in conjunction with CMake--and it's been wonderful.