This repository has been archived by the owner. It is now read-only.

`./config --debug`: node's .default_configuration should be 'Debug' for debug binary, 'Release' for release binary #4299

wants to merge 1 commit into


None yet
5 participants

NodeJS from Git, configured with (among other things) ./configure --debug, builds both a Debug and a Release build of node.
make install installs the Release build, but node -e 'console.log(process.config.target_defaults.default_configuration)' still gives "Debug" when using the Release build node binary.

From what I've found, this causes node-gyp to build Debug versions of addons unless '-r' option is specified.
This causes problem when npm install builds these addons as dependencies, since no way to specify '-r' option to node-gyp. Not all entry scripts are designed to deal with path to the Debug build of the addon, so using these modules will fail.

Wouldn't it be much more logical to have process.config.target_defaults.default_configuration be:

  • 'Release' for out/Release/node (and the binary installed with make install)
  • 'Debug` for out/Debug/node


See Issue #2571 for reference.
From looking at this issue, I'd quess the solution would be to set default_configuration on each step in {'Debug', 'Release') to match that particular step in the build process.

From looking at this issue, I'd quess the solution would be to set BUILDTYPE on each step in {'Debug', 'Release') to match that particular step in the build process.

No, that still wouldn't fix it. The build process serializes the config.gypi file into a header file as a C string, and that gets compiled into the binary. So we'd need to change that file in between the release and debug build... I haven't yet looked into how hard that would be to do.

ahh... tools/ You're right, should have thought of that.


bnoordhuis commented Nov 21, 2012

The fact that target_defaults.default_configuration == 'Debug' is not really wrong because, well, it is the default configuration - just not the one that's used to compile the binary.

I guess a fairly straightforward solution is to pass -DBUILDTYPE="$(BUILDTYPE)" to the compiler and act on that in src/ but the question then becomes: where to put that property?

Here's a proof-of-concept to test. Instead of changing, it uses a Python macro in src/ (new file) to preprocess src/node.js, substituting the current BUILDTYPE.
Yes, I realize that it's not portable (it depends on env to pass an environment variable to, but it's enough for testing. It should probably use a constant instead, but that requires generating a on the fly (or choosing between a and using a conditional) and passing that to

Perhaps the whole idea of a src/ is worth keeping around for doing build-time configuration of lib/*.js?Please let me know.

$ out/Debug/node -e 'console.log(process.config.target_defaults.default_configuration)'
$ out/Release/node -e 'console.log(process.config.target_defaults.default_configuration)'

Of couse one could do the same in C++, without the need for passing environment variables around, but I have no experience with accessing Javascript stuff from there.
Also, isn't process.config supposed to be read-only after being initialized?

Nope, after second thought, not currently possible from C++, because the substitution must be done as soon as possible after startup.processConfig, before node.js evaluates any command line -e / --eval stuff or other scripts.

Match node's internal default_configuration with build type.
When building after ./configure --debug , both out/Debug/node and
out/Release/node have
process.config.target_defaults.default_configuration === 'Debug'
which causes node_gyp to build addons in Debug mode.
When `npm install` (which normally uses the Release build of node)
builds such addons as dependencies, some modules will fail to load
because their main script is not designed to use the Debug version
of the addon.
Fix this by setting default_configuration to the build type of the
node binary.

Can one of the admins verify this patch?

We could certainly include this but I question the need to use this information, we could use something like ben suggests. Please open a new PR if you still need this feature.

@tjfontaine tjfontaine closed this Feb 18, 2014

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.