cjntaylor / node-cmake Goto Github PK

npm install just outputs Error: spawn EACCES.

• os Darwin 15.3.0 Darwin Kernel Version 15.3.0
• node v4.3.1
• npm 2.14.12

under example there is an 'out' folder containing some mac build products. The extra space taken is a minor annoyance, but on our windows build machines the very long paths produced (> 260 characters) cause problems for some build scripts.
We have a workaround (a hack to delete that folder partway through a build) but would it be possible to remove those, either from this or the next release?

This might be my lack of cmake experience, but I believe cache values are not being overridden in the case of defaults vs CLI cmake values.

If you have a CMakeLists.txt like:

nodejs_init()

# For the sake of debugging.
message(STATUS "NODEJS_BINARY: ${NODEJS_BINARY}")
message(STATUS "NODEJS_VERSION: ${NODEJS_VERSION}")
message(STATUS "NODEJS_SOURCES: ${NODEJS_SOURCES}")
message(STATUS "NODEJS_INCLUDE_DIRS: ${NODEJS_INCLUDE_DIRS}")
message(STATUS "NODEJS_LIBRARIES: ${NODEJS_LIBRARIES}")
message(STATUS "NODEJS_LINK_FLAGS: ${NODEJS_LINK_FLAGS}")
message(STATUS "NODEJS_DEFINITIONS: ${NODEJS_DEFINITIONS}")

And you run it:

$ cmake .. -GXcode

...

-- NodeJS: Using node, version v7.6.0
-- NODEJS_BINARY: /Users/XXXXX/nvm/versions/node/v7.6.0/bin/node
-- NODEJS_VERSION: v7.6.0
-- NODEJS_SOURCES:
-- NODEJS_INCLUDE_DIRS: /Users/XXXXX/dev/XXPROJECTXX/build/node/v7.6.0/include
-- NODEJS_LIBRARIES:
-- NODEJS_LINK_FLAGS: -undefined dynamic_lookup
-- NODEJS_DEFINITIONS: _LARGEFILE_SOURCE;_FILE_OFFSET_BITS=64;_DARWIN_USE_64_BIT_INODE=1

Looks good. If you then decide to build for electron:

$ cmake .. -GXcode -DCODE_COVERAGE=0 -DNODEJS_NAME=iojs -DNODEJS_VERSION=v1.6.4 -DNODEJS_URL=https://atom.io/download/atom-shell

...

-- NodeJS: Using iojs, version v1.6.4
-- NODEJS_BINARY: /Users/XXXXX/nvm/versions/node/v7.6.0/bin/node
-- NODEJS_VERSION: v1.6.4
-- NODEJS_SOURCES:
-- NODEJS_INCLUDE_DIRS: /Users/XXXXX/dev/XXPROJECTXX/build/iojs/v1.6.4/include
-- NODEJS_LIBRARIES:
-- NODEJS_LINK_FLAGS: -undefined dynamic_lookup
-- NODEJS_DEFINITIONS: _LARGEFILE_SOURCE;_FILE_OFFSET_BITS=64;_DARWIN_USE_64_BIT_INODE=1

Notice how NODEJS_BINARY is pointing to the old value?

And finally, if you then later build for just node again, you'll still have the same Electron values:

$ cmake .. -GXcode

...

-- NodeJS: Using iojs, version v1.6.4
-- NODEJS_BINARY: /Users/XXXXX/nvm/versions/node/v7.6.0/bin/node
-- NODEJS_VERSION: v1.6.4
-- NODEJS_SOURCES:
-- NODEJS_INCLUDE_DIRS: /Users/XXXXX/dev/XXPROJECTXX/build/iojs/v1.6.4/include
-- NODEJS_LIBRARIES:
-- NODEJS_LINK_FLAGS: -undefined dynamic_lookup
-- NODEJS_DEFINITIONS: _LARGEFILE_SOURCE;_FILE_OFFSET_BITS=64;_DARWIN_USE_64_BIT_INODE=1

I'm guessing this is because CLI values take precedent over uninitialized defaults. But it's definitely a gotcha. Once the NAME/VERSION/URL is set on the command line, all of those params must be unset (via -U) or given something reasonable.

Or am I doing it wrong?

I get the following error:

[build] Starting build
[proc] Executing command: "C:\Program Files\CMake\bin\cmake.EXE" --build c:/workspace/bla/.bin/win --config Debug --target all -- -j 10
[build] [1/1 100% :: 0.110] Linking CXX shared library bla.abi-79.node
[build] FAILED: bla.abi-79.node bla.abi-79.dll.a 
[build] cmd.exe /C "cd . && c:\workspace\bla\..\mingw32\bin\g++.exe  -Wall -g  -z now -shared -o bla.abi-79.node -Wl,--out-implib,libbla.abi-79.dll.a -Wl,--major-image-version,0,--minor-image-version,0 @CMakeFiles\bla.abi-79.rsp  && cmd.exe /C "cd /D C:\workspace\bla\.bin\win && "C:\Program Files\CMake\bin\cmake.exe" -E copy C:/workspace/bla/.bin/win/bla.abi-79.node C:/workspace/bla/lib/node-v79/bla.node""
[build] c:/workspace/mingw32/bin/../lib/gcc/i686-w64-mingw32/7.3.0/../../../../i686-w64-mingw32/bin/ld.exe: unrecognized option '-z'
[build] c:/workspace/mingw32/bin/../lib/gcc/i686-w64-mingw32/7.3.0/../../../../i686-w64-mingw32/bin/ld.exe: use the --help option for usage information
[build] collect2.exe: error: ld returned 1 exit status
[build] ninja: build stopped: subcommand failed.
[build] Build finished with exit code 1

Hey, this is rather an odd request, but I've written a find_package() routine to find Node.JS in CMake, and I'm looking for its permanent home, to be a part of a native addon builder node package.

https://github.com/hokiedsp/cmake-modules/blob/master/FindNodeJS.cmake

It is a fairly complete routine (downloads the version-matched node/nw/electron runtime files on the fly). The usage (supported components and output variables) is included in the file's header comment block.

I've been using it to build native addons independent of node (I'm a node.js newbie, coming from native side) and it has been working well for what I do. I suspect there are some overlapping features to your NodeJS.cmake (like runtime downloading) but if there is any interest in reviving(?) the find_package() support, I could help merging them. The only caveat of my file is that it has not been tested on non-Windows environment.

Thanks

We are trying to link an Electron addon to an existing 3rd party library with node-cmake, and are getting linking errors on Windows but none on Linux: "error LNK2019: unresolved external symbol".

Any clue as to why?

N-API is starting to gain traction. This should have the ability to compile against it similar to a node runtime I feel like.

maybe NodeJS.cmake need some check for CXX_STANDARD? node v16 need 14...

Looks like the Node libraries are not being linked to the target in the CMake.

Getting linker errors on Windows with MSVC2015.

Using the below line in the CMakeLists.txt resolves the problem, but it would be great ifadd_nodejs_module method itself takes care of it.

  target_link_libraries(${PROJECT_NAME}  ${NodeJS_LIBRARIES})

module.js:598
  return process.dlopen(module, path._makeLong(filename));
                 ^

Error: %1 is not a valid Win32 application.

Works only after by using:
ncmake configure -g "Visual Studio 15 2017 Win64"

The previous version 1.x used keyword signatures for targets. I'm trying to update my project (https://github.com/mapbox/mapbox-gl-native) to 2.x, but am getting this error:

CMake Error at cmake/node.cmake:35 (target_link_libraries):
The plain signature for target_link_libraries has already been used with
the target "mbgl-node". All uses of target_link_libraries with a target
must be either all-keyword or all-plain.

The uses of the plain signature are here:

• cmake/NodeJS.cmake:583 (target_link_libraries)

Why was the signature changed back to the (old?) plain syntax?

Need to deploy prebuild binaries to windows servers (without visual studio installed) with different versions of node installed. It is painful to reconfigure every time.

Replace
GetModuleHandle
GetModuleFileName
PathFindFileName
PathRemoveFileSpec
PathAppend
to
GetModuleHandleA
GetModuleFileNameA
PathFindFileNameA
PathRemoveFileSpecA
PathAppendA

And replace TCHAR with CHAR corresponding

At the moment I can't see a way to pass CMake options to the cmake invocation through ncmake.

Here's how this could look like:

ncmake rebuild -- -DKEY0=VAL0 -DKEY1=VAL1

which should pass the CMake -D options through to the cmake command.

Why is this needed? In a large code base optional node bindings may need cmake support, think

cmake .. -DCMAKE_BUILD_TYPE=Release -DENABLE_NODE_BINDINGS=On -DMORE=Options

but at the moment using ncmake as a build system driver this is not possible.

Irrespective of what is set in the CMAKE_BUILD_TYPE ncmake is always generating MinSizeRel build type.

After verifying the docs looks like there is a config option for the ncmake to set the build type, but it would be good if the default option falls back to what is specified in the CMakeLists (since the addon could get built as part of other CMakeLists based projects and external build options are being overridden with this ncmake behavior)

Hi,

Some cpp files are created by swig.

howto add these files as dependencies , since they are generated by swig .

Regards,
S.Ancelot

i.e.

export npm_config_target=v2.0.0-beta.1
export npm_config_disturl=https://atom.io/download/electron

and maybe we should add two new ones

export npm_config_checksum_type=SHA1
export npm_config_checksum_file=SHASUMS # maybe derives from checksum type?

PS: I believe we don't need npm_config_arch && npm_config_target_arch，right?

FindNodeJS.cmake has

target_include_directories(${NAME} 
        PUBLIC ${NodeJS_INCLUDE_DIRS}
        PUBLIC ${NAN_PATH}
    )

while should have

target_include_directories(${NAME} SYSTEM
        PUBLIC ${NodeJS_INCLUDE_DIRS}
        PUBLIC ${NAN_PATH}
    )

Currently only node.lib is linked. A foreach should be enough.

I'll try to make a patch tomorrow.

The version string v2.0.0-beta.1 breaks the HEADERS_MATCH regular expression:

set(HEADERS_MATCH "^([A-Fa-f0-9]+)[ \t]+([^-]+)-(headers|v?[0-9.]+)-(headers|v?[0-9.]+)([.]tar[.]gz)$")

The content of the SHASUMS.txt

dc6b365c1d2df25205c878e4ecd3e3106cedf2a1  node-v2.0.0-beta.1.tar.gz
337cdeea1c4dadc4c20d688c464bc6223fb9f342  iojs-v2.0.0-beta.1.tar.gz
36c4707de00b044e309c10a67721206a45d632dd  iojs-v2.0.0-beta.1-headers.tar.gz
44adb76edc7eb84f52eab0fb29a73dcc7183bec5  node.lib
555d30c34f09ba2c656745cd4940c24eace0db58  x64/node.lib
44adb76edc7eb84f52eab0fb29a73dcc7183bec5  win-x86/iojs.lib
555d30c34f09ba2c656745cd4940c24eace0db58  win-x64/iojs.lib

If I have a project with several targets, the nodejs_init function will grab the global SOURCES variable and set it as NODEJS_SOURCES

subsequent calls to add_nodejs_module will use NODEJS_SOURCES ... ignoring the parameters passed.

the documentation should reflect this flow:

include(NodeJS.cmake)
nodejs_init()
file(GLOB NODEJS_SOURCES "node/*.cpp")
add_nodejs_module(my_node_module)

Also, if I want to build more than one module.... I'll need multiple CMAKE files (which is OK, but not always desirable)

First, thanks for your work on a great project. My issue: it would be nice to be able to pass compiler options to add_nodejs_module (I'm specifically interested in CXX_STANDARD, currently hardcoded to 11, but I'd imagine other options might be useful as well). Cheers!

Thanks for taking time in making this available. It is helpful.

Presently I have a big c++ project with CMake build system, and I am considering exposing one of the libraries of that project as nodejs-addon and would like keep the addon part into a separate project (in a sub-directory in the big project).

The problem is: right now I have to run npm install on the add-on subproject manually before running the cmake on the parent project.

Is there anyway this can be streamlined?

The goal is: when the cmake is triggered on the parent project, the addon should get configured as part of that process without manual intervention (such as requiring manual npm install).

I see the change to use set_target_properties for LINK_FLAGS, but if the parent scope LINK_FLAGS is empty (and thus NODEJS_LINK_FLAGS is empty), set_target_properties fails.

CMake Error at node_modules/node-cmake/NodeJS.cmake:609 (set_target_properties):
  set_target_properties called with incorrect number of arguments.

In the prependModulePath(args) function when running on windows the paths are not escaped and cmake is choking on the windows \ path that is returned from const MODULE_PATH = path.resolve(__dirname, '..', 'cmake');.

By modifying the function with:

  if (WINDOWS)
    paths = paths.replace(/\\/g, "/");

  out[1] = `CMAKE_MODULE_PATH=${paths}`;

CMake is able to handle the path and work properly.

I am not certain of the proper fix here as it appears that __dirname is working correctly on windows but CMake requires additional escaping or the use of the / to handle the string properly.

cmake version 3.18.2
node v12.18.3

node-cmake version: 2.1.1
Node versions: v6.9.4, v4.7.2
OS: Ubuntu 12.04.5 LTS

Output: (for full output, see Travis CI builds below)

-- Enabling assertions
-- Downloading: https://nodejs.org/download/release/v6.9.4/SHASUMS256.txt
CMake Error at cmake/NodeJS.cmake:280 (message):
  Unable to extract header archive checksum
Call Stack (most recent call first):
  CMakeLists.txt:93 (nodejs_init)

Travis CI Builds:

• https://travis-ci.org/Project-OSRM/node-osrm/jobs/194239977
• https://travis-ci.org/Project-OSRM/node-osrm/jobs/194239975

Encountering many linker errors, such as:

