gyp.js
gyp.js copied to clipboard
`shared_library` support
gyp.js currently supports static_library, executable, and none target_type, but shared_library is very important for Node.js addons! Therefore we need to support it in ninja.
Hints:
Possible problems - many.
Support:
- [x] OS X
- [x] Windows
- [x] Linux
- [x] FreeBSD (needs verification, should work)
- [ ] Others (needs verification, should work)
Could be tested on https://github.com/indutny/llnode
I'm going to take OS X support for this.
OS X - done.
Linux - appears to be working.
I'm inclined to say that FreeBSD and other Unixes should work, but this needs a verification.
Anyone wants to verify this?
Hey i'd like to ! Could you tell me where i should start ? llnode seems to be something different.
@kapouer thank you!
@pmed you said that you tested windows shared_library support on node.js addons, would you care to share some info on this with us? Thanks!
@kapouer llnode may be a bit too complicated. However, if you want to give it a shot, the way to do it is:
- Install node.js on the system
- Install
ninjafrom https://ninja-build.org/ npm install -g gyp.jsgit clone [email protected]:indutny/llnode.git && cd llnode- Install lldb-3.8 or any lldb, and its headers (Honestly, I don't know how to do it on FreeBSD, or anywhere else except Mac and Linux)
- run
gyp -Icommon.gypi llnode.gyp - run
ninja -C out/Release ls -la out/Release- should have
llnode.so
Alright, I have pushed gyppies to the repo. So it should be possible to test this by just running npm test. Note that tests should be run from MSVS console on Windows, and the NINJA env variable should be set to the full path to ninja.exe.
@indutny, I've forked node-gyp to use gyp.js instead of gyp: https://github.com/pmed/node-gyp/tree/gyp.js
To build a native addon you just need a C++ compiler and Ninja installed. Visual C++ is used by default on Windows (my version of node-gyp tries to locate a VC++ version installed in the system).
And ninja executable should be in a PATH. Yoг can also set NINJA environment variable or set -ninja command line option for node-gyp to override the ninja location.
ps. I just saw you added platform.win.genEnvironment() that performs similar to findMSVS() function. Probably I would try to use your implementation.
@pmed Fantastic!
@pmed I have just pushed some fixes, and it appears that all npm tests pass on Windows, except the copy one.
@pmed One more thought: what do you think about contributing your patch back to node-gyp, with gyp.js used under a command-line flag or env variable?
See: https://github.com/nodejs/node-gyp/issues/960
Yes, command-line flag to switch between gyp and gyp.js would be great. And I'd like to use gyp.js by default some time later :smile:
The switch should be the same for the configure and build commands, so env.variable seems preferable.
@pmed I would go with both, probably? Is it too hard to do it in an existing architecture?
Thanks for looking into it.
@indutny yes, both, with comman-line option and env var. It shouldn't be hard to keep branches both for gyp and gyp.js in configure and build commands.
I added the gyp.js dependency into node-gyp/package.json, and use gyp.main() on configure step. Build function spawns ninja -C build/Release (or build/Debug). On Windows build function in node-gyp invokes vcvarsall.bat $target_arch before ninja.
I can try to make a PR into node-gyp.
Just run npm test on FreeBSD, everything appears to be working.
@indutny what would you consider "others"? sunos and aix-ppc?
I can try to compile on a raspberry-pi 2 running noobs, and on a MIPS32 OpenWRT machine
Well llnode was a wild goose chase, it doesn't compile cleanly on VS2015 with GYP... :(
But I was able to compile node.dll, anybody know who do you test it?
@refack yeah solaris, aix, everywhere where node works.
Cracking up my emulator...