cjntaylor / node-cmake

CMake-based build system for node.js native modules
ISC License
78 stars 20 forks source link

Install Targets #28

Closed computerquip-streamlabs closed 6 years ago

computerquip-streamlabs commented 7 years ago

There doesn't appear to be anyway to invoke install commands from ncmake. You can invoke them by using cmake --build build --target install but there should preferably be a way to invoke them through ncmake.

cjntaylor commented 7 years ago

I'll add this to the next minor revision. It'll be exposed through the ncmake command install, to match the old node-gyp conventions.

That said, I'm not sure why you'd want this. Modules are typically built in place and referenced via relative paths; the module finding code node-cmake provides assumes that the binary will be in a specific set of locations (namely, in the module's folder, with the subpath build/{Debug,Release}/<name>.node). This isn't my convention; this is what node-gyp/require assumes.

You'll definitely need to add commands to your CMakeLists.txt to define what it means to install the module; the NodeJS.cmake definitions don't provide this as there isn't any standard for what it should be. If you could elaborate on your use case, I could consider that to add some reasonable install defaults to the NodeJS.cmake definitions, so you wouldn't have to define them every time.

cjntaylor commented 6 years ago

Added in 2.4.0. Sorry for the delay.

I'm still not sure why you'd want this, but it literally does what you're suggesting above cmake --build <output> --target install. By default, this will do nothing (in fact, it'll error as no install target is defined).

computerquip-streamlabs commented 6 years ago

Install commands in cmake have more than one use. It can also be used to consolidate dependencies into one directory after the build has finished, be it for tests or for setting up a working directory for the finished binary. It can be used for moving resources into a particular layout for that working directory.

Also, there's no reason to stick to the the build/{Release,Debug} layout. Node.js' require doesn't assume these at all. They show the paths they search through here: https://nodejs.org/api/modules.html#modules_all_together

A typical index in a native addon may look something like: module.exports = require('./build/Release/myaddon') as a result but the path can be changed to anything as long as you can get the binary there.

cjntaylor commented 6 years ago

It can also be used to consolidate dependencies into one directory after the build has finished, be it for tests or for setting up a working directory for the finished binary. It can be used for moving resources into a particular layout for that working directory.

Good point; apologies for not pushing this out sooner.

Also, there's no reason to stick to the the build/{Release,Debug} layout

One of the goals of this project as of 2.0 was to mirror node-gyp's behaviour, which does have a prescribed output directory (out). I also wanted to provide an easy-to-use require() replacement that didn't need the module developer to hard-code where the module was built (and that would automatically switch between the debug and release builds). The result is the search module in index.js which assumes that build + a release target directory will be somewhere in the hierarchy of folders relative to the module that includes node-cmake.

Granted, this can now be altered as of 2.4.0 by specifying the -o/--output argument as part of calls to ncmake, at the cost of breaking this functionality. Of course, you can manually specify it as you've suggested above.

Anyways, hopefully this addresses the original issue you were having, and please do open another issue (or pull request :smile:) if there is another problem. This module sits for long periods of time as there isn't a whole lot that needs to be modified on it at this point, outside of these suggestions.