RFC: Bazel for build system

[hashseed]

This is something I've been brooding over for a while. Elaborated here.

TL; DR: GN doesn't seem like a good option going forward. Maybe Bazel is a viable replacement for GYP? V8 already has, internally at Google, Bazel configs. I'm just suggesting this as option, not trying to convince anyone. The V8 team doesn't really have anything to gain from this.

[seishun]

So far I don't see any disadvantages of Bazel compared to GN besides the fact that Bazel requires a separate installation.

Node.js native modules require gyp. Migration away would be very difficult.

As far as I know, native modules don't require any special support from Node.js. That is, GYP files could be completely removed from Node.js, and they would still compile and work. Please correct me if I'm wrong.

JavaScript developers may have an irrational aversion against Java.

I don't think anyone would really care as long as they don't have to read or write Java code or install JVM.

[ljharb]

If JS devs have to rely on a Java tool, they would have to read or write Java in order to contribute for bugfixes etc; there is definitely an aversion in the community to that (“irrational” is a subjective enough term that perhaps it should be removed from the doc, to avoid debating how rational it might indeed be).

[hashseed]

Well in case of gyp that would be Python. In case of cmake and V8 that would be C++.

[ljharb]

To clarify, would be particularly compelling if the tool used were implemented in JS.

[hashseed]

Don't you then have to come up with a way to bootstrap?

[mcollina]

I’m -1 on moving to a Java tool. Python is part of all Linux distributions, so it is not a dependency we need to install in a lot of cases.

I’m +0 to be self hosted, but writing yet another build tool is not a priority. I would prefer to use an existing tool.

[hashseed]

I’m -1 on moving to a Java tool. Python is part of all Linux distributions, so it is not a dependency we need to install in a lot of cases.

The way I understand it Bazel comes packaged with JVM. The fact that it is written in Java is an implementation detail that is transparent to the user.

[mcollina]

From https://docs.bazel.build/versions/master/install-ubuntu.html Bazel seems more complicated than using/installing gyp.

[bnoordhuis]

GYP files could be completely removed from Node.js, and they would still compile and work. Please correct me if I'm wrong.

Add-ons depend on node's common.gypi: nodejs/node-gyp#1118

It's not unfixable but that will take time and effort.

[jin]

If JS devs have to rely on a Java tool, they would have to read or write Java in order to contribute for bugfixes etc; there is definitely an aversion in the community to that (“irrational” is a subjective enough term that perhaps it should be removed from the doc, to avoid debating how rational it might indeed be).

FWIW, the surface of Bazel that the JS devs will have to interact with is mostly the Skylark (Python-based) API extension that the rules are implemented in (like rules_node). The core incremental graph processing framework are mostly developed by the core Bazel developers and some rule writers.

[ljharb]

Sure. But the JS devs that use it might become those core developers given the chance - and having it be in JS maximizes that.

[hashseed]

That sounds a bit far-fetched though, and considering that there is no mature build system in JS at all right now, purposefully avoiding Java seems unreasonable.

[seishun]

Add-ons depend on node's common.gypi: nodejs/node-gyp#1118

It's not unfixable but that will take time and effort.

That doesn't seem to be a blocker.

1. It probably wouldn't take much effort to continue maintaining common.gypi.
2. Fixing Don't include common.gypi from node source tree node-gyp#1118 is a good idea whether or not Node.js switches to a different build system.

[mcollina]

👍 for fixing nodejs/node-gyp#1118 anyway.

Some notes:

1. Will the new build tool be pushed/made available to the ecosystem, or the ecosystem would stick being gyp-only? I don't think we can easily move the ecosystem, so we must keep maintaining gyp anyway and moving to another just for core increases the code we have to rely on.
2. Gyp is written in python, we maintain it in-tree and it is very easy to ship and distribute as part of our platform. I think these are good properties, and we should retain them. Asking developers to install XYZ separately will introduce a lot of friction in the ecosystem (and for core developers).

[hashseed]

If by ecosystem you mean node modules currently relying on gyp... I don't think that should be within scope of this discussion. Anything that replaces gyp in Node core will have the same effect.

[mhdawson]

I agree with @mcollina's comment:

Gyp is written in python, we maintain it in-tree and it is very easy to ship and distribute as part of our platform. I think these are good properties, and we should retain them. Asking developers to install XYZ separately will introduce a lot of friction in the ecosystem (and for core developers).

One of the great things about Node.js is how easy it is to build Node.js even if you have not done it before.

[rvagg]

I'd really like us to jump ship to a proven technology rather than something that could be just as much a dead end for us as GYP. I have the same reservations about GN. I'm not seeing anyone that's heard of Bazel before and I'd hate to see Node be a test subject for yet another build technology that may not last the distance.

Also, there's something pretty gross about telling people to install Java just to build a Node addon--I assume we're talking about a build tool that we'd end up encouraging userland to adopt as well. Speaking from experience managing the Java install across platforms in our Build infra for Jenkins, it's a pain in the neck.

@hashseed do you have any insight as to why Google has an aversion to CMake? It seems to me that CMake has the most longevity amongst the crowd of semi-intelligent config+build systems out there, and at this stage I'd be much more comfortable shifting to CMake as our default for this reason.

[hashseed]

I don't think Google has an aversion to cmake. Like I stated, the V8 team doesn't have any stakes in this. I'm merely introducing options that could make sense. Bazel requires less additional maintenance work, since V8 already has to maintain Bazel configs. With cmake, as with gyp, Node will need to maintain build configs everytime V8 is updated.

I wouldn't say Bazel is unproven technology, since most of Google is built with it, and is seeing increased public adoption. But I do get your point.

[gibfahn]

I wouldn't say Bazel is unproven technology, since most of Google is build with it, and is seeing increased public adoption. But I do get your point.

At least for me, the issue isn't that Bazel/GN/GYP aren't stable and powerful tools, it's that Google develop them to fix their current problems, and there's no guarantee they won't disappear. I'd rather maintain V8 build configs than risk having to maintain another build system in the future.

Another +1 for cmake.

[mhdawson]

+1 for cmake, and I think @bnoordhuis is already working on an proof of concept using cmake.

[ulfjack]

Full disclosure: I work on Bazel for Google.

I'd like to say a few things:

• I wouldn't say that Google has an aversion to cmake, but I don't think cmake will work for Google because large [1]. You could argue that Google could have made cmake work for it, and that might have been possible, but I think that ship has sailed now.
• Bazel is more than 10 years old, although we only open sourced it three years ago.
• Bazel is what Google is using for all of its development. A bunch of open source projects are using BUILD files (e.g., TensorFlow, V8, ABSL, Kubernetes, Angular, full list at [2]). To me, it seems unlikely that it'll go away any time soon.

Happy to answer any questions you may have.

[1] https://www.wired.com/2015/09/google-2-billion-lines-codeand-one-place/
[2] https://github.com/bazelbuild/bazel/wiki/Bazel-Users

[joyeecheung]

Looking at https://github.com/bazelbuild/bazel/releases it seems that Bazel only provides packaged installers for Linux, Windows and macOS. To install it on all the CI machines of our supported platforms we would still need to deal with JDK installation. Not sure if there is any conflict with our Jenkins installations?

[bnoordhuis]

Another thing is that the build tool is ideally something that you can just apt-get install, which is not the case with bazel.

[ulfjack]

I'm an engineer, not a salesperson. I freely admit that there are valid concerns about using Bazel as a build system. However, I'm concerned that the arguments brought up so far have been around what I would consider secondary issues. The most important things about a build system, in my opinion, are ease of use, fitness for the intended purpose, reliability, maintainability, correctness, and performance, not necessarily in that order.

It's true that you can't just "apt-get install bazel" right now (we do publish debian packages, but we're not in upstream), but I think that is missing the point. Despite its age, Bazel changes at a rate of several hundred changes per month, whereas the last two Debian stable releases were two years apart. In that case you have to wait for ~12 months on average to use new features. Do you really want to wait that long for a new build system release?

[seishun]

So far it seems Bazel isn't really a better choice than GN.

• Although Bazel has more public adoption than GN, it's still somewhat obscure.
• Bazel is difficult to install on a number of platforms, so we would probably end up bundling it or providing an installation script - just like with GN.
• Platform support in Bazel isn't any better than GN. According to the document, the only difference is that Bazel supports OpenBSD officially, but GN only unofficially.

[gibfahn]

So far it seems Bazel isn't really a better choice than GN.

From what you say, Bazel is the same or better in all three of those areas, it's more popular, has more official platform support, and is equally difficult to install.

Also I'd assume Google aren't going to be interested in supporting both long-term, so the chances are that GN will go the way of GYP. What would be the reason(s) to choose GN over Bazel?

[seishun]

What would be the reason(s) to choose GN over Bazel?

• If I understood correctly, Bazel isn't supported officially by V8, it's only for internal use. Also, Google uses Blaze internally, not Bazel, which might result in compatibility issues that we won't get help with.
• With Bazel, we'll have to figure out how to bundle it or provide an installation script. With GN, it's already done for us.

[ofrobots]

@seishun

So far it seems Bazel isn't really a better choice than GN.

FWIW, from my point of view, here are the differences between Bazel and GN:

• Google has been using the technology behind Bazel for around a decade. While Bazel is a Google initiated project, it is very much an open source project with a strong interest in bringing a fast and correct build system to the widest community of developers. IOW, this is a NOT a Google-only tool. Much like the Kubernetes project.
• GN is developed by the Chrome team for building Chrome. There isn't much interest by the Chrome team to make it usable in more scenarios or to be able to support other use cases.

If the comparison was only between these two tools, my recommendation would be strongly towards Bazel.

If I understood correctly, Bazel isn't supported officially by V8, it's only for internal use. Also, Google uses Blaze internally, not Bazel, which might result in compatibility issues that we won't get help with.

For the purposes of this discussion the differences between Bazel and Blaze are academic. Internally at Google we build V8 using Blaze. The V8 team supports this build configuration. I would expect that the V8 team could easily support a bazel build configuration, if necessary.

[seishun]

While Bazel is a Google initiated project, it is very much an open source project with a strong interest in bringing a fast and correct build system to the widest community of developers. IOW, this is a NOT a Google-only tool.

But what does it mean for Node.js in practical terms? It seems there is no practical difference in terms of platform support at least.

There isn't much interest by the Chrome team to make it usable in more scenarios or to be able to support other use cases.

Any use cases that are currently supported by GYP and Bazel, but not by GN?

---

By the way, I don't see any BUILD files in the V8 repo. Where can I find them?

[ofrobots]

Any use cases that are currently supported by GYP and Bazel, but not by GN?

My understanding, to put it bluntly, is that any use of GN in a project other than Chrome is unsupported.

By the way, I don't see any BUILD files in the V8 repo. Where can I find them?

Those are in our internal-only repo.

[seishun]

Those are in our internal-only repo.

So what's the plan, make them available if we agree to use Bazel? Do we get to experiment with them first?

My understanding, to put it bluntly, is that any use of GN in a project other than Chrome is unsupported.

As in, you won't get help with GN issues unless you're working on Chrome? But will you get help building V8 with Bazel if you don't work for Google?

[fhinkel]

Everything works fine with gyp and gn - at the moment. It might be, that we can use gyp for the next decades and never run into any problems, it might be, that there's a change in V8 in 6 month that just happens to make it impossible to build with gyp (unlikely).

The issue with gn is the long term outlook. It's build for and by Chrome, and afaik there's no guarantee that it will be supported in the future. Might be that Chrome ends up using it forever, might be that it's replaced next year. We're not looking at other build options because gyp or gn don't work but because we don't want ugly surprises in the future.

@seishun We (V8 team) would make our existing Bazel/Blaze configs and scripts that convert from gn to Bazel available and then they would be an additional build option. If the Node project officially adapts those or makes them the default all depends on how well they work or our users and ecosystem.

Unsupported means, that there's no guarantee that it will be supported in the future or that features don't get removed. Gn is open source, as in, you can use the code, but changes really depend on what's decided in Chromium whereas Bazel has a larger community and a different "goal", so you get all the help the community is willing and able to give.

[hashseed]

I have definitive statement from Chrome's GN team to not promote GN outside of Chrome. GN has been developed for Chrome and only Chrome. The team to support GN is very small and will not have the bandwidth to deal with other users.

I'm not entirely clear what you can expect wrt support from Bazel. But given the size of the Bazel team at Google and the fact that Google uses Blaze for everything internally, I'd say that it is here to stay. I will have a meeting with the Bazel team next week to explore options for Node.js. At this point, we have config files for V8 that should be easily adopted to Bazel. We don't have that for Node.js though.

[mhdawson]

Just looping back to the earlier discussion, what are the advantages of Bazel over cmake ? I guess it is because the v8 team is willing to maintain the Bazel configs ?

[hashseed]

Yes.

[seishun]

So far it sounds like the V8 team would be doing Node.js a special favor by providing us with support for building V8 with Bazel. Would it take more effort for the GN team to do us a favor by supporting the use of GN for Node.js instead? Considering there is extensive public documentation for GN, but Bazel build for V8 is effectively non-existent as of today, that doesn't seem to be the case. Or is the GN team completely separate from the V8 team, and the former just doesn't care about Node.js at all?

[jasnell]

This discussion appears to have stalled out. What is the next step?

[hashseed]

I might experiment with this some time. Not high priority for me though due to lots of other things going on.

Let's close this for now.