From 6f32f5e9cb61e78147eabb787d707d4b484f0c3f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Henr=C3=A9=20Botha?= Date: Thu, 28 Aug 2025 12:30:43 +0200 Subject: [PATCH 1/2] Fix markup Triple backticks is for code blocks, not inline code. --- doc/node-gyp.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/node-gyp.md b/doc/node-gyp.md index 529aa0ea2..f9c83c7ec 100644 --- a/doc/node-gyp.md +++ b/doc/node-gyp.md @@ -11,10 +11,10 @@ Until now **node-gyp** is the **de-facto** standard build tool for writing Node.js addons. It's based on Google's **gyp** build tool, which abstract away many of the tedious issues related to cross platform building. -**node-gyp** uses a file called ```binding.gyp``` that is located on the root of +**node-gyp** uses a file called `binding.gyp` that is located on the root of your addon project. -```binding.gyp``` file, contains all building configurations organized with a +`binding.gyp` file, contains all building configurations organized with a JSON like syntax. The most important parameter is the **target** that must be set to the same value used on the initialization code of the addon as in the examples reported below: @@ -75,7 +75,7 @@ NODE_API_MODULE(NODE_GYP_MODULE_NAME, Init) - [Command options](https://www.npmjs.com/package/node-gyp#command-options) - [Configuration](https://www.npmjs.com/package/node-gyp#configuration) -Sometimes finding the right settings for ```binding.gyp``` is not easy so to +Sometimes finding the right settings for `binding.gyp` is not easy so to accomplish at most complicated task please refer to: - [GYP documentation](https://gyp.gsrc.io/index.md) From 033a3753f4edae63173a8348a928d2343e4836ca Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Henr=C3=A9=20Botha?= Date: Thu, 28 Aug 2025 12:35:29 +0200 Subject: [PATCH 2/2] Improve grammar --- doc/node-gyp.md | 34 +++++++++++++++++----------------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/doc/node-gyp.md b/doc/node-gyp.md index f9c83c7ec..04c42f149 100644 --- a/doc/node-gyp.md +++ b/doc/node-gyp.md @@ -4,19 +4,19 @@ C++ code needs to be compiled into executable form whether it be as an object file to linked with others, a shared library, or a standalone executable. The main reason for this is that we need to link to the Node.js dependencies and -headers correctly, another reason is that we need a cross platform way to build +headers correctly. Another reason is that we need a cross-platform way to build C++ source into binary for the target platform. -Until now **node-gyp** is the **de-facto** standard build tool for writing -Node.js addons. It's based on Google's **gyp** build tool, which abstract away -many of the tedious issues related to cross platform building. +**node-gyp** remains the **de-facto** standard build tool for writing +Node.js addons. It's based on Google's **gyp** build tool, which abstracts away +many of the tedious issues related to cross-platform building. -**node-gyp** uses a file called `binding.gyp` that is located on the root of +**node-gyp** uses a file called `binding.gyp` that is located in the root of your addon project. -`binding.gyp` file, contains all building configurations organized with a -JSON like syntax. The most important parameter is the **target** that must be -set to the same value used on the initialization code of the addon as in the +The `binding.gyp` file contains all building configurations organized with a +JSON-like syntax. The most important parameter is the **target** that must be +set to the same value used in the initialization code of the addon, as in the examples reported below: ### **binding.gyp** @@ -27,8 +27,8 @@ examples reported below: { # myModule is the name of your native addon "target_name": "myModule", - "sources": ["src/my_module.cc", ...], - ... + "sources": ["src/my_module.cc", …], + … ] } ``` @@ -38,11 +38,11 @@ examples reported below: ```cpp #include -// ... +// … /** -* This code is our entry-point. We receive two arguments here, the first is the -* environment that represent an independent instance of the JavaScript runtime, +* This code is our entry point. We receive two arguments here: the first is the +* environment that represent an independent instance of the JavaScript runtime; * the second is exports, the same as module.exports in a .js file. * You can either add properties to the exports object passed in or create your * own exports object. In either case you must return the object to be used as @@ -50,13 +50,13 @@ examples reported below: */ Napi::Object Init(Napi::Env env, Napi::Object exports) { - // ... + // … return exports; } /** -* This code defines the entry-point for the Node addon, it tells Node where to go +* This code defines the entry point for the Node addon. It tells Node where to go * once the library has been loaded into active memory. The first argument must * match the "target" in our *binding.gyp*. Using NODE_GYP_MODULE_NAME ensures * that the argument will be correct, as long as the module is built with @@ -75,8 +75,8 @@ NODE_API_MODULE(NODE_GYP_MODULE_NAME, Init) - [Command options](https://www.npmjs.com/package/node-gyp#command-options) - [Configuration](https://www.npmjs.com/package/node-gyp#configuration) -Sometimes finding the right settings for `binding.gyp` is not easy so to -accomplish at most complicated task please refer to: +Sometimes finding the right settings for `binding.gyp` is not easy, so to +accomplish the most complicated tasks, please refer to: - [GYP documentation](https://gyp.gsrc.io/index.md) - [node-gyp wiki](https://github.com/nodejs/node-gyp/wiki)