> We will have a window of at least three months between major (breaking) releases That seems... short
Well you can keep using the LTS releases. I can't find offhand how long "long" is. Presumably much longer than three months...
Bazel 1.0
161–170 of 204 posts
Re: Bazel 1.0
#162One of the major time savers of bazel is Remote Build Execution (RBE), which allows you to build modules in parallel in the cloud. So if you have 1000 CPUs, you can really just have a client do `bazel build -j 1000 //...` and you can get a huge speed-up. Remote (and local) builds all happen in a sandbox, so you don't have to worry about e.g. preparing a docker image with the worker / build slave environment. (You do,…
It isn't a native CMake solution, but the ROS (Robot Operating System) community has been dealing with the "build many CMake/python/other projects in parallel" problem for a long time, and has produced several tools and which address this.
The most recent effort is called colcon, which you can find here: https://colcon.readthedocs.io/en/released/
In the past (for example with catkin_tools, colcon's predecessor), the biggest barrier to use with conventional CMake packages has always been that they don't export dependency information in an easily machine-consumable way, so any regular CMake package brought into the workspace needed to have a package.xml file patched into it.
Colcon still has the ability to bring in extra metadata for things like ensuring environment variables and so on are set up correctly in the final workspace, but it's gotten a lot better at parsing/interpreting the native expressions of dependency and figuring out what to do. See for example how you build the multiple projects which make up the Gazebo simulator with colcon:
https://colcon.readthedocs.io/en/released/user/quick-start.h...
Of course, colcon also supports adding python/setuptools repos, and includes experimental support for bazel, gradle, cargo, and other buildsystems which can do an "install" step into a reasonably sane FHS tree. So in that way it's kind of like a cross-language supercharged virtualenv— it gives you the benefits of building multiple pieces of a system from source, semi-isolated, without the hassle of dealing with containers or VMs, where you also have to have all your tools in the isolated environment.
Re: Bazel 1.0
#163One of the major time savers of bazel is Remote Build Execution (RBE), which allows you to build modules in parallel in the cloud. So if you have 1000 CPUs, you can really just have a client do `bazel build -j 1000 //...` and you can get a huge speed-up. Remote (and local) builds all happen in a sandbox, so you don't have to worry about e.g. preparing a docker image with the worker / build slave environment. (You do,…
Used to be able to do something similar with Gentoo back in, like, 2002, I think. Distribute build jobs to multiple remote machines.
Re: Bazel 1.0
#164Earlier quoted context omitted.
It is successful enough that it has spawned a few clones—Buck, Pants, Please.build, and the thing that Chromium uses now. From what I can tell, before Bazel was open-source, everyone who left Google wanted to use Blaze badly enough to write their own version.
Not exactly ringing endorsements here. In large, most of the clones you are talking about are because this is a google pushed product. Chromium specifically is because google pushed it in. Regarding everyone at google wanting this, before entering industry, most folks never used a proper build system at all. It is not uncommon for college or earlier users to just use whatever their IDE does for them. Such that, yes,…
If this is because Google is pushing it, two things don’t make sense to me.
- Why would you clone an open-source product because Google is pushing it?
- Why are some of the clones older than Bazel? Bazel was open-sourced on Sep 8, 2015, going by first tag, and Buck two days later, so Buck must have been in development for a while. Pants was late 2014, and Please was early 2016.
> Regarding everyone at google wanting this, before entering industry, most folks never used a proper build system at all.
Could you give an example of a “proper build system”? Even if this applies to most folks, Google hires so many people, and there are enough old-timers there (hell, Stuart Feldman was a VP of Engineering) with industry experience.
One of the fundamental problems here is that for large enough projects or multi-project repos, it becomes burdensome just to load and evaluate all of the build rules. The inevitable result is that you have to split the build rules across multiple files for different parts of the tree, and people have been doing this for decades, this is nothing new. If you look at existing build systems, there are very precious few that will actually traverse the dependency graph well across these different subinstances. Recursive make sure doesn't do this very well (see Recursive Make Considered Harmful, 1997). IDEs usually do a good job of this but they only solve a narrow set of problems to begin with.
Once you start with the goal of solving this particular problem well, my claim is that your solution will have some surprising similarities to Bazel (unless you ditch some other objective like incremental builds).
Re: Bazel 1.0
#165Earlier quoted context omitted.
For packages, you download things by specifying an archive (zip file, git repo, etc), and a SHA256 hash. Think of it as extremely-precise version pinning. You can also refer to other Bazel projects and use their internal rules if permitted. The biggest advantages of Bazel over something like CMake are: 1) It is very general, so you can easily express dependencies of this sort: - concat three text files, then - run th…
(1) sounds like table stakes for any build system - `make` has done all that for decades
Make cannot guarantee that this is the case. Bazel sandboxs all builds and hides them from non-reproducable things (internet, files they shouldn't get to see, etc) to make it "impossible" for you to have a build that isn't specified correctly in the DAG
Re: Bazel 1.0
#166Earlier quoted context omitted.
Java Hello World takes 0.132s on my Macbook pro. If I turn on -Xshare:on to use class data sharing, then it drops to 0.119s. Ergo, Java startup time is non-factor. Graal could make this even quicker, for example, a GraalVM AOT helloworld can be reduced to .008s startup, see https://github.com/graalvm/graalvm-demos/tree/master/java-ko... for example. "time bazel" returns 0.098s Running a null build took 0.84s, but Baz…
> "time bazel" returns 0.098s For me it returns 1.6s on first run, .9s on second (bazel 0.29.1).
$ time (echo 'quit()' | python)
real 0m0.025s
user 0m0.000s
sys 0m0.031s
$ time (echo 'quit()' | python3)
real 0m0.036s
user 0m0.031s
sys 0m0.016s
Re: Bazel 1.0
#167Earlier quoted context omitted.
Not exactly ringing endorsements here. In large, most of the clones you are talking about are because this is a google pushed product. Chromium specifically is because google pushed it in. Regarding everyone at google wanting this, before entering industry, most folks never used a proper build system at all. It is not uncommon for college or earlier users to just use whatever their IDE does for them. Such that, yes,…
If this is because Google is pushing it, two things don’t make sense to me. - Why would you clone an open-source product because Google is pushing it? - Why are some of the clones older than Bazel? Bazel was open-sourced on Sep 8, 2015, going by first tag, and Buck two days later, so Buck must have been in development for a while. Pants was late 2014, and Please was early 2016. > Regarding everyone at google wanting…
First there was blaze, the closed-source google internal build tool.
People left google and wanted to copy blaze, hence pants and buck were created.
Then google released bazel, an open source version of blaze.
Re: Bazel 1.0
#168Earlier quoted context omitted.
We didn't have Bazel on ARM for NixOS because we can't bootstrap openJDK on ARM. There's no source code for a JVM that compiles on ARM afaik. Though in theory we could package binary blobs from oracle and bootstrap JDK and Bazel from there, it means now our trust path for your critical build tool has a random Oracle blob in its trust path there that is extremely hard to get rid off. Build systems should be easy to bu…
Google builds stuff for themselves and then dumps it for extra reputation points on the dev community. The part where this starts to suck is when their tools become pseudo-standards and everyone has to live with their decisions.
I'm biased because I work at Google on an open source project, but the complaint here seems to be:
1. A corporation spends significant resources developing a project.
2. Then they release to allow the public to use it at zero cost. Often they even invest in supporting that external use.
3. The project provides enough value to so many users (who chose it of their own volition) that it becomes nearly a standard.
And this is somehow a bad thing?
Re: Bazel 1.0
#169How is it different than Buck or Pants? What makes Bazel better than them? If I already use Buck or Pants what benefit would I get if I move to Bazel?
Bazel is more popular, with a larger community and better language support than the other two. It seems that Bazel has "won".
Re: Bazel 1.0
#170Earlier quoted context omitted.
This is actually called the "throw over the fence" open source development model. Most Google projects are like this, including Android which is the main reason why vendors struggle with os updates.
AFAICT Android is a pain to upgrade because of custom closed-source drivers and lack of ABI stability in Linux, so you need to recompile a driver for a newer kernel. Android is not a Google's internal product, unlike Bazel.
This.
Treble is suppose be their ABI