node-gyp
node-gyp copied to clipboard
nodejs
lib: add gyp.js support
See: #960
Added initial gyp.js support with --gypjs command line option.
Environment variable npm_config_gypjs also turns this option on.
Update configure and build usage strings depending on npm_config_gypjs
environment variable.
Set npm_config_gypjs env variable if --gypjs command-line option
was set to affect usage text for configure and build commands.
Update usage strings if --gypjs command-line option was supplied
Trying to load gyp.js module only if --gypjs command-line option was supplied.
cc @bnoordhuis
See #962
Hi Fedor @indutny
I glad to see that gyp.js feature is again moving forward 👍
Is it a rebased version of #962? If so, please note that PR is based on #964, and those two PRs probably should be closed after merging of this one.
@Fishrock123 it doesn't, default slow version of ninja is included. If it wouldn't be ninja, we'd have to use MSVS on Windows and make on Unixes, meaning that gyp.js will have to support two platform-specific generators instead of one cross-platform generator.
@indutny Oh, I was wondering why gyp.js required it when regular gyp didn't? Just maintenance cost of that?
@Fishrock123 yep, maintenance cost and a single solution for all platforms.
I've been thinking about this for some time and I've come to the conclusion that I'd rather not have node-gyp be in the business of generating platform- and tooling-specific build files.
That's what gyp.js does, it writes ninja files tailored for the platform and the compiler. As the upstream GYP project has demonstrated, keeping up with platforms and toolchains is a never-ending slog. It takes a lot of time and energy that is better spent elsewhere.
I'm hoping we can leverage an existing tool. My personal preference is cmake; it's stable and just works. Now to write a tool that translates GYP files to CMakeLists...
@indutny WDYT? Reasonable, unreasonable?
I've been using CMake.js for at least one project, and it works amazingly good! It only requires the cmake binary instead of relying on python which is a huge plus, I also prefer writing cmake files to gyp file to be honest...
https://github.com/cmake-js/cmake-js#why-cmake
I like gyp.js because of the vision being self-hosted with installing node.js. I'm totally fine if node.js itself uses something else; but a big community win would be having gyp.js Good Enough to build a majority of the node-gyp projects.
@bnoordhuis I'm fine with compiling GYP files to CMake in addons, but I have no idea if this is possible in general.
IMO, gyp.js + ninja.js is more viable and as @jbergstroem said is self-hosted.
With Node.js v4 reaching End Of Life in two weeks, gyp.js will be compatible with all supported Node versions! Maybe we could consider getting rid of the Python dependency. What is the status of this? Is there something I can do to help?
Of course. Anyone wants to pick it up from me? I haven't touched this code in months now.
I was thinking of picking this up again but only just realised that gyp.js requires ninja. I'm really not a fan of ninja simply because it's not commonly available. We're replacing a python dependency with a ninja dependency, that's arguably asking for more trouble because at least python is easy to fetch and install on every platform. We're going to have to get into the business of shipping ninja binaries like Chromium does. Maybe getting it beyond ninja is a reasonable task, but that's not a trivial amount of work.
@indutny how mature is that? If I ship a node-gyp with --gypjs support, what's your rough % guess for how much of the current ecosystem is going to be able to successfully build without requiring additional tools (python, ninja, just make and c++)? I'm wondering how much investment I'm going to have to make if I take this on.
This is a very good question. Most addons have very simple (if not identical) configuration. gyp.js should handle it well out of box.
The only limiting factor is "python" support: https://github.com/indutny/gyp.js#reduced-python . gyp.js emulates some trivial python commands, but of course cannot do full python support.
Since we're the only remaining major user of GYP I suspect we'll be able to move the ecosystem to not depend on sophisticated python syntax in their gyp files. Maybe we could even move it to support some JavaScript if people really need advanced stuff in there.