Build node with GN

[nornagon]

Electron is starting to move its build system from GYP to GN to align with Chromium, which will make rolling Chromium substantially easier. However, we still have to shell out to GYP to build node.js, which is a lot of bridging code to maintain. I see there have been prior conversations about porting node's build system to GN from GYP, but they seem to have petered out without conclusion.

Would node.js be willing to accept patches to switch from GYP to GN?

NB, not suggesting that node does such a thing for 3rd-party native modules, just for node's own build.

[bnoordhuis]

That's already possible with ./configure --build-v8-with-gn.

edit: unless you mean porting all of the build system over. The answer is 'no' in that case.

[nornagon]

Sorry, I'm not referring to building v8 with GN, I'm referring to building node.js itself with GN.

[bnoordhuis]

Don't know if you saw my ninja edit but I think it's safe to say a switch to GN is not on the table.

[nornagon]

Ah, no, I missed it (would be awesome if GH would refresh edits live). Could you expand on why that's the case? (Is there perhaps a document describing blockers/reasoning that you could refer me to?)

[bnoordhuis]

See nodejs/TSC#464 which touches on that.

Speaking for myself, getting burned by a made-by-Google-for-Google build system once is enough; the next one should be one with broad community support.

[mhdawson]

Based on earlier discussion Google said they don't support other projects using GN and recommended against it.

[joyeecheung]

We are basically left with 3 choices after gyp:

• Blaze: Google uses that (Blaze) internally so they can support it, see RFC: Bazel for build system TSC#464 for a breakdown. It's a Java tool although it has distributions with JDK bundled. Would be the most difficult to transition the addon tooling into.
• GN: Currently used by V8 but people from the V8/Chromium/GN side all recommended against it in RFC: Bazel for build system TSC#464 due to support issues, it's also coupled in depot_tools and platform support is limited. There is already ./configure --build-v8-with-gn in our code base though. Future of addon tooling is bleak.
• CMake: We'll have to port the build files over and maintain them by ourselves (I guess we would need a revamp of [request] cmake build job build#1003) No additional dependencies other than cmake itself. If we want to transition the addon tooling in the future as well there is already cmake.js

See https://docs.google.com/document/d/101BP4BpZoP4tsMGo4j_MhoyLv169-2Oq_HeyWykCNGc/edit (OP of that TSC issue) for a breakdown

[bnoordhuis]

Also apropos cmake, I'm reasonably confident I can teach node-gyp to convert a binding.gyp to CMakeLists.txt on the fly and effectively phase out GYP.

[nornagon]

It's totally possible to use GN without depot_tools, see e.g. https://github.com/yue/build-gn. GN works fine on win/mac/linux, not sure about arm64 support but chromium itself builds against arm64: e.g.. @joyeecheung can you expand on what you mean by "platform support is limited"? Also not sure what you mean by "addon tooling".

[joyeecheung]

Regarding OP's request:

Would node.js be willing to accept patches to switch from GYP to GN?

I think patches for GN support can be accepted as long as they are not the default flow of building Node.js and are more in a situation similar to our Android builds (self-serve). If Electron needs GN to build Chromium then building Node.js with GN would be the most viable option for Electron, but it is not the case for Node.js itself and we have been explicitly advised against using it from the V8/Chromium/GN team.

[joyeecheung]

It's totally possible to use GN without depot_tools, see e.g. https://github.com/yue/build-gn.

Didn't know that, good to hear, thanks

GN works fine on win/mac/linux, not sure about arm64 support but chromium itself builds against arm64: e.g.. @joyeecheung can you expand on what you mean by "platform support is limited"?

https://docs.google.com/document/d/101BP4BpZoP4tsMGo4j_MhoyLv169-2Oq_HeyWykCNGc/edit touched on that a little bit (regarding FreeBSD and AIX). See supported platforms for the full list of platforms and tiers that we support.

Also not sure what you mean by "addon tooling".

I meant providing support for building 3rd-party native modules (as mentioned in the OP) with one of those tools and transitioning the ecosystem into it.

[bnoordhuis]

platform support is limited

Little to no freebsd/openbsd/etc. support. You're basically restricted to what Google is willing to support.

I think patches for GN support can be accepted

Supporting multiple build systems is already a hassle for libuv, and that's a fairly simple project to build.

I don't see it happening for Node.js. Without major ongoing maintenance it bitrots in no time.

[joyeecheung]

Supporting multiple build systems is already a hassle for libuv, and that's a fairly simple project to build.
I don't see it happening for Node.js. Without major ongoing maintenance it bitrots in no time.

I agree, but Idon't see any harm if we do not support GN, just allowing the build files to exist in the code base and get maintained by people who need them (e.g. Electron) though.