Repository navigation
Forming a GYP WG #110
Description
Activity
For the last couple of months I had a chance to; dig in the actual
GYPcode, help @indutny withgyp.js, and try to improve some of our.gypfiles. I've managed to push some changes upstream, and was able to getgyp.jsto buildnodeon windows.
I feel confident that with the help of the people of the org we can remove some of the obstaclesGYPhas put in our way./cc @nodejs/collaborators
What's the point of forking if complete rewrite is the goal?
Reacted by James M Snell and Ingvar Stepanyan- changed the title
[-]forking `GYP` and starting a `GYP` WG[/-][+]Forming a `GYP` WG[/+]on Apr 24, 2017 Ok, you're right, I changed the title.
ForkingGYPis an interim solution, since we still have multiple issues with it.P.S. we already have a fork. Actual two node-gyp and in node/tools (and a secret one in deps/npm).
But IMHO we don't manage them as well as we should.Agreed. I've stated elsewhere that when (not if) we take over maintenance of GYP, we should strip it down to its core. The cmake generator, xcode emulation, old Visual Studio support, etc. - those can all probably go.
I don't think a separate Working Group is necessary (or desirable) but a separate repo and a team would make sense.
Perhaps the working team can cover not just maintaining old gyp but also help push the
gyp.js"compatibility layer" as well as thinking about a format that might be more suitable thanGypfile?Reacted by Refael AckermannPerhaps the working team can cover not just maintaining old gyp but also help push the gyp.js "compatibility layer" as well as thinking about a format that might be more suitable than Gypfile?
Exactly!
Regarding a handoff, I got a general "we're open to it" from Chromium.
@bnoordhuis I assume if we do a handoff they would be against stripping it down ;)
Besides IMHOgyp.jsis a better (and python-free) option.
@indutny do you think it's time / willing to move gyp.js into the fold?Can't find the comment but remember how I said (half in jest, half serious) that node-sass and node-iconv are the litmus test for gyp.js? Until it is able to build most popular add-ons, including ones with complex build scripts, it won't be a replacement for the python version.
I remember that nodejs/node#7440 (comment)
To which I answered nodejs/node#7440 (comment)nodejs/node#7440 might be stage #2 of the WG
So Dirk Pranke who's in charge of
GYPsuggested that as a first step he will invite members of the org to become maintainers. Anyone who hasGYPexperience and wants to pitch in is invited to submit CLs (PRs in Chromium), and get fast tracked to become maintainer.
/cc @nodejs/build @nodejs/ctc
Past patchers @shigeki @jbergstroem @bnoordhuis @danbev
@joaocgreis can you think of anyone else?I said nothing about "fast tracked", but otherwise, sure we'd be happy to have folks contributing to GYP :).
This is likely something that we can make sure is discussed at the collaborator summit next week in Berlin and raised in various other discussions. One important thing to figure out, however, would be a clear delineation of what we actually need here.
Reacted by Gibson FahnestockThis issue has been inactive for a while and this repository is now obsolete. I'm going to close this, but feel free to open another issue in a relevant active repository (TSC perhaps?) and include a link back to this issue if this is a subject that should receive continued attention.
Reacted by Refael Ackermann
Follow up to #2
I suggest we form a GYP WG, and I volunteer to be the first member :).
The main goal of the WG will be to replace the
GYPtool thus removing thepythonrequirement from native modules (nodejs/node-gyp#629).As an interim solution I suggest we fork
GYPinto the org, and minimally maintain it in a centralized, and managed manor (in #2 @rvagg suggests "We could consider taking over GYP from Chromium, either officially or by forking it" I'll try to talk with them about a hand off. If anyone can help as well?).Reasoning
.gypfiles to scaffold our build system, and to build native add-ons.GYPtool (until @indutny's gyp.js matures 🤞)GYPhas been almost abandoned by chromium (at present there are 3 google stakeholders inGYP), pushing changes upstream is very slow.node-gyphas a test-suite but it mainly tests the JS wrapper aroundGYPso again sometimes regressions creep in (Weird error MSB6006: "cmd.exe" exited with code 1 on some packages node-gyp#1151).gypfiles. Institutional knowledge is highly fragmented in comments and issue threads...