Skip to content
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

Add quotes for include_dir #1001

Closed
wants to merge 3 commits into from
Closed

Add quotes for include_dir #1001

wants to merge 3 commits into from

Conversation

SurienDG
Copy link

index.js Outdated
@@ -1,6 +1,6 @@
const path = require('path');

const include_dir = path.relative('.', __dirname);
const include_dir = `"path.relative('.', __dirname)"`;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
const include_dir = `"path.relative('.', __dirname)"`;
const include_dir = `"${path.relative('.', __dirname)}"`;

Isn't this the intended change according to nodejs/node-addon-examples#183 (comment)?

Copy link
Author

@SurienDG SurienDG May 15, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are correct. I meant to do that (must've been too tired 😅). Thanks for catching that.

Should be correct now

@mhdawson
Copy link
Member

@mhdawson
Copy link
Member

@hanazuki
Copy link
Contributor

hanazuki commented May 17, 2021

This looks like the wrong way to fix the examples. include_dir was introduced in #766 to replace now-deprecated include and avoid gyp's list-context command expansion (<!@(command)), which fails to correctly escape paths containing spaces, quotes, etc.

Because the packages that already adopted include_dir expect its value to be a non-escaped path (whether they use gyp or not), changing its format breaks all the existing packages.

What we should do is to replace list-context expansion with scalar-context one. For example, 1_hello_world would be:

diff --git i/1_hello_world/node-addon-api/binding.gyp w/1_hello_world/node-addon-api/binding.gyp
index b819abb..ddf73d2 100644
--- i/1_hello_world/node-addon-api/binding.gyp
+++ w/1_hello_world/node-addon-api/binding.gyp
@@ -6,7 +6,7 @@
       "cflags_cc!": [ "-fno-exceptions" ],
       "sources": [ "hello.cc" ],
       "include_dirs": [
-        "<!@(node -p \"require('node-addon-api').include\")"
+        "<!(node -p \"require('node-addon-api').include_dir\")"
       ],
       'defines': [ 'NAPI_DISABLE_CPP_EXCEPTIONS' ],
     }
diff --git i/1_hello_world/node-addon-api/package.json w/1_hello_world/node-addon-api/package.json
index f70a69d..fb231dd 100644
--- i/1_hello_world/node-addon-api/package.json
+++ w/1_hello_world/node-addon-api/package.json
@@ -6,7 +6,7 @@
   "private": true,
   "dependencies": {
     "bindings": "~1.2.1",
-    "node-addon-api": "^1.0.0"
+    "node-addon-api": "^3.0.2"
   },
   "scripts": {
     "test": "node hello.js"

@mhdawson
Copy link
Member

@hanazuki thanks for catching that. Moving the examples to use include_dir instead of include seems like the right way to go. @SurienDG FYI.

@SurienDG
Copy link
Author

SurienDG commented May 19, 2021

I see so if we get rid of the @ it should work on both platforms with the original include_dir? @hanazuki
As you said with

-        "<!@(node -p \"require('node-addon-api').include\")"
+        "<!(node -p \"require('node-addon-api').include_dir\")"

@hanazuki
Copy link
Contributor

@SurienDG I think it should work on Windows as this repository itself is tested in that way on Windows CI environment. (sorry that I don't have a handy local Windows environment to check it).

Even if it doesn't, I suppose we need to fix the gyp's side since it has the responsibility to escape the given paths for each OS and toolchain it supports, and also because changing the node-addon-api side solely for gyp may break packages using the other build tools such as cmake-js.

@SurienDG
Copy link
Author

Ah okay I'll give it a try and then update the examples (if you haven't already). Thanks for your advice @hanazuki

@mhdawson
Copy link
Member

Based on the discussion I think this can be closed. Please let me know if you think that was not the right thing to do.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants