Evaluating Bazel for building Firefox
blog.mozilla.org
blog.mozilla.org
But... if you climb that cliff, there are many rewards at the top. Like the article notes, you can reuse intermediate build artifacts between developers (because it's not possible for those artifacts to accidentally depend on developer-specific state), you can automatically parallelize (because the build system can tell declaratively which tasks do no depend on each other) and you can ask it interesting queries about the dependency graph. That sounds an awful lot like the runtime safety, performance, and static analysis static types give you.
The challenge is that for small programs, dynamic types are just easier to get going with. And every build script starts pretty small. So you have a plethora of simple, hackable build systems like make that work fine at first but then get more and more painful as the program grows. With software, there is at least some customer-visible pain that can enable you to justify a rewrite in a statically-typed language. But build infrastructure is always a hidden cost so it's really hard to get the resources to migrate to a different build language.
Maybe the lesson here is to bite the bullet and start with a hermetic build system at first.
cc_binary(
name = "app",
srcs = glob([ "*.hpp", "*.cpp" ]),
)
What do you mean?
That makes the graph more granular, e.g. if you just update the foo_main.cc you don't need to recompile the libraries. Or you can reuse bar_lib in a different binary.
It could, in theory.
Something to be aware of though is that Bazel does do some stupid things around this space. Like adding and removing files causes the build rule to change (if using a glob), which will proc a full rebuild of the library.
Are you sure this is required? I just tried with a test repo and Bazel only performed two actions after I updated foo_main.cpp (compile foo_main.cpp and link app.)
Foo.cc that depends on a a lib that's glob of a.h, b.h, c.h, d.h.
Foo.cc that depends on a_lib, b_lib, etc.
Modify a. In the first case, you'll have to recompile all of abcd. In the second, only a.
Note that adding and removing files (including through a glob) does always cause a rebuild though (because it's a change of the rule). This is a deficiency of bazel.
The other nice thing is you get dead code elimination for free.
The other place this is obvious is with tests. If you have a unit test per source, a change to any source will return all tests, splitting reduces this.
In other words, correctly using bazel gives you access to all the cool magic linkers do without having to do the work to implement it. And it adds value even for the ones that do (like C++, again: you'll run fewer tests).
Bazel has other tools for mitigating excessive test running (like test size/time descriptions and parallel test running) running too many tests has never been a problem I have encountered with even my dozen source file bazel libraries. Bazel also has smart test runners that can split up the tests in a test binary and run it in parallel, and I don't have to write a dozen lines for every C++ library.
I'm literally quoting Google's best practices for using bazel/blaze.
> Bazel has other tools for mitigating excessive test running (like test size/time descriptions and parallel test running) running too many tests has never been a problem I have encountered with even my dozen source file bazel libraries. Bazel also has smart test runners that can split up the tests in a test binary and run it in parallel, and I don't have to write a dozen lines for every C++ library.
Right, but here's the key thing: You're still running the test. My way, you just don't, and you lose nothing. You use less CPU, and less time.
> To use fine-grained dependencies to allow parallelism and incrementality.
> To keep dependencies well-encapsulated.
Like if I need 5 source files in a library to keep it well encapsulated, I'm doing that instead of making 5 libraries that are a rat's nest of inter-dependencies. And like the headers and repeating all the deps and specific command line arguments and so on would be unreadable.
> Like if I need 5 source files in a library to keep it well encapsulated, I'm doing that instead of making 5 libraries that are a rat's nest of inter-dependencies.
If you can't form your dependency tree into a DAG, you have larger design issues. This is yet another thing that bazel does a good job of uncovering. Libraries with cyclic dependencies aren't well encapsulated, and you should refactor to remove that.
I recognize that at a small scale this doesn't matter. But to be frank, there are parts of my job that I literally would be unable to accomplish if my coworkers did what you suggest.
One source file per library and one source file per object is an example of two policies that will conflict here (and I'm not trading code organization for build organization when I can just as easily use the features intended for this situation).
Meanwhile in the real world limiting the accessibility of header files not meant for public use prevents people from depending on things they shouldn't. Organizing libraries on abstraction boundaries regardless of code organization allows for more flexible organization of code (e.g. for readability and documentation). And so on.
This is why these feature exists and why Google projects like both Tensorflow and Skia don't follow the practices you are espousing here pathologically.
> But to be frank, there are parts of my job that I literally would be unable to accomplish if my coworkers did what you suggest.
Then you are incompetent and bad at your job. To be blunt I would recommend firing an engineer who pathologically misused a build tool in ways that encourage hard to read code and difficult to document code, while also making the build bloated and more complicated, all in the name of barely existent (and not at all relevant) performance improvements. And then said they couldn't do their job unless everyone conformed to that myopic build pattern.
It's like what, an extra 4 characters to get the list of code files in a library from a bazel query? What in the world could you possibly be doing that having to iterate over five files rather than one makes your job impossible.
> Tensorflow
Tensorflow is a perenial special case at Google. It's a great tool, but it's consistent disregard for internal development practices is costly. A cost I've had to pay personally before.
> Then you are incompetent and bad at your job
No, I just don't have the time or interest in reimplement language analysis tools when I don't need to.
And I don't have the time or interest to do it by hand when bazel already has that.
I mean not really, it's there enough that for all practical cases it exists effectively. I would be extremely surprised if that wasn't intentional when any other C++ build tool makes use of it extensively. I would have laughed bazel out of the room if it didn't make use of the fact that nearly all C++ compilers provide nicely formatted lists of the files a given file depends on.
Also it does work for tests perfectly fine.
> Especially when its easier to have tooling automatically manage build files for you, so you don't even have to do it by hand!
And this managing build file tooling is public? Because I am not at all aware of any automatic tools for bazel along those lines.
Which really is my frustration with bazel's google developers, their views are eternally myopic about how other people use their tools (e.g. using C++17 properly means re-writing the whole toolchain from scratch, have fun!). Yet those views are based on a closed and mostly unpublished ecosystem.
Let alone how terrible bazel does with dynamic libraries on windows (each cc_library then outputs a dll! yay!).
I don't think you realize how for anyone outside of Google bazel's tagline might as well be "The best terrible option".
Well sure, but build systems are hard, so that's still success in my book.
> And this managing build file tooling is public
No, but neither is the language analysis stuff you suggest I build instead, and claim I'm incompetent if I don't do.
Yes, I get it, you have complaints about the tool. That doesn't make what I'm saying less correct.
Sure, but suggesting the one true way to use the tool is a way that only works inside of google's ecosystem is myopic. I don't actually have complaints with bazel directly. I have issues with the googlers who continue to insist on using it on a way that only works inside of google to others and then act surprised when those people don't use it at all (or use it wildly incorrectly, or complain about the tool being poorly thought out, and so on).
What you suggest runs counter to many of the things that makes Bazel useful for anyone outside of google. I would swap back to CMAKE, by hand makefiles, hell I would use shell scripts, before I use it the way you suggest.
> No, but neither is the language analysis stuff you suggest I build instead
I didn't say you specifically should go build that. I was saying it's possible with bazel, any language that doesn't have those features is not a mature programming language, and if bazel is going to be used with that language it should probably make use of those features (or accept that it's not a mature language). If C++ and javascript can provide reflection than so can whatever bespoke language you are describing.
> and claim I'm incompetent if I don't do.
No I claimed you are incompetent because you claimed you couldn't do you job if a `.lib` file contained the output from more than one source file.
None of the work I do cares about the actual output artifacts. I care, almost exclusively, about the representation of the build graph itself. That work cannot be done if I don't have a build graph to analyze, which I don't if you do things like glob files together.
I've seen the simple act of untangling a globbed dependency to the various isolated files reduce the size of an output artifact by gigabytes.
> any language that doesn't have those features is not a mature programming language
You're calling literally every language that doesn't use the c-linker an immature language. Which may include c++17-with-modules, though I don't know that for certain.
> javascript
Javascript doesn't do what you're talking about though. At least not if you do any fancy precompilation/tree-shaking to your js at compile time. If all you're doing is copying the files, then sure, but as soon as you want to do useful things like, for example, run a typescript or closure analysis on your files, or generate js from typescript, or compile and minify your js, it will get a whole heck of a lot faster when you use more isolated build targets[0]. I know because our JS teams went to a lot of work to make js builds faster by taking advantage of this information.
And I don't take issue with what are obviously exceptional cases. What you are describing is not "I put togeather 5 related files" it's like "I globbed a file I wasn't supposed to".
> You're calling literally every language that doesn't use the c-linker an immature language. Which may include c++17-with-modules, though I don't know that for certain.
Uhhhh, I don't think you understand how the feature in question functions. I am simply talking about the -M option family of gcc (and similar commands for other compilers). Which provides a dependency tree for C++ files.
> At least not if you do any fancy precompilation/tree-shaking to your js at compile time.
I think it's actually the opposite. Those are the same tools that provide the reflection features in question (or some other AST parsing library)... then you write a two line lambda and feed that in over an interpreter. Boom list of files.
A lot of work goes into those 4 lines. This is evidenced by the simple question of, how do you set up a custom compiler for that code properly? The answer being a couple hundred lines of starlark code, for what in other build systems is effectively `CC=clang` (to be fair bazel allows this but does not support or encourage it, especially for anything besides toy builds).
I like Bazel (a lot!) but you are oversimplifying it here.
Provided the abstraction doesn't leak I really don't care, in the same way that end users of Microsoft Word don't care about the algorithms that kern their text, about how DirectWrite does subpixel rendering, or anything else.
Yes, it's all fiercely large and complex. The original user is pointing out that this is all hidden for simple projects, waiting in the wings for when you need it, and therefore doesn't matter.
The author I was replying points out how simple the syntax is. But that's missing the point. I provided a direct counter example:
Adding a new compiler to bazel is very complicated, and by new compiler I include something as simple as asserting "all of my C++ code is c++17" at a project level is (when done the correct way, and not one of the many hacky prone to failure ways) a 100+ line toolchain definition (because C++17 should be treated as an entirely new compiler from the perspective of bazel; treating it as a command line argument gets you in a bad place where you hit weird errors).
To draw an analogy, it's like saying that C++ code like:
some_matrix[i, j];
Hello world is simple in python, but it is still hard to get started writing real-time code in it even if hello world might be your first step.
$ cat Makefile
SRCS = foo.cpp bar.cpp baz.cpp
OBJS = $(SRCS:.cpp=.o)
PROG = app
EXT =
.PHONEY = all clean
all : $(PROG)
LDLIBS = $(OBJS)
$(PROG) : $(PROG:$(EXT)=.cc) $(OBJS)
clean :
rm -f $(PROG) $(OBJS)
$ make SRCS="`echo *.cpp`" clean all
rm -f app a.o b.o c.o
c++ -O2 -pipe -c a.cpp -o a.o
c++ -O2 -pipe -c b.cpp -o b.o
c++ -O2 -pipe -c c.cpp -o c.o
c++ -O2 -pipe app.cc a.o b.o c.o -o app
$The "beauty" of UNIX falls apart when trying to code across all of them.
For example, I cannot even remember if that Makefile would work 100% with a POSIX make.
Bazel isn't really nicer than the autotools when you need something complicated, if it even supports your platform. Here's a fun bazel bug report: https://github.com/bazelbuild/bazel/issues/4350#issuecomment...
I've always managed to avoid autotools unless it was used before with things like LDFLAGS='-lsocket -lns' make ...
* https://pubs.opengroup.org/onlinepubs/009695399/utilities/ma...
I _think_ that it's also broken, if I copy-paste it: your comment renders with spaces in the `clean :` stanza, but I believe make requires that to be a tab character?
While certainly simplistic, the bazel example shows one obscure feature (glob) that's both still fairly obvious, and unnecessary for a direct comparison to your example. The rest reads clean, and could be replicated/modified by someone with no clue fairly straightforwardly.
Don't get me wrong, bazel BUILD files will often hide a whole lot of magic. But the benefit is, for a newcomer the files they have to interact with on a day-to-day basis are friendly. Take tensorflow, one of the most complicated bazel repos I know - browse to a random leaf BUILD file and you'll probably find it quite readable. (I randomly clicked to https://github.com/tensorflow/tensorflow/blob/master/tensorf... , seems pretty clear - especially when I consider it's compiling kernels for GPUs, which I know nothing about.)
(Disclaimer: Googler, work closely with the bazel team. I like bazel.)
There's really not much cargo cult in my example. Everything would be in the most rudimentary doc or tutorial, certainly less reading than if you needed to use git for the first time.
And yes there is supposed to be a tab there, some copy-paste thing munged that.
The issue is that declarative build systems ALWAYS need an escape hatch for the exceptions--and the exceptions grow over time.
We've been here before. It was called Make. And then it was called Ant. And then Maven. And Google still built their own system. And they will build another again.
Nobody ever learns the lesson that a build system is a program--period. Sorry to burst your bubble: there will be circular dependencies--you will have to deal with it. There will be two different C compilers on two different architectures. You will have to deal with it. Libraries will be in the wrong place--you will have to deal with it. These libraries come from the system but these libraries come from an artifact--you will have to deal with it.
The only way to deal with it is to have a genuine programming language underneath.
> there will be circular dependencies--you will have to deal with it.
Add them both to the same compilation unit (cc_library, whatever). Or extract an ABI (e.g. Turbine) and compile against that.
> There will be two different C compilers on two different architectures. You will have to deal with it.
Poke around https://github.com/tensorflow/tensorflow/tree/master/third_p... . I see arm and x86, Windows and many variants of Linux, multiple versions of GCC, multiple versions of clang, multiple versions of cuda, python 2 and 3, and names I don't even recognize.
See also https://docs.bazel.build/versions/master/platforms-intro.htm....
> Libraries will be in the wrong place--you will have to deal with it.
Just write the path to the file, or write a build rule that makes it visible in a standard location, or make it part of the platform definition, or use something like https://docs.bazel.build/versions/master/be/workspace.html#b... to alias it into your workspace. (Not recommended, but supported.)
> Libraries will be in the wrong place--you will have to deal with it.
Platform-specific library paths are very common. These days it's probably better specified as part of your "platform", but https://docs.bazel.build/versions/master/be/functions.html#s... is a convenient way to make in-place selectors.
I won't pretend bazel can express _everything_, but there's little you can't hack in _somehow_ with sufficient motivation, and moving towards the bazel-recommended patterns brings growing peace-of-mind (and faster builds).
(Disclaimer: Googler, work closely with the bazel team. I like bazel).
Gradle is in use on a couple billion LoC and still sucks.
Bazel is like so many other tools--it works great if it owns everything, but when it has to cooperate, it falls down hard.
> The only way to deal with it is to have a genuine programming language underneath.
I disagree. Having a full programming language is great for the flexibility, but it causes lots of issues at scale. Restrictions in Bazel are critical for having a good performance on a large codebase, and for keeping the codebase maintainable.
With restrictions, we can provide strong guarantees (e.g. determinism, hermeticity), get better tooling, we can query the graph (without running the tools), we can track all accesses to files, etc. We can also make large-scale changes across the codebase.
Note also that Bazel language is not truly declarative, but it encourages a separation between the declarations (BUILD files) and the logic (bzl files).
Note the vocabulary--"restrictions". Your build system isn't solving a technical problem--it's solving a political one and trying to cloak it in technical terms.
We already have a problem. Your build system is now IN THE WAY if I'm not at scale. Any build system that makes people take notice of it is an a priori failure.
Thanks for posting this though. I've had a nagging irritation with so many of these "scalable" things, and this is the first time it has really coalesced that "scale" is almost always intertwined with "political control".
Note that Bazel builds still depend on the ambient system environment, like the compiler toolchain and system libraries, and it's possible to poison a shared build cache.
Shared caches are typically used with remote execution and CI servers, where the build environment is fully controlled.
The only way to poison the cache then is to break things at an OS level, which is highly unlikely.
Bazel does not really hash any of the system stuff -- like system headers, and system-provided .a and .so files (unless they are explicitly declared in WORKSPACE, but this is optional, and I have never seen this done for libc stuff fot example).
So all you need to do is to find one person who likes to mess with their system (for example, by installing latest versions of the libraries from random PPA's), and you'll end up with poisoned cache for everyone.
Because in general yes, I agree, it would be nice. Probably not in source control though -- putting in compilers + libraries will make checkouts very slow, git is not really designed for tens of gigabytes of stuff.
For bazel specifically, this is not really well supported. The default rules and all examples just trust system-installed compilers.
There is ongoing work on building in docker (with all the corresponding security issues), and there are rumors that Google internal version has some sort of magic, but this is not a "mainstream" configuration.
However, I think my point still stands -- this work looks pretty experimental. And most tutorials, including bazel's own [0], recommend using default configuration, which uses system compiler. And most of the examples I have seen also rely on system compiler.
[0] https://docs.bazel.build/versions/master/tutorial/cpp.html
This is because configuring a checked-in toolchain in Bazel needs tremendous effort and very specific knowledge about something 99.9% of developers does not know and DOES NOT WANT to know or spend their time on.
Build systems have the annoying property that they are ultimately highly declarative, but they need some pretty extreme scope to handle edge cases. Any C/C++ project is going to boil down to "compile these N source files, and link them into a library/executable", but the necessary build flags is going to come from several locations, there are multiple variations of build flags and compilers that need to be used at the same time, and there is going to be project-custom code to generate source files that involves potentially building the tools to generate the files as part of the build system. And mixed-language projects add more layers of pain.
However, there are at least two cases where you do not want real hermetic builds:
- in the case of open source software that needs to be packaged for distributions, vendoring all the dependencies is bad. As the name already says, distributions remix software components and thus might want to compile your software against a different version of a library than the particular version you pick. - for libraries, consumers use your library just as a component and might want to combine it with a specific version of other libraries, so vendoring also sucks.
Unfortunately, many declarative build systems make it hard to separate the "building a component" part from the "composing a product" part. I could find no way in Bazel to depend on system software (using for example pkgconfig).
In my opinion, build systems for open source software (as I mentioned, for companies Bazel makes sense since you often want to vendor all your deps anyway) need to have three aspects:
- build rules for just for this component - dependencies on other components/libraries - a method to lock down components/libraries to a specific version, creating an offical "product" with an official supported combination of all dependencies.
This still makes it possible for distributions to create their own "product", without having to rewrite most parts of the build system. At the same time, developers can work with the official library versions (for compat, maybe you should even have multiple "sets" of dependencies), so getting started is easy and you don't need to install lots of dependencies first before you can hack on the project.
Often, build systems do things that are nice for onboarding (like "build systems" that pull git repos of dependencies during build, in order to have a single command to build the product from scratch after checkout). But those things directly conflict with the needs of distributions. We need to separate the "instructions to build, supplying all deps externally explictly" (in the context of building a package for a distribution) from the "just build it from the command line on a dev machine" (here, dependencies should be implictly fetched automatically, to give a nice user experience).
[1] https://github.com/bazelbuild/bazel-gazelle/blob/master/inte...
Additionally, adding lots of additional customization on top of the build system itself defeats the purpose of using a popular system in the first place.
We had a particularly "fun" instance of this sort of Makefile weirdness back when we used Make for Rust... https://github.com/rust-lang/rust/blob/efec34a95a76212b2324d...
(Discussed on HN: https://news.ycombinator.com/item?id=13655081)
That might make the installed size large, but if it's isolated to Bazel, managed by Bazel, updated by Bazel, etc, then why does it matter whether it's a JVM, a Python binary, a JS VM, or anything else?
Wait, I think we're already in that era.
Oh well.
(Cue "but disk space is so cheap nowadays"...)
I don’t know how I feel about it myself.
Sure I'll bite. There are cases where this matters, absolutely, it would also matter if the difference was between 10MB and 10GB, but we're talking about a pretty small relative difference.
In return, you get the reliability of not having to worry about how your OS/configuration/other packages may interact with the software. In my opinion that's a huge productivity win, and also fits nicely with the fact that build systems should be thoroughly reproducible and do the same thing everywhere they run.
There are some good, niche, reasons for not bundling things like a JVM:
- If you're a strong free software advocate and need total control over the freedom in your dependencies. Debian do a lot of dependency unbundling for this reason. They're good at it, but it's not something most people care about or want to deal with the fallout of.
- Memory usage optimisation by sharing libraries in memory. This has a nice benefit for native code, but unlikely to do a lot for Java processes from what I understand. This likely _could_ have a significant benefit for the Electron ecosystem given that many people now run 2-3 Electron apps at a time.
These days getting dependencies and the right version of the runtime is considered a harder problem.
I personally feel like the world is wasting a huge amount of memory because of this, but have to agree that distributing apps is hard.
I still remember when dynamic linking was being introduced into OSes, Amiga libraries, Windows 3.x, the very first Linux kernel to support dynamic linking,....
When dynamic linking was finally possible, it was welcomed with pleasure, because not only it allowed to save disk and memory space, it also opened the door for extensibility via plugins, and dynamic behavior without restarts, instead slow IPC with one process per plugin/action.
Now thanks to missteps of glibc design and .so hell on Linux (even worse than on Windows due to all distributions), many devs embrace static linking as some golden solution.
See https://www.archive.ece.cmu.edu/~ganger/712.fall02/papers/p7... for the canonical paper on why it can be important to be able to recreate your build chain from scratch in a verified way.
Yes. It makes verifiability much harder.
E.g. Debian put a lot of work into making a more trustworthy build chain by introducing reproducible builds. There's no Bazel on Debian. And not on many other distros. Because getting Bazel to be built itself is a complexity nightmare. "Here, download this big blob where you have no idea how it's been built" doesn't exactly help.
But there's a simple fact: The more complex your build chain is the more difficult this is. And Java adds a whole bunch of complexity.
Read into the bug report to get an idea what a nightmarish task this is: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782654
In fact I think that bundling in a JVM that they know works in a particular way will likely improve the reproducibility of Bazel _setups_ and therefore builds that come out of Bazel, which is their aim.
env EXTRA_BAZEL_ARGS="--host_javabase=@local_jdk//:jdk" bash ./compile.sh.
To build the bazel binary in a reproducible way, also set SOURCE_DATE_EPOCH.
I build binaries locally to get something that's marginally more likely to work on my system, rather than because I believe I could somehow catch nasties buried in the source code even if I read every line. Too many years of seeing the ingenuity of IOCCC entries has taught me I won't succeed at that. :)
ChromeOS users don't compile their kernel.
Crostini is built with Rust and Go.
The Python ecosystem is much, much simpler than Java.
The Java ecosystem had painless build artifacts figured out way before Python did (ship this directory of .jar files vs... a requirements.txt?).
With a Java package, the final distro package will mostly be a single .jar file under /usr/share/java/, but getting to that .jar file from source is often a nightmare.
With a Python package, the final distro package will mostly be a sprawling directory under /usr/lib/python/site-packages/, but getting that directory from source is very rarely anything more than `./setup.py install --optimize=1`.
In my experience, large, complicated Python packages with C dependencies can be a huge nightmare just like large Java applications, and simple cases are simple in either case. With many dependencies, you need to unbundle every single one and package it separately, in either case.
Here's a simple, random Java package in Fedora:
https://src.fedoraproject.org/rpms/maven-antrun-plugin/blob/...
It only specifies its dependencies (which are individually packaged), and the %mvn_build and %mvn_install macros take care of everything else.
A slightly more complicated one, Guava:
https://src.fedoraproject.org/rpms/guava/blob/master/f/guava...
Elasticsearch, including unbundling patches:
https://src.fedoraproject.org/rpms/elasticsearch/blob/master...
Even if you write custom rules, you use the Python-like Skylark language and never interact with Java code.
[1]: https://github.com/bazelbuild/bazel/releases (the single-binary distribution is bazel-1.1.0-linux-x86_64, it's only 40MB).
OpenBSD and NetBSD have OpenJDK ports, but will probably require some patches.
The Haiku OS and Minix Firefox ports appear to be unmaintained.
Note that all of these are unofficial ports - all of Mozilla's supported platforms are also supported by Bazel.
(Disclaimer: Googler, work closely with the bazel team. I like bazel; I like BuildXL for expanding the space of build ideas, but have long-term concerns it settles in a local maxima that'll be hard to get out of).
[1] https://build2.org/build2/doc/build2-build-system-manual.xht...
My impression about the modules you linked to: A secondary feature because many C/C++ project need some additional scripting.
To rebuild, it will rerun the script, except that it knows which file it reads (and which mustn't exist), so if nothing is changed, it can skip that stage. There is no inherent difference between the compiler binary (say, /usr/bin/gcc), the system include (/usr/include/stdio.h), and the project source.
It makes for a super simple build script, which, after one successful build, gives tup enough information about dependencies and parallelization opportunities, while at the same time also tracks toolchains better than you can manually (does /usr/bin/gcc shell to /usr/bin/x86-gcc or /usr/bin/amd64-gcc ? did one of them change but not the other? was it the one we need? tup knows)
Unfortunately, it is nontrivial; it can uses ptrace or fuse to trace file access on Linux, IIRC has some other hack on Windows - and little to no support for other systems. Also, the overhead is in the single digit % last time I checked.
And in the case you don't want to, it is hardly any different from shipping a bunch of .so/.dll with the application.
I suppose I see the benefit of this setup if you keep many libraries and want to pin to the latest instead of, an explicit lib version. If you're in a multi-repo system you're probably not doing this but I can see how Bazel could actually make this possible.
Can someone shed some light on the CI story? Can Bazel do code deployment as well? Is that a smart thing to do with Bazel?
A pure Go codebase? Not worth it.
Personally, I use Bazel even for small projects as soon as they involve things like generated code or gRPC.
Yes, there are multiple rulesets for deployments, like rules_k8s[1] and rules_docker[2]. Of course, you can easily build your own custom deployment pipeline.
What do you use it with?