Node2nix uses nodejs.src for --nodedir when it can just use the nodejs

[CMCDragonkai]

I've started using node2nix with native addon projects where I'm compiling from C/C++ source in MatrixAI/TypeScript-Demo-Lib#38.

I noticed that inside node-env.nix, it's doing:

  # Extract the Node.js source code which is used to compile packages with
  # native bindings
  nodeSources = runCommand "node-sources" {} ''
    tar --no-same-owner --no-same-permissions -xf ${nodejs.src}
    mv node-* $out
  '';

node2nix/nix/node-env.nix

Lines 204 to 209 in 68f5735

	# Extract the Node.js source code which is used to compile packages with
	# native bindings
	nodeSources = runCommand "node-sources" {} ''
	tar --no-same-owner --no-same-permissions -xf ${nodejs.src}
	mv node-* $out
	'';

Which is later used in --nodedir options for npm rebuild and npm install.

I've found that just using nodejs is a better option than nodejs.src.

Firstly because you don't need to extract from any tar archive, and secondly because nodejs actually contains all the relevant configuration. Right now nodejs.src doesn't have the config.gypi file that does in fact exist in the nodejs store path.

This warning message is shown when using node-gyp against nodejs.src while the warning message doesn't show when just using nodejs store output.

gyp WARN read config.gypi ENOENT: no such file or directory, open '/nix/store/9av58jhvx76lqysgrzc0kixg9f210r2x-node-sources/include/node/config.gypi'

I think it can be entirely removed, and replaced with just --nodedir=${nodejs}.

[CMCDragonkai]

Further investigation on this has revealed that changing to nodejs is the same as if you had ran node-gyp directly because it downloads the node headers which has the same output.

However, I noticed that the node-gyp itself is actually programmed to expect the source directory of the nodejs. As can be seen in:

https://github.com/nodejs/node-gyp/blob/6f74c762fe3c19bdd20245cb5c02e2dfa65d9451/addon.gypi#L20-L28

This results in something like:

-I/nix/store/zl4bvsqfxyx5vn9bbhnrmbmpfvzqj4gd-nodejs-16.14.2/include/node 
-I/nix/store/zl4bvsqfxyx5vn9bbhnrmbmpfvzqj4gd-nodejs-16.14.2/src 
-I/nix/store/zl4bvsqfxyx5vn9bbhnrmbmpfvzqj4gd-nodejs-16.14.2/deps/openssl/config 
-I/nix/store/zl4bvsqfxyx5vn9bbhnrmbmpfvzqj4gd-nodejs-16.14.2/deps/openssl/openssl/include 
-I/nix/store/zl4bvsqfxyx5vn9bbhnrmbmpfvzqj4gd-nodejs-16.14.2/deps/uv/include 
-I/nix/store/zl4bvsqfxyx5vn9bbhnrmbmpfvzqj4gd-nodejs-16.14.2/deps/zlib 
-I/nix/store/zl4bvsqfxyx5vn9bbhnrmbmpfvzqj4gd-nodejs-16.14.2/deps/v8/include 

Now if you use nodejs directly, the only path that works would be:

-I/nix/store/zl4bvsqfxyx5vn9bbhnrmbmpfvzqj4gd-nodejs-16.14.2/include/node 

Whereas the other paths only work if you were using nodejs.src.

However it doesn't matter in the end, because if you wanted md5.h for example, you would use:

#include <openssl/md5.h>

And this would work whether you used only nodejs or nodejs.src because in nodejs, the openssl/md5.h would resolve from the include/node directory, while in the case of nodejs.src, it would resolve from deps/openssl/openssl/include.