Huge News!Announcing our $40M Series B led by Abstract Ventures.Learn More →
cmake-js - npm Package Compare versions
Comparing version 6.0.0 to 6.1.0
@@ -0,1 +1,6 @@ | ||
| v6.1.0 - 27/02/20 | ||
| ========== | ||
| - Add support for "-A/--platform" option to make target platform selectable for Visual Studio 2019 generator: https://github.com/cmake-js/cmake-js/pull/201 | ||
| v6.0.0 - 30/09/19 | ||
@@ -2,0 +7,0 @@ ================= |
@@ -193,2 +193,5 @@ "use strict"; | ||
| } | ||
| if (this.toolset.platform) { | ||
| command += " -A\"" + this.toolset.platform + "\""; | ||
| } | ||
| if (this.toolset.toolset) { | ||
@@ -304,3 +307,3 @@ command += " -T\"" + this.toolset.toolset + "\""; | ||
| CMake.prototype.reconfigure = async function* () { | ||
| CMake.prototype.reconfigure = async function () { | ||
| await this.clean(); | ||
@@ -307,0 +310,0 @@ await this.configure(); |
@@ -18,2 +18,3 @@ "use strict"; | ||
| this.toolset = options.toolset; | ||
| this.platform = options.platform; | ||
| this.target = options.target; | ||
@@ -174,2 +175,25 @@ this.cCompilerPath = options.cCompilerPath; | ||
| } | ||
| // The CMake Visual Studio Generator does not support the Win64 or ARM suffix on | ||
| // the generator name. Instead the generator platform must be set explicitly via | ||
| // the platform parameter | ||
| if (!this.platform && this.generator.startsWith("Visual Studio 16")) { | ||
| switch(this.targetOptions.arch) { | ||
| case "ia32": | ||
| this.platform = "Win32"; | ||
| break; | ||
| case "x64": | ||
| this.platform = "x64"; | ||
| break; | ||
| case "arm": | ||
| this.platform = "ARM"; | ||
| break; | ||
| case "arm64": | ||
| this.platform = "ARM64"; | ||
| break; | ||
| default: | ||
| this.log.warn("TOOL", "Unknown NodeJS architecture: " + this.targetOptions.arch); | ||
| break; | ||
| } | ||
| } | ||
| } | ||
@@ -176,0 +200,0 @@ else { |
@@ -19,3 +19,3 @@ { | ||
| "main": "lib", | ||
| "version": "6.0.0", | ||
| "version": "6.1.0", | ||
| "author": "Gábor Mező aka unbornchikken", | ||
@@ -22,0 +22,0 @@ "repository": { |
| # CMake.js (MIT) | ||
| ## Quick note to contributors | ||
| First of all, thanks for the PRs! Keep'em comming! I try to verify and release stuff as fast as I can. So, you should not bother to compile and include ES5 files along with your PRs, generating them is the part of the release process. | ||
| ## About | ||
| CMake.js is a Node.js/io.js native addon build tool which works *exactly* like [node-gyp](https://github.com/TooTallNate/node-gyp), but instead of [gyp](http://en.wikipedia.org/wiki/GYP_%28software%29), it is based on [CMake](http://cmake.org) build system. It's compatible with the following runtimes: | ||
| CMake.js is a Node.js/io.js native addon build tool which works (almost) *exactly* like [node-gyp](https://github.com/TooTallNate/node-gyp), but instead of [gyp](http://en.wikipedia.org/wiki/GYP_%28software%29), it is based on [CMake](http://cmake.org) build system. It's compatible with the following runtimes: | ||
@@ -14,80 +10,2 @@ - Node.js 10+ since CMake.js v6.0.0 (for older runtimes please use CMake.js 5) | ||
| ### Supported native libraries | ||
| - **Boost**: it's supported by a separate module called boost-lib, that manages Boost dependencies, downloads and installs appropriate Boost versions from Github, and compiles its required libraries automatically. See the [readme](https://github.com/unbornchikken/boost-lib) and the [tutorial](https://github.com/unbornchikken/cmake-js/wiki/TUTORIAL-04-Creating-CMake.js-based-native-modules-with-Boost-dependency). | ||
| ## Why CMake? | ||
| Nearly every native addon is using node-gyp today, so what's wrong with it? | ||
| 1. First of all, Google, the creator of the gyp platform is moving | ||
| towards its new build system called [gn](https://gn.googlesource.com/gn/), | ||
| which means gyp's days of support are counted. (Just for the record, despite the announced gn switch, | ||
| there is [Bazel](https://github.com/google/bazel) in the works, so sooner or later gn will be dropped in favor of it - IMHO.) | ||
| 2. It uses Python 2 which is a huge PITA in the current century, and because of the above, there is no hope for upgrade, | ||
| see: [node-gyp Issue #193](https://github.com/TooTallNate/node-gyp/issues/193). | ||
| 3. While gyp is very good in dependency management and project generation, | ||
| it still lacks features of essential build customization | ||
| (see: [gyp wiki - Custom_build_steps](https://code.google.com/p/gyp/wiki/GypUserDocumentation#Custom_build_steps)). | ||
| 4. [Its wiki](http://code.google.com/p/gyp/w/list) might be enough for an in-house project, | ||
| but far from what can be called for a good product documentation. | ||
| 5. If you wanna port a native library to node as an addon, | ||
| there is a (very-very) good chance that it doesn't use gyp for its build system, | ||
| you have to make gyp binding by hand, which is really hard or nearly impossible considering the previous bulletpoint. | ||
| Also you have to be an expert of the given build system **and** gyp to do it right. | ||
| 6. There is no IDE that supports gyp as a native project format. Gyp can be used to generate IDE projects, | ||
| but this is not a two way operation, if you tune your settings or setup in the IDE, | ||
| you have to propagate changes back to gyp files by hand. | ||
| 7. Gyp itself isn't capable to build node modules, | ||
| there is fair amount custom JS code in node-gyp module to make it capable to doing so | ||
| (that's why it named as Generate Your Project not Build Your Project). | ||
| So supporting advanced build features like Ninja generators is impossible without extra development effort added to node-gyp | ||
| (see [node-gyp PR #429](https://github.com/TooTallNate/node-gyp/pull/429)). | ||
| It looks like [node-gyp support itself eats up development resources](https://github.com/TooTallNate/node-gyp/issues), | ||
| so there won't be new features like this added or merged in the near future. | ||
| So with node-gyp you are stuck to good old Make which makes build times very long while working on large modules. | ||
| So, let's take a look at CMake compared to the above bullet points. | ||
| 1. Cmake is quite mature and very widely used, making it quite stable and convenient. It's used by projects like | ||
| [Blender](http://wiki.blender.org/index.php/Dev:Doc/Building_Blender/Linux/Ubuntu/CMake), | ||
| [LLVM](http://llvm.org/docs/CMake.html), [MySQL or Netflix](http://www.cmake.org/success/), | ||
| and it isn't likely to be abandoned in the near future. | ||
| 2. It's native software, having no dependencies to any runtime. | ||
| 3. Right now CMake has all of the features that | ||
| [were missing when development of gyp started](https://gyp.gsrc.io/docs/GypVsCMake.md), and on top of that | ||
| it still has those features that gyp didn't have since then. | ||
| It has an own module ecosystem with [internal modules](http://www.cmake.org/cmake/help/v3.2/manual/cmake-modules.7.html), | ||
| and with 3rd party gems like [Compile Time Reducer (Cotire)](https://github.com/sakra/cotire). | ||
| 4. CMake has [excellent documentation](http://www.cmake.org/documentation/), | ||
| lots of [tutorials](https://www.google.hu/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=cmake%20tutorial), | ||
| and [examples](https://www.google.hu/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=cmake+example). | ||
| 5. If you pick a native cross platform library, there is a very good chance that is uses CMake as of its build system, | ||
| or it has CMake build files somewhere, | ||
| for example: [Shark](http://image.diku.dk/shark/sphinx_pages/build/html/rest_sources/getting_started/installation.html), | ||
| [Lua](https://github.com/LuaDist/lua), [SDL](http://wiki.libsdl.org/Installation). | ||
| If not, [there are converters](http://www.cmake.org/Wiki/CMake#Converters_from_other_buildsystems_to_CMake) | ||
| that helps you to create CMake files from other project formats. | ||
| 6. CMake is widely supported by major cross platform C++ IDEs | ||
| like: [QtCreator](http://doc.qt.io/qtcreator/creator-project-cmake.html), [KDevelop](https://www.kdevelop.org/) | ||
| and the upcoming [CLion](https://www.jetbrains.com/clion/#cmake-support) from JetBrains. | ||
| With CMake.js you are gonna be able to develop Node.js addons by using those, | ||
| even you have the ability to use features like integrated debugging. | ||
| 7. CMake.js module doesn't build your project, CMake does. | ||
| All of its commands (configure, build, clean, etc.) are simple CMake invocations without involving JS magic anywhere. | ||
| Even you can print CMake command line with CMake.js module for each command (eg.: cmake-js print-configure, cmake-js print-build, cmake-js print-clean). | ||
| This means supporting new features of a given native build system (like new version of Ninja or Visual Studio) | ||
| won't involve developer efforts from CMake.js side, installing new versions of CMake will be enough. | ||
| ## Installation | ||
@@ -136,2 +54,3 @@ | ||
| -t, --toolset use specified toolset [string] | ||
| -A, --platform use specified platform name [string] | ||
| -T, --target only build the specified target [string] | ||
@@ -290,2 +209,4 @@ -C, --prefer-clang use Clang compiler instead of default CMake compiler, | ||
| If any of the `runtime`, `runtimeVersion`, or `arch` configuration parameters is not explicitly configured, sensible defaults will be auto-detected based on the JavaScript environment where CMake.js runs within. | ||
| You can configure runtimes for compiling target for all depending CMake.js modules in an application. Define a `cmake-js` key in the application's root `package.json` file, eg.: | ||
@@ -314,3 +235,3 @@ | ||
| - **runtimeVersion**: version of the application's target runtime, for example: `0.12.1` | ||
| - **arch**: architecture of application's target runtime (eg: `x64`, `ia32`, `arm`). *Notice: on non-Windows systems the C++ toolset's architecture's gonna be used despite this setting. If you don't specify this on Windows, then architecture of the main node/io.js runtime is gonna be used, so you have to choose a matching nw.js runtime.* | ||
| - **arch**: architecture of application's target runtime (eg: `x64`, `ia32`, `arm64`, `arm`). *Notice: on non-Windows systems the C++ toolset's architecture's gonna be used despite this setting. If you don't specify this on Windows, then architecture of the main node/io.js runtime is gonna be used, so you have to choose a matching nw.js runtime.* | ||
@@ -323,3 +244,3 @@ #### Runtime options in CMakeLists.txt | ||
| - **NODE_RUNTIMEVERSION**: for example: `"0.12.1"` | ||
| - **NODE_ARCH**: `"x64"`, `"ia32"`, `"arm"` | ||
| - **NODE_ARCH**: `"x64"`, `"ia32"`, `"arm64"`, `"arm"` | ||
@@ -418,3 +339,2 @@ #### NW.js | ||
| ```cmake | ||
| # Include N-API wrappers | ||
@@ -459,5 +379,5 @@ execute_process(COMMAND node -p "require('node-addon-api').include" | ||
| - [Jeremy Apthorp](https://github.com/nornagon) - Support for Electron v4+ | ||
| - [Gregor Jasny](https://github.com/gjasny) - CMake 3.14 support | ||
| - [Gregor Jasny](https://github.com/gjasny) - CMake 3.14 support, auto-detect Visual Studio 2019 platform | ||
| - [Rogério Ribeiro da Cruz](https://github.com/rogeriorc) - Windows delay load hook, Electron 4+ compatibility | ||
| - [Jack McKernan](https://github.com/jmcker), [Nik M](https://github.com/nik-m2) - VS 2019 support | ||
| - [Colden Cullen](https://github.com/ColdenCullen) - --cc and --cxx flags |
Sorry, the diff of this file is not supported yet
New alerts
License Policy Violation
LicenseThis package is not allowed per your license policy. Review the package's license to ensure compliance.
Found 1 instance in 1 package
Fixed alerts
License Policy Violation
LicenseThis package is not allowed per your license policy. Review the package's license to ensure compliance.
Found 1 instance in 1 package
Major refactor
Supply chain riskPackage has recently undergone a major refactor. It may be unstable or indicate significant internal changes. Use caution when updating to versions that include significant changes.
Found 1 instance in 1 package
Improved metrics
- Lines of code
- increased by1.8%
1473
- Number of medium supply chain risk alerts
- decreased by-33.33%
2
Worsened metrics
- Total package byte prevSize
- decreased by-4.7%
81576
- Number of lines in readme file
- decreased by-17.51%
377
No dependency changes