-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable Node.js to build with Microsoft's ChakraCore engine #873
Conversation
Thanks for the pull request. This can't land before the PR for core lands but let me point out now that the changes to files in the gyp/ directory should be submitted to the upstream gyp project first. |
lib/build.js
Outdated
@@ -227,6 +227,9 @@ function build (gyp, argv, callback) { | |||
// Specify the build type, Release by default | |||
if (win) { | |||
var p = arch === 'x64' ? 'x64' : 'Win32' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kunalspathak The previous var p = …
here should be removed, I guess?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, that's right.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is still unfixed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My bad, this got missed out while merging. I will remove it.
Sorry about the run-around @kunalspathak but to echo what @bnoordhuis said, we've maintained a fairly strict policy here of only using gyp as it comes from upstream and not landing additional changes ontop of it. Let us know if you need help on that front. |
Thanks @rvagg , not a problem. Could you point me the upstream branch location? |
The official of GYP project is https://gyp.gsrc.io/. Submitting a patch is described in @bnoordhuis knows its workflow well. |
Thanks @shigeki , I will go through the work-flow and get in touch with @bnoordhuis if i have more questions. |
I'm okay with keeping this open if you can rework it to drop the changes to gyp and link to the CL you're going to file. |
@kunalspathak Can you give a quick update on the status of this pull request? I see some changes have landed in upstream gyp. Does that mean this PR is ready to go through? |
@munyirik , you worked on landing this work upstream, right? Can we get this PR merged in that case? |
Yeah the gyp change (in msvs.py) got committed. I don't see the change in nodejs:master. Isn't that where the change should go first before this gets merged? |
When building node-sass and libsass using `npm build .` or `node scripts/build -f`, script uses `node-gyp` version installed as part of `npm install` step inside `node_modules` folder. However this version of `node-gyp` is not compatible with [node-chakracore](https://github.com/nodejs/node-chakracore). It will become partially compatible with node-chakracore once nodejs/node-gyp#873 is merged. However in order to fully work with node-chakracore build need to use the `node-gyp` version that is installed with node-chakracore. This change detects if `npm build` was ran from `Node.js chakracore command prompt` and if yes, use the `node-gyp` that comes with node-chakracore instead of using from `node_modules`.
When building node-sass and libsass using `npm build .` or `node scripts/build -f`, script uses `node-gyp` version installed as part of `npm install` step inside `node_modules` folder. However this version of `node-gyp` is not compatible with [node-chakracore](https://github.com/nodejs/node-chakracore). It will become partially compatible with node-chakracore once nodejs/node-gyp#873 is merged. However in order to fully work with node-chakracore build need to use the `node-gyp` version that is installed with node-chakracore. This change detects if `npm build` was ran from `Node.js chakracore command prompt` and if yes, use the `node-gyp` that comes with node-chakracore instead of using from `node_modules`.
f62dc72
to
3258f00
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The change to MSVSSettings.py seems to be missing. Isn't it needed?
lib/configure.js
Outdated
@@ -272,6 +272,7 @@ function configure (gyp, argv, callback) { | |||
argv.push('-Dnode_gyp_dir=' + nodeGypDir) | |||
argv.push('-Dnode_lib_file=' + release.name + '.lib') | |||
argv.push('-Dmodule_root_dir=' + process.cwd()) | |||
argv.push('-Dnode_engine=' + (gyp.opts.node_engine || process.jsEngine || 'v8')) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
process.jsEngine
doesn't look quite correct. The current node binary might not be the one you're targeting. (node -> node-webkit is a common example.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bnoordhuis , sorry I didn't exactly follow your comment. Could you please elaborate?
process.jsEngine
is something that was added in node-chakracore
to distinguish between engines.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Concrete example: building an add-on for chakra-node with v8-node. If the user doesn't specify --node-engine
on the command line, this will build for an add-on for the wrong binary.
Ideally, the engine is somehow determined from the source tree or headers we're building against. For example, you wouldn't need to set it here if node_engine were a field from node's common.gypi because node-gyp includes that file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the late reply. The design decision we had taken is other way round. Once user specified --node-engine
, we will include appropriate headers deps\v8\include
or deps\chakrasim\include
.
E.g. On windows, it is vcbuild.bat chakracore
On Linux/Mac , it is ./configure --engine=chakracore
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, I think I follow. Still, using process.jsEngine
here means we potentially build the add-on for the wrong binary, right? Not the end of the world but I need to know if my understanding is correct.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you build node.exe
using --node-engine=chakracore
, and using that binary if you are building an add-on, process.jsEngine
will be automatically populated with chakracore
and we will be building an add-on compatible with node-chakracore
. Likewise for node-v8
.
Only scenario where things can go wrong is someone build node-chakracore
and use it to build add-on passing --node-engine=v8
or vice versa. So in that case, your understanding is correct.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, thanks. Minor nit: can you wrap this line at 80 columns?
Sorry, what changes did you mean? I might be missing something here. |
See bnoordhuis/gyp@02b145a - that's the gyp changes, right? That patch adds a line to MSVSSettings.py but the patch in this pull request does not. |
My impression was that patch for |
The change in MSVSSettings.py (the CompileAsWinRT change) wasn't required in this PR. It's something I needed for my UWP fork. |
@@ -8,7 +8,7 @@ | |||
'<(node_root_dir)/include/node', | |||
'<(node_root_dir)/src', | |||
'<(node_root_dir)/deps/uv/include', | |||
'<(node_root_dir)/deps/v8/include' | |||
'<(node_root_dir)/<(node_engine_include_dir)' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
node_engine_include_dir is not defined anywhere, only node_engine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lib/configure.js
Outdated
@@ -272,6 +272,7 @@ function configure (gyp, argv, callback) { | |||
argv.push('-Dnode_gyp_dir=' + nodeGypDir) | |||
argv.push('-Dnode_lib_file=' + release.name + '.lib') | |||
argv.push('-Dmodule_root_dir=' + process.cwd()) | |||
argv.push('-Dnode_engine=' + (gyp.opts.node_engine || process.jsEngine || 'v8')) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, I think I follow. Still, using process.jsEngine
here means we potentially build the add-on for the wrong binary, right? Not the end of the world but I need to know if my understanding is correct.
Microsoft's chakracore engine is dependent on Windows SDK, and build tools should know the version installed on user machine. This change adds those dependencies in node-gyp tools. Below is the summary: * Configure msvs_windows_target_platform_version to use the right Windows SDK. * Configure msvs_use_library_dependency_inputs to export symbols correctly (otherwise functions not used by node.exe but might be needed by native addon modules could be optimized away by linker). These changes were originally made in nodejs/node#4765, but as @shigeki mentioned, it was more sensible to send these changes as PR to node-gyp repo.
* Support building node.js with chakracore on Windows on ARM * Building chakracore for ARM has a dependency on Windows SDK installed on the machine. Update python script to populate `WindowsSDKDesktopARMSupport` and `WindowsTargetPlatformVersion` for ARM builds. This will be using in node repo to build`chakracore.gyp`.
Moved definition of `node_engine_include_dir` from `node-chakracore` to this repo.
3258f00
to
26207f1
Compare
ping. @bnoordhuis , do you have any other feedback? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you make sure tests pass? See https://ci.nodejs.org/view/All/job/nodegyp-test-commit/36/ - both the Linux and Windows bot are red.
lib/configure.js
Outdated
@@ -272,6 +272,7 @@ function configure (gyp, argv, callback) { | |||
argv.push('-Dnode_gyp_dir=' + nodeGypDir) | |||
argv.push('-Dnode_lib_file=' + release.name + '.lib') | |||
argv.push('-Dmodule_root_dir=' + process.cwd()) | |||
argv.push('-Dnode_engine=' + (gyp.opts.node_engine || process.jsEngine || 'v8')) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, thanks. Minor nit: can you wrap this line at 80 columns?
* Fixed CI test failure * Addressed review feedback
I checked and it was because test were ran with
Sure. I noticed that there were some lines that don't follow 80 columns rule, so didn't paid attention. Updated to be within 80 columns. |
Thanks. New CI: https://ci.nodejs.org/view/All/job/nodegyp-test-commit/37/ |
Microsoft's chakracore engine is dependent on Windows SDK, and build tools should know the version installed on user machine. This change adds those dependencies in node-gyp tools. Below is the summary: * Configure msvs_windows_target_platform_version to use the right Windows SDK. * Configure msvs_use_library_dependency_inputs to export symbols correctly (otherwise functions not used by node.exe but might be needed by native addon modules could be optimized away by linker). These changes were originally made in nodejs/node#4765, but as @shigeki mentioned, it was more sensible to send these changes as PR to node-gyp repo. PR-URL: #873 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
* Support building node.js with chakracore on Windows on ARM * Building chakracore for ARM has a dependency on Windows SDK installed on the machine. Update python script to populate `WindowsSDKDesktopARMSupport` and `WindowsTargetPlatformVersion` for ARM builds. This will be using in node repo to build`chakracore.gyp`. PR-URL: #873 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
All green. Thanks Kunal, landed in 93d7fa8...ec5fc36. |
When building node-sass and libsass using `npm build .` or `node scripts/build -f`, script uses `node-gyp` version installed as part of `npm install` step inside `node_modules` folder. However this version of `node-gyp` is not compatible with [node-chakracore](https://github.com/nodejs/node-chakracore). It will become partially compatible with node-chakracore once nodejs/node-gyp#873 is merged. However in order to fully work with node-chakracore build need to use the `node-gyp` version that is installed with node-chakracore. This change detects if `npm build` was ran from `Node.js chakracore command prompt` and if yes, use the `node-gyp` that comes with node-chakracore instead of using from `node_modules`.
When building node-sass and libsass using `npm build .` or `node scripts/build -f`, script uses `node-gyp` version installed as part of `npm install` step inside `node_modules` folder. However this version of `node-gyp` is not compatible with [node-chakracore](https://github.com/nodejs/node-chakracore). It will become partially compatible with node-chakracore once nodejs/node-gyp#873 is merged. However in order to fully work with node-chakracore build need to use the `node-gyp` version that is installed with node-chakracore. This change detects if `npm build` was ran from `Node.js chakracore command prompt` and if yes, use the `node-gyp` that comes with node-chakracore instead of using from `node_modules`.
Enable node.js to build with Microsoft's chakracore engine on Windows x86, x64 and ARM architecture.
The changes were originally made as part of nodejs/node#4765, but based on @shigeki comments and my response, I removed those changes from the PR and sending it separately to this repo.
Commits summary :