Skip to content

The generated config.gypi file should inherit from $nodedir/config.gypi instead of process.config #2490

@zcbenz

Description

@zcbenz

Currently the variables field of the generated config.gypi file inherits from process.config:

node-gyp/lib/configure.js

Lines 101 to 103 in 5f1a06c

var config = process.config ? JSON.parse(JSON.stringify(process.config)) : {}
var defaults = config.target_defaults
var variables = config.variables

And the target_defaults field does inherit from process.config for the reason that the build configurations of the running node executable may be different from the target being compiled for:

node-gyp/lib/configure.js

Lines 115 to 122 in 5f1a06c

// don't inherit the "defaults" from node's `process.config` object.
// doing so could cause problems in cases where the `node` executable was
// compiled on a different machine (with different lib/include paths) than
// the machine where the addon is being built to
defaults.cflags = []
defaults.defines = []
defaults.include_dirs = []
defaults.libraries = []

However the variables field also belongs to build configurations of Node.js, and should be treated the same with target_defaults, for example Node.js executable compiled with v8_enable_pointer_compression=1 can not load modules compiled with v8_enable_pointer_compression=0.

This has been causing problems when compiling modules for Electron, because node-gyp is using process.config.variables of the running node executable for compilation, which are different from the build configurations of Electron.

So the generated config.gypi file should not inherit from process.config at all, and it should inherit from the $nodedir/include/node/config.gypi file instead, which is the actual build configuration of the target.

I can start working out a pull request if the above suggested solution sounds good to the maintainers.

/cc @rvagg

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions