Build native JNI library with a consolidated CMake toolchain (cross-platform)

[drywolf]

@irbull I started replacing the static Visual Studio project files with CMake scripts in my fork.

This is the groundwork to consolidate all build scripts & steps into a single build script toolchain eventually.
Currently I wrote & tested the scripts only for Windows builds (since that's what I'm using J2V8 on), but I would continue work on support for the other platforms if you would be interested in a PR ?

[TonyRice]

Any movement on this?

[drywolf]

@irbull there seems to be demand for this PR ... what is your word on this ?
I'd really like to get a "go" or "no-go" from you before I continue work on this. As a next step I would then try to post a consolidated list of all the .bat/.sh/makefile files that are currently in the repo that I think would be effectively replaced by the CMake toolchain once it is done. I really need your feedback on this since I don't really know all the usages that you might have for all the build-scripts that are all over the repository 😉

My goal is that we can get a clear picture of which usecases the build-system needs to support

[irbull]

I have spent a good portion of last week looking at cross platform builds, and if you have something that works, then a big +1 from me!!!

Are you just building J2V8, or are you building V8 / node as well. What platform does the build itself run on? How many platforms have you managed to get working? (I was unable to get Node to build for Mac when the build was running on Linux).

[drywolf]

In my fork I'm just looking into the native part (V8 / Node) since CMake is primarily designed to build cross platform C/C++ projects. Did you look into something similar for the Java side ? or is a true cross platform build already possible for the Java code ?

(I was unable to get Node to build for Mac when the build was running on Linux).

I'm uncertain what you mean by that, do you mean that you cross-compile Node on a linux host but targeting a Mac binary output ? The distinction between a cross-platform build toolchain and a cross-compiling toolchain makes a big difference in the complexity of the setup.

I saw in the repository some Dockerfiles, are those part of the attempts that you mentioned ? This would mean that we want to also go for cross-compiling ... but I think as long as we can get a working Docker image for each of the supported build + target platform combinations, then the rest will again just be regular CMake scripts (i.e. easy enough).

Virtualizing MacOS on Linux using docker does not seem to be supported though, so we might have to go for a full VM virtualization with something like Vagrant.

PS: what are the usecases for Maven + Gradle build scripts ? is one of those deprecated or are both still in use ?

PSS: which OS are you using to develop / compile J2V8 ? (I'm primarily on Win 10)

[irbull]

The Java side is easy -- compiled Java files can run on all platforms. The scripts are a mess because we have a few different requirements (.aar file that can be consumed by Gradle and Android Studio, and maven builds for Jars for Maven Central), but I'm confident I can clean those up.

The harder part is the cross-compiling.

In my case, I was (still am) trying to cross-compile node for Mac from a linux machine. The concept was to encode the steps in a Dockerfile, and run it on Docker. From what I understand, the host will always be linux -- but please correct me if I'm wrong there (I actually hope I'm wrong).

What do you mean by:

The distinction between a cross-platform build toolchain and a cross-compiling toolchain make a lot of a difference in the complexity of the setup.

What does a cross-platform build toolchain give us if we cannot cross-compile and target a different OS/Architecture than we are currently running on.

BTW, Thanks for taking the time and following up on this. I was getting pretty frustrated last week -- and was ready to give up. But you have given me some new hope :)

[drywolf]

What does a cross-platform build toolchain give us if we cannot cross-compile and target a different OS/Architecture than we are currently running on.

The benefit that you get from a cross-platform build toolchain (like CMake) alone is that you can support all the native IDEs & CLI build toolchains that are supported by such a tool ... see here for CMake's supported target toolsets
This is nice for a team of developers on diverse platforms that want to work on a project together, because every developer can work with their OS & IDE/CLI of choice, but still they are all working together on a consolidated build-system definition (in the form of CMake files). Also the project is then potentially going to compile properly at least on each platform that was considered in the definition of the CMake files.

So imho the wins when using CMake over a custom cross-platform build script solution are:

• a consolidated defintion for the build-processes of the project between all supported target platforms
• more freedom of choice for the developers regarding their used IDEs / CLIs

Regarding the MacOS build on a Linux host ... yes, most of the time Docker will run a Linux container, Microsoft has been working on support for Windows Server in Docker containers but I have not tried those out yet 😄

Which docker image did you use for your MacOS build ? Was it one off the Dockerhub or a custom one ?
Just a regular Linux image or something specialized for MacOS ? Did you use clang for the cross-compilation ? any other tools like https://github.com/tpoechtrager/osxcross ?

BTW, Thanks for taking the time and following up on this.

It's a pleasure ... I really like the idea of this project, I'm a big fan of JavaScript but I also see why Java is needed in enterprises ... so I can imagine many interesting usecases for J2V8 ... also I'm working on a little side project to get production-ready ES6 class interop running with J2V8.

[irbull]

Alright, I'm convinced 😄.

To split things out (and hopefully make this repository easier to navigate), I have just created a new project called Static Node Build. This will just include the scripts to build node.js.

This is currently a collection of Dockerfiles and build.sh. If you can help with converting some of the scripts to CMake that would be great! I'd be happy to just have Dockerfiles and CMake files.

I'm hoping that we can run make from the root of this and get the static libraries for all the supported platforms, but that might be wishing for a bit too much. If we could at least run it on the current platform and produce the artifacts for that platform, that would be great.

As for the Mac build, yes I tired osxcross and some of the docker images people have made using that. However, the platform is still reported as linux and it appears that some of the node.js build checks this and tries to include linux specific header files and link against linux libraries, which doesn't work.

[drywolf]

Great, I will also look if I can get a Node.js MacOS cross-compile working in Docker ... once we have that figured out I could continue the work on transitioning the build-scripts to a consolidated CMake setup.

[irbull]

I have pushed the Dockerfile I used to try and build the MacOS binaries on Linux using the osxcross toolchain. This fails once the build starts because of missing .h files. However, these are linux specific headers. I assume this is happening because sys.platform is returning Linux, not Darwin (because the host is linux).

[drywolf]

I just finished the trip down the rabbit hole and ended up in the same place as you @irbull 😆
The cross compile / dest-os options passed to ./configure seem not to correctly get passed down the line ... however, what I found out is that you can manually override the OS by adding custom variables in the v8.gyp file, for example:

  'variables': {
    'OS': 'mac', <----- manually added
    'host_os': 'mac', <----- manually added
    'v8_code': 1,
    'v8_random_seed%': 314159265,
    'v8_vector_stores%': 0,
    'embed_script%': "",
    'warmup_script%': "",
    'v8_extra_library_files%': [],
    'v8_experimental_extra_library_files%': [],
    'mksnapshot_exec': '<(PRODUCT_DIR)/<(EXECUTABLE_PREFIX)mksnapshot<(EXECUTABLE_SUFFIX)',
    'mkpeephole_exec': '<(PRODUCT_DIR)/<(EXECUTABLE_PREFIX)mkpeephole<(EXECUTABLE_SUFFIX)',
  },

I'm not yet sure if both of those variables should be set to mac or if the host_os should still be linux.
My current test setup is currently quite a mess from all the experimentation and hours are already late here, I will continue the investigation tomorrow.

[drywolf]

Alternatively adding -DOS=mac to gyp_node.py should be a way to have gyp use it in all gyp files.

[irbull]

Great job @drywolf!

I've made a few changes to the Dockerfile for mac. In particular, I used x64 disabled the use of dtrace and set --xcode. eclipsesource/static-node-build@dce38ec

With those changes, plus adding your changes above (both OS mac, host_os mac and adding -DOS=mac to the gyp_node.py), I get further. In fact, it appears the compile steps finishes. However, it now fails for me during linking:

  o64-g++   -o /build/node/out/Release/mkpeephole -Wl,--start-group /build/node/out/Release/obj.target/mkpeephole/deps/v8/src/interpreter/bytecodes.o /build/node/out/Release/obj.target/mkpeephole/deps/v8/src/interpreter/mkpeephole.o /build/node/out/Release/obj.target/deps/v8/src/libv8_libbase.a -Wl,--end-group 
ld: unknown option: --start-group

It appears that --start-group / --end-group is not available on Mac (or in our case Mac toolchains). I'm not sure why it's trying the Linux linking step here.

[irbull]

Also, I set CXXFLAGS=-std=gnu++0x

[drywolf]

According to this stackoverflow post, -Wl, --start-group and --end-group are not supported by the MacOS ld

If I remove those from the generated Makefile like so...

sed -i -e 's|--start-group||g' ./out/Makefile
sed -i -e 's|--end-group||g' ./out/Makefile
sed -i -e 's|-Wl, ||g' ./out/Makefile

I'm now stuck at the following linker problem:

ld: warning: ignoring file /build/node/out/Release/obj.target/deps/v8/src/libv8_libbase.a, file was built for unsupported file format ( 0x21 0x3C 0x74 0x68 0x6
9 0x6E 0x3E 0x0A 0x2F 0x2F 0x20 0x20 0x20 0x20 0x20 0x20 ) which is not the architecture being linked (x86_64): /build/node/out/Release/obj.target/deps/v8/src/
libv8_libbase.a
Undefined symbols for architecture x86_64:
  "_V8_Fatal", referenced from:
      v8::internal::interpreter::Bytecodes::Size(v8::internal::interpreter::Bytecode, v8::internal::interpreter::OperandScale) [clone .constprop.36] in bytecodes.o

[irbull]

I don't think trying to tweak the generated makefiles will be successful. We need to understand why it's creating Linux specific makefiles when using the MacOSX toolchain. I'm hoping there is another parameter (like the OS=mac) that we're just missing. I've updated our progress on nodejs/node#12556 (comment) in case anyone has ideas. Thanks!

[drywolf]

I made some further progress looking into what the build currently produces (the error above).
This was caused because the build was using the Linux ar instead of the MacOS ar from osxcross (AR=x86_64-apple-darwin12-ar)

This lets the build continue further, but then I seem to run into this issue

make[1]: Entering directory '/build/node/out'
  LD_LIBRARY_PATH=/build/node/out/Release/lib.host:/build/node/out/Release/lib.target:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; cd ../deps/v8/src; mkdir -p /bu
ild/node/out/Release/obj.target/v8_base/geni; "/build/node/out/Release/mkpeephole" "/build/node/out/Release/obj.target/v8_base/geni/bytecode-peephole-table.cc"
/build/node/out/Release/mkpeephole: 4: /build/node/out/Release/mkpeephole: Syntax error: ")" unexpected
deps/v8/src/v8_base.target.mk:13: recipe for target '/build/node/out/Release/obj.target/v8_base/geni/bytecode-peephole-table.cc' failed
make[1]: *** [/build/node/out/Release/obj.target/v8_base/geni/bytecode-peephole-table.cc] Error 2

[drywolf]

One alternative would be using Vagrant as said. I already built node successfully using this Vagrant box, which comes as a download of a 13 GB image though, so not as lightweight as a Docker setup, but at least this one would work right now.

[irbull]

@drywolf I agree. We've put a valiant effort into this, and a docker based solution would be nice, but it might not be worth it. Furthermore, we will likely go through all this again when we try and target the next version of node.

Here is what I think we should do.

1. Create a cross platform build script that builds node for all our platforms. We can use docker, Vagrant, whatever. Ideally it will run on Mac / Windows / Linux and produce node/node.adroid.x86, node/node.android.arm, node/node.mac.x64, ...

2. Take the output of this and produce a fully built target platform tarball that someone can download if they want.

3. Use the tarball in the J2V8 builds (I'm not sure if should produce all platforms in the J2V8 builds).

With this approach someone can either download our giant (it will be big) tarball with the prebuild platforms, or they can run the full node build themselves.

I am currently producing the tarball for Android right now. I haven't tried Vagrant before, but it seems like a good time to learn.

[drywolf]

Hi @irbull

I see that you are already busy, converting parts of the build / publish workflows to a new structure 👍

Here's a short summary on what I have been up to:

• I created a Vagrant configuration & scripts to successfully build the MacOS binaries (I looked at how you did it in your Docker builds and pretty much did it the same way, but using Vagrant)
• I saw that you created buildAll.sh (and some other scripts) for the consolidated build process. While I like the overall structure, what makes me worry is the use of shell scripts for the control of the builds outside Docker/Vagrant because they are not easily able to be run on non-unix based platforms

To improve on the second point I started converting the scripts to python scripts instead, while also putting in some simple code structures to make the build-system primitives & configs a little bit reusable and more easy to maintain. Based on your buildAll.sh I created a small python build-system that allows to define the same behavior as follows:

docker = DockerBuildSystem()
vagrant = VagrantBuildSystem()

docker_builds = [
    #------------------------------------------------------------------------------------------
    BuildConfig("android", "x86",
    [
        MountPoint("$PWD/node.out", "/build/node")
    ],
    "android-gcc-toolchain x86 --api 15 --host gcc-lpthread -C sh -c \"cd jni && ndk-build\""),
    #------------------------------------------------------------------------------------------
    BuildConfig("linux", "x64",
    [
        MountPoint("$PWD/node.out", "/build/node"),
        MountPoint("$PWD", "/build/."),
    ]),
    #------------------------------------------------------------------------------------------
]

vagrant_builds = [
    #------------------------------------------------------------------------------------------
    BuildConfig("macos", "x64"),
    #------------------------------------------------------------------------------------------
]

docker.build(docker_builds)
vagrant.build(vagrant_builds)

PS: I'm thinking about moving the declaration of the Docker filesystem mounts also into the Dockerfile, similar as it is done in Vagrant, which would make the above syntax even more concise.

This is already working and runs both the docker and vagrant builds successfully. Before I continue to put more work into it though I would like to hear from you if you would be accepting of using python instead of bash for the high-level scripting.

Please let me know of what you think and if I should continue, I would then soon submit a PR with the python equivalents of the current shell scripts + the MacOS build additions.

Once we have that, I would then expand the cross-platform support of the cmake scripts that I already wrote for Windows/Visual Studio for the other platforms.

[drywolf]

I've continued work on the architecture & code for the build-system that I outline above. The capabilities have already expanded quite a bit, so far the proof-of-concept is capable of supporting the following features / usecases:

(MacOS used as example platform, works for the others too)

• run selective builds of certain build-stages or a full build of all build stages in order
  • nodejs
  • j2v8-cmake
  • j2v8-jni
  • j2v8-java
• run a build on bare metal
  • python ./build_platform.py -t macos -a x64 -ne
• run a build via cross-compilation (actual build runs in Vagrant MacOS VM)
  • python ./build_platform.py -t macos -a x64 -ne -x
• run a build from within another python script

import build_platform as b

b.execute_build(b.target_macos, b.arch_x86, b.build_all, node_enabled = True, cross_compile = True)
b.execute_build(b.target_macos, b.arch_x64, b.build_all, node_enabled = True, cross_compile = True)

@irbull Please let me know if this still looks good to you, I'd not like to put so much effort into this without knowing if I'm headed in the right direction 😉

[drywolf]

To expand on the example of using the API in scripts, this is what it would look like to build just Node.JS for all platforms:

# build Node.js only
def build_njs(target, arch):
    b.execute_build(target, arch, [b.build_node_js], node_enabled = True, cross_compile = True)

build_njs(b.target_android, b.arch_arm)
build_njs(b.target_android, b.arch_x86)

build_njs(b.target_linux, b.arch_x86)
build_njs(b.target_linux, b.arch_x64)

# needs reboot here to turn Hyper-V off if Host-OS is Windows

build_njs(b.target_macos, b.arch_x86)
build_njs(b.target_macos, b.arch_x64)

# needs reboot here to switch to Windows-Containers

build_njs(b.target_win32, b.arch_x86)
build_njs(b.target_win32, b.arch_x64)

[drywolf]

The MacOS build & cross-compile is now working (almost)

Before that I even got many more errors, because the maven surefire plugin was trying to run the java unit tests in parallel which I could fix by adding ...

      <forkCount>1</forkCount>
      <reuseForks>false</reuseForks>

... in the pom.xml, but the errors in the screenshot above are still happening.
@irbull do you have any idea what could be causing those errors?
All of them are happening in the NodeJSTest.java and most of those are actually the same error:

testExports(com.eclipsesource.v8.NodeJSTest)  Time elapsed: 0.085 s  <<< ERROR!
java.lang.NullPointerException
	at com.eclipsesource.v8.NodeJSTest.tearDown(NodeJSTest.java:36)

Also I just pushed all my code in its current state to my J2V8 fork
I'll work on build-support for the other platforms next ... probably windows first, since it was already working with CMake before, so it should be a given.

[drywolf]

I figured it out, I was missing the -force_load option for linking libnode.a, now all the tests are passing.

I will clean up the scripts a little bit more tomorrow, and by then the integration for MacOS is pretty much done.

[drywolf]

Just tried out my existing windows CMake build and with some small additions for node 7.4.0 it still does produce the shared lib for j2v8. But I seem to be running into the same problem as I was with the linker on MacOS stripping out some symbols from node.lib which results in the Node.js tests failing on windows too...

@TonyRice from what I saw you were already able to build J2V8 for windows after the 7.4.0 update, did you need to make any special changes to the linker options ? Did you build with node-support enabled ?

[TonyRice]

@drywolf I'm actually currently building with VS2015 and node version v7.10.0. If you checkout the 7.10.0 tag and checkout vcbuild.bat from master you should be able to run vcbuild.bat release x64 dll static

I am currently attempting to update the project to the latest versions. My local fork is a little different than the original but I hope to get things working. I am going to try out your cmake builds and see what happens from there.

[drywolf]

I found the cause of the problem. Some of the builtin node-module registrations were missing in com_eclipsesource_v8_V8Impl.cpp for v7.4.0. Once I fixed that, the build was working and the tests ran just fine. I think I will look into a way to detect this situation in the build scripts that I'm working on to have the option for an early abort of the build, since otherwise you are spending time building artifacts that are ultimately not going to work later anyway. I'd really like to improve that while I'm already at it.

[drywolf]

I'm currently setting up the android cross-compile ... @irbull do you run the junit tests in some way on android to make sure the jar + native lib are working ?

[drywolf]

I'm back for the weekly(ish) progress update.

I currently have Android builds working for the two target architectures (armv7a & x86), including the bundling as an AAR package. I have also just now got android instrumentation tests set up to run the existing unit-test suite of J2V8 to see if everything is working as expected with the android build artifacts.

And the results look quite promising...

(this was produced by running the tests in the x86 android emulator)

Next up is the linux build configuration, and with that I'm then heading towards the end of the roadmap/todos for what I had planned for this build-system integration. So a PR should be coming up pretty soon 😉

[irbull]

Sorry, I'm not ignoring you. I just returned from vacation. I am catching up on issues / emails right now. I will look at this tonight.

Regarding the unit tests. No, I don't run them "on device". It would be cool to do this, but I don't currently have a setup to make this work.

[irbull]

Some notes:

1. Regarding build scripts vs Python:

I completely agree with you. The build scripts I added are pretty simple, and I only added them as control files so I could get a build to run. I think a platform independent build script is a much better idea. I don't think there is any real logic in these files, but I could be mistaken.

2. Selective build stages:

Awesome! This is pretty important, especially the part about not building node each time. I was hitting build time limits on Travis.

I think this is exactly the right direction.

3. Your on device tests:

Some of those (RuntimeNotLoaded and testGetOSLinux) I'm not really worried about. The other ones are interesting though. If you put your work in a PR, I can try it tomorrow and look at the tests.

[drywolf]

Sorry, I'm not ignoring you. I just returned from vacation. I am catching up on issues / emails right now. I will look at this tonight.

No worries, welcome back 😄

[drywolf]

I am closing this since the main focus of this issue is achieved by the merging of #280
Any related issues / additional features are already being discussed in several other issues.

[rajeshpandry]

@drywolf I'm actually currently building with VS2015 and node version v7.10.0. If you checkout the 7.10.0 tag and checkout vcbuild.bat from master you should be able to run vcbuild.bat release x64 dll static

I am currently attempting to update the project to the latest versions. My local fork is a little different than the original but I hope to get things working. I am going to try out your cmake builds and see what happens from there.

Hello @drywolf
Have you able to successfully built the J2V8 windows 64 bit JAR for latest version of NODE? it would be a great if you share the JAR file and let me know the steps how to compile it?
I am using Microsoft Visual Studio 2017 for compiling and node version is v8.11.2
winbuild.bat is giving me an error
1>c:\program files (x86)\windows kits\10\include\10.0.17134.0\ucrt\corecrt_memcpy_s.h(47): error C2065: 'EINVAL': undeclared identifier
1>c:\program files (x86)\windows kits\10\include\10.0.17134.0\ucrt\corecrt_memcpy_s.h(52): error C2065: 'EINVAL': undeclared identifier
1>c:\program files (x86)\windows kits\10\include\10.0.17134.0\ucrt\corecrt_memcpy_s.h(53): error C2065: 'ERANGE': undeclared identifier
1>c:\program files (x86)\windows kits\10\include\10.0.17134.0\ucrt\corecrt_memcpy_s.h(56): error C2065: 'EINVAL': undeclared identifier
1>c:\program files (x86)\windows kits\10\include\10.0.17134.0\ucrt\corecrt_memcpy_s.h(76): error C2065: 'EINVAL': undeclared identifier
1>c:\program files (x86)\windows kits\10\include\10.0.17134.0\ucrt\corecrt_memcpy_s.h(77): error C2065: 'EINVAL': undeclared identifier
1>c:\program files (x86)\windows kits\10\include\10.0.17134.0\ucrt\corecrt_memcpy_s.h(78): error C2065: 'ERANGE': undeclared identifier
1>c:\program files (x86)\microsoft visual studio\2017\enterprise\vc\tools\msvc\14.15.26726\include\string(190): error C2065: 'ERANGE': undeclared identifier
1>c:\program files (x86)\microsoft visual studio\2017\enterprise\vc\tools\msvc\14.15.26726\include\string(208): error C2065: 'ERANGE': undeclared identifier
1>c:\program files (x86)\microsoft visual studio\2017\enterprise\vc\tools\msvc\14.15.26726\include\string(226): error C2065: 'ERANGE': undeclared identifier
1>c:\program files (x86)\microsoft visual studio\2017\enterprise\vc\tools\msvc\14.15.26726\include\string(244): error C2065: 'ERANGE': undeclared identifier
1>c:\program files (x86)\microsoft visual studio\2017\enterprise\vc\tools\msvc\14.15.26726\include\string(262): error C2065: 'ERANGE': undeclared identifier
1>c:\program files (x86)\microsoft visual studio\2017\enterprise\vc\tools\msvc\14.15.26726\include\string(279): error C2065: 'ERANGE': undeclared identifier
1>c:\program files (x86)\microsoft visual studio\2017\enterprise\vc\tools\msvc\14.15.26726\include\string(296): error C2065: 'ERANGE': undeclared identifier
1>c:\program files (x86)\microsoft visual studio\2017\enterprise\vc\tools\msvc\14.15.26726\include\string(313): error C2065: 'ERANGE': undeclared identifier
1>c:\program files (x86)\microsoft visual studio\2017\enterprise\vc\tools\msvc\14.15.26726\include\string(332): error C2065: 'ERANGE': undeclared identifier
1>c:\program files (x86)\microsoft visual studio\2017\enterprise\vc\tools\msvc\14.15.26726\include\string(350): error C2065: 'ERANGE': undeclared identifier
1>c:\program files (x86)\microsoft visual studio\2017\enterprise\vc\tools\msvc\14.15.26726\include\string(368): error C2065: 'ERANGE': undeclared identifier
1>c:\program files (x86)\microsoft visual studio\2017\enterprise\vc\tools\msvc\14.15.26726\include\string(386): error C2065: 'ERANGE': undeclared identifier
1>c:\program files (x86)\microsoft visual studio\2017\enterprise\vc\tools\msvc\14.15.26726\include\string(404): error C2065: 'ERANGE': undeclared identifier
1>c:\program files (x86)\microsoft visual studio\2017\enterprise\vc\tools\msvc\14.15.26726\include\string(421): error C2065: 'ERANGE': undeclared identifier
1>c:\program files (x86)\microsoft visual studio\2017\enterprise\vc\tools\msvc\14.15.26726\include\string(438): error C2065: 'ERANGE': undeclared identifier
1>c:\program files (x86)\microsoft visual studio\2017\enterprise\vc\tools\msvc\14.15.26726\include\string(455): error C2065: 'ERANGE': undeclared identifier
j2v8\node\src\node.h(239): warning C4275: non dll-interface class 'v8::Platform' used as base for dll-interface class 'node::MultiIsolatePlatform'
j2v8\node\deps\v8\include\v8.h(93): note: see declaration of 'v8::Platform'
j2v8\node\src\node.h(239): note: see declaration of 'node::MultiIsolatePlatform'
j2v8\node\src\node.h(728): warning C4251: 'node::CallbackScope::try_catch_': class 'v8::TryCatch' needs to have dll-interface to be used by clients of class 'node::CallbackScope'
j2v8\node\deps\v8\include\v8.h(8529): note: see declaration of 'v8::TryCatch'
j2v8\j2v8\jni\com_eclipsesource_v8_v8impl.cpp(371): error C2660: 'node::CreateEnvironment': function does not take 7 arguments
j2v8\node\src\node.h(284): note: see declaration of 'node::CreateEnvironment'
j2v8\j2v8\jni\com_eclipsesource_v8_v8impl.cpp(432): error C2661: 'v8::ObjectTemplate::New': no overloaded function takes 0 arguments
j2v8\j2v8\jni\com_eclipsesource_v8_v8impl.cpp(608): error C2039: 'TerminateExecution': is not a member of 'v8::V8'
j2v8\node\deps\v8\include\v8.h(8087): note: see declaration of 'v8::V8'
j2v8\j2v8\jni\com_eclipsesource_v8_v8impl.cpp(608): error C3861: 'TerminateExecution': identifier not found
j2v8\j2v8\jni\com_eclipsesource_v8_v8impl.cpp(694): error C2512: 'v8::TryCatch': no appropriate default constructor available
j2v8\node\deps\v8\include\v8.h(8529): note: see declaration of 'v8::TryCatch'
j2v8\j2v8\jni\com_eclipsesource_v8_v8impl.cpp(704): error C2512: 'v8::TryCatch': no appropriate default constructor available
j2v8\node\deps\v8\include\v8.h(8529): note: see declaration of 'v8::TryCatch'
j2v8\j2v8\jni\com_eclipsesource_v8_v8impl.cpp(718): error C2512: 'v8::TryCatch': no appropriate default constructor available
j2v8\node\deps\v8\include\v8.h(8529): note: see declaration of 'v8::TryCatch'
j2v8\j2v8\jni\com_eclipsesource_v8_v8impl.cpp(732): error C2512: 'v8::TryCatch': no appropriate default constructor available
j2v8\node\deps\v8\include\v8.h(8529): note: see declaration of 'v8::TryCatch'
j2v8\j2v8\jni\com_eclipsesource_v8_v8impl.cpp(747): error C2512: 'v8::TryCatch': no appropriate default constructor available
j2v8\node\deps\v8\include\v8.h(8529): note: see declaration of 'v8::TryCatch'
j2v8\j2v8\jni\com_eclipsesource_v8_v8impl.cpp(761): error C2512: 'v8::TryCatch': no appropriate default constructor available
j2v8\node\deps\v8\include\v8.h(8529): note: see declaration of 'v8::TryCatch'
j2v8\j2v8\jni\com_eclipsesource_v8_v8impl.cpp(783): error C2512: 'v8::TryCatch': no appropriate default constructor available
j2v8\node\deps\v8\include\v8.h(8529): note: see declaration of 'v8::TryCatch'
j2v8\j2v8\jni\com_eclipsesource_v8_v8impl.cpp(810): error C2512: 'v8::TryCatch': no appropriate default constructor available
j2v8\node\deps\v8\include\v8.h(8529): note: see declaration of 'v8::TryCatch'
j2v8\j2v8\jni\com_eclipsesource_v8_v8impl.cpp(1058): warning C4267: 'return': conversion from 'size_t' to 'jint', possible loss of data
j2v8\j2v8\jni\com_eclipsesource_v8_v8impl.cpp(1611): error C2039: 'IdleNotification': is not a member of 'v8::Isolate'
j2v8\node\deps\v8\include\v8.h(6981): note: see declaration of 'v8::Isolate'
j2v8\j2v8\jni\com_eclipsesource_v8_v8impl.cpp(1645): error C2039: 'IdleNotification': is not a member of 'v8::Isolate'
j2v8\node\deps\v8\include\v8.h(6981): note: see declaration of 'v8::Isolate'
j2v8\j2v8\jni\com_eclipsesource_v8_v8impl.cpp(1675): error C2660: 'v8::Object::SetPrototype': function does not take 1 arguments
j2v8\node\deps\v8\include\v8.h(3442): note: see declaration of 'v8::Object::SetPrototype'
1>Done building project "j2v8.vcxproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

[drywolf]

As mentioned above I only built node using VS 2015 ... using VS 2017 might need adjustments to get working ... you should look into the node.js build documentation if this version is even supposed to compile with VS 2017. TBH I haven't used J2V8 or built node.js from source for over a year now, so others might be more in the loop on the latest details of how to build node with VS.

[rajeshpandry]

Thanks a lot. VS 2015 JAR is available? I can try to use it for one of my solution. could you please share it.