[100%] Linking CXX shared library abc.node
(main.cc.obj):main.cc:(.text+0x1d): undefined reference to `v8::String::NewFromUtf8(v8::Isolate*, char const*, v8::String::NewStringType, int)'

Turns out that the ${NodeJS_LIBRARIES} is empty and not populated with the node js libraries. How to correct this? Environment: -- NodeJS: Using node, version v6.9.2 on Windows 10 with MingW64

Because apparently, node requires this be defined on a target in order to properly provide linkage to a node module.

The previous 1.x branch allowed configuring the CXX_STANDARD by setting NodeJS_CXX_STANDARD. The current branches forces a CXX_STANDARD of 11. What's the reason for this change?

Instead of downloading headers at configuration time it would be great if existing node headers would be detected if they are placed in ~/.nvm/versions/node/$(nvm current)/include.

So that when the CMakeLists.txt is modified, the configuration is re-run (to regenerate the solution/project files) and re-built. (Helpful in the dev cycle)

Right now, ncmake --build does not respect the modifications to the CMakeLists and just verifies only the targets validity.

There doesn't appear to be anyway to invoke install commands from ncmake. You can invoke them by using cmake --build build --target install but there should preferably be a way to invoke them through ncmake.

So this is a repeat of #4 but I will make sure to follow up.

So currently when I build I get a bunch of warnings from include/v8.h (which obscures warnings that are actually my fault) I am using set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -pedantic -Wextra")

node/v6.7.0/include/v8.h:4886:20: warning: unused parameter 'isolate' [-Wunused-parameter]
       v8::Isolate* isolate, v8::Local<v8::String> name) {
                    ^
node/v6.7.0/include/v8.h:4886:51: warning: unused parameter 'name' [-Wunused-parameter]
       v8::Isolate* isolate, v8::Local<v8::String> name) {
                                                   ^
node/v6.7.0/include/v8.h:5373:50: warning: unused parameter 'string' [-Wunused-parameter]
   virtual void VisitExternalString(Local<String> string) {}
                                                  ^
node/v6.7.0/include/v8.h:5383:57: warning: unused parameter 'value' [-Wunused-parameter]
   virtual void VisitPersistentHandle(Persistent<Value>* value,
                                                         ^
node/v6.7.0/include/v8.h:5384:47: warning: unused parameter 'class_id' [-Wunused-parameter]
                                      uint16_t class_id) {}
                                               ^
node/v6.7.0/include/v8.h:7391:55: warning: unused parameter 'isolate' [-Wunused-parameter]
   V8_INLINE static void CheckInitialized(v8::Isolate* isolate) {

If SYSTEM was added to https://github.com/cjntaylor/node-cmake/blob/dev/NodeJS.cmake#L602 it would fix it for me. Is there another way I can/should be doing this?

It's unclear how to take advantage of rebuild hooks when including a package in node_modules.
Cmake-js for example, allows you to specify a cmake-js field in the top-most package.json. Since ncmake appears to ignore node-gyp environment (such as msvs_version), there doesn't appear to be a reliable way to take advantage of the rebuild hooks.

Hi,

First of all, thanks very much for this project! I'm using this over at js-platform/node-webrtc.

We still claim support for Node 4 and 5. Granted, Node's Release schedule states that Node 5 is "End-of-life", but Node 4 is marked "Maintenance LTS" until 2018-04-30.

node-cmake 2.5.0 appears to break compatibility with Node 4 and 5 due to the issue below. Would you consider rewriting this change and releasing a 2.5.1? Otherwise, I may need to cut a patch release pinning to an earlier node-cmake release.

Running ncmake configure --debug
/home/travis/build/js-platform/node-webrtc/node_modules/node-cmake/lib/ncmake.js:10
let argparse = yargs
^^^
SyntaxError: Block-scoped declarations (let, const, function, class) not yet supported outside strict mode
    at exports.runInThisContext (vm.js:53:16)
    at Module._compile (module.js:387:25)
    at Object.Module._extensions..js (module.js:422:10)
    at Module.load (module.js:357:32)
    at Function.Module._load (module.js:314:12)
    at Function.Module.runMain (module.js:447:10)
    at startup (node.js:148:18)
    at node.js:405:3

Mark

perhaps this is documented somewhere that i couldn't find... but it'd be helpful for the folks that use heroku to know how to get cmake into the build system, e.g.,

    heroku buildpacks:set https://github.com/ddollar/heroku-buildpack-multi.git --app $APP

then create .buildpacks with these two lines:

    https://github.com/brave/heroku-cmake-buildpack.git
    https://github.com/heroku/heroku-buildpack-nodejs.git

In traditional CMakeLists, binaries should be linked with third party libraries with the line target_link_libraries(MyApp LibraryToLink)

How can this be done with node cmake?

Copy paste from MS's delayimp.h header

// Prior to Visual Studio 2015 Update 3, these hooks were non-const.  They were
// made const to improve security (global, writable function pointers are bad).
// If for backwards compatibility you require the hooks to be writable, define
// the macro DELAYIMP_INSECURE_WRITABLE_HOOKS prior to including this header and
// provide your own non-const definition of the hooks.

This result in the following error :

win_delay_load_hook.c(35): error C2373: '__pfnDliNotifyHook2': redefinition; different type modifiers

Solution, just add the define DELAYIMP_INSECURE_WRITABLE_HOOKS in win_delay_load_hook.c

#define DELAYIMP_INSECURE_WRITABLE_HOOKS
#define WIN32_LEAN_AND_MEAN
#include <windows.h>

#include <delayimp.h>
#include <string.h>

The current release of node-cmake depends on a vulnerable verson of yargs-parser, which causes npm audit to fail:

┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Low           │ Prototype Pollution                                          │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ yargs-parser                                                 │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Patched in    │ >=13.1.2 <14.0.0 || >=15.0.1 <16.0.0 || >=18.1.2             │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ node-cmake [dev]                                             │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ node-cmake > yargs > yargs-parser                            │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://npmjs.com/advisories/1500                            │
└───────────────┴──────────────────────────────────────────────────────────────┘

[email protected] requires yargs-parser@^5.0.0 via [email protected]
The earliest fixed version is 13.1.2.

Defining a macro like this makes it impossible to use target names that contain dashes, since macros can't contain dashes.

"module.parent.filename" is only accurate the first time node-cmake is included.

This means that if node-cmake is used in two different modules which are used in the same project, the second one fails to find the native module.