Support for alternative build tools (node-cmake)

[danpat]

In an effort to ditch the python dependency of node-gyp, we've been experimenting with node-cmake, which is a thin wrapper around cmake.

It's use is quite straightforward if you're already using CMake. We just added this:

https://github.com/mapbox/route-annotator/blob/b07d7751988419482b84e536ec84205543466c88/CMakeLists.txt#L44-L62

and we can build our .node binary with:

./node_modules/.bin/ncmake --build

After this is run, all the usual node-pre-gyp package, node-pre-gyp publish commands work as expected.

With a little bit of hackery, I added support for ncmake to node-pre-gyp build by providing an alternative to lib/util/compile.js that calls the appropriate ncmake commands instead of their node-gyp equivalents.

Would it make sense to support alternative build tools like this in node-pre-gyp on a larger scale? The publishing logic is well established and independent of the build tool.

An alternative might be to fork node-pre-gyp into node-pre-cmake.

[daniel-j-h]

For the record, when adding this I had to update the CMake min. version to 3.1 as node-cmake uses some advanced features. This may be a problem for users e.g. on Ubuntu <= Trusty (which is somewhat bad since Trusty is LTS).

[0181532686cf4a31163be0bf3e6bb6732bf]

+1 here. Maybe it's simpler just to define somewhere commands which can be overridden, but call node-gyp by default? So that it will be a matter of changing some vars to from node-gyp build to cmake && make instead

[0181532686cf4a31163be0bf3e6bb6732bf]

I think I've found a workaround: https://gyp.gsrc.io/docs/LanguageSpecification.md#Actions

[TheMarex]

Current work-a-round we use in node-osrm for this is adding the following to the package.json:

{
  "scripts": {
    "preinstall": "npm install node-pre-gyp",
    "install": "node-pre-gyp install --fallback-to-build=false || make"
  }
}

That way we defer to the makefile in case we need to actually compile code and run our own cmake based toolchain.

[markandrus]

@danpat would you consider sharing your changes to lib/util/compile.js? I am also preferring node-cmake these days (in part, due to CLion's nice CMake support).