Repository navigation
RFC: Bazel for build system #464
Description
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.
Activity
seishun commentedon Jan 7, 2018
So far I don't see any disadvantages of Bazel compared to GN besides the fact that Bazel requires a separate installation.
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.
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 commentedon Jan 7, 2018
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 commentedon Jan 7, 2018
Well in case of gyp that would be Python. In case of cmake and V8 that would be C++.
ljharb commentedon Jan 7, 2018
To clarify, would be particularly compelling if the tool used were implemented in JS.
hashseed commentedon Jan 7, 2018
Don't you then have to come up with a way to bootstrap?
mcollina commentedon Jan 7, 2018
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 commentedon Jan 7, 2018
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 commentedon Jan 7, 2018
From https://docs.bazel.build/versions/master/install-ubuntu.html Bazel seems more complicated than using/installing gyp.
bnoordhuis commentedon Jan 7, 2018
Add-ons depend on node's common.gypi: nodejs/node-gyp#1118
It's not unfixable but that will take time and effort.
jin commentedon Jan 8, 2018
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 commentedon Jan 8, 2018
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 commentedon Jan 8, 2018
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 commentedon Jan 8, 2018
That doesn't seem to be a blocker.
common.gypi.mcollina commentedon Jan 8, 2018
👍 for fixing nodejs/node-gyp#1118 anyway.
Some notes:
hashseed commentedon Jan 8, 2018
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.
9 remaining items
seishun commentedon Jan 12, 2018
So far it seems Bazel isn't really a better choice than GN.
gibfahn commentedon Jan 13, 2018
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 commentedon Jan 13, 2018
ofrobots commentedon Jan 16, 2018
@seishun
FWIW, from my point of view, here are the differences between Bazel and GN:
If the comparison was only between these two tools, my recommendation would be strongly towards Bazel.
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 commentedon Jan 16, 2018
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.
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 commentedon Jan 16, 2018
My understanding, to put it bluntly, is that any use of GN in a project other than Chrome is unsupported.
Those are in our internal-only repo.
seishun commentedon Jan 16, 2018
So what's the plan, make them available if we agree to use Bazel? Do we get to experiment with them first?
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 commentedon Jan 17, 2018
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 commentedon Jan 17, 2018
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 commentedon Jan 17, 2018
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 commentedon Jan 17, 2018
Yes.
seishun commentedon Jan 18, 2018
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 commentedon Feb 17, 2018
This discussion appears to have stalled out. What is the next step?
hashseed commentedon Feb 17, 2018
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.