Which is normally a good thing, but may exacerbate the issue described in the post where, by enforcing isolation, you end up cutting off the compiler from its caches and making the build slower.
I think the ideal solution would be for Bazel to somehow know about and integrate with LLVM’s CAS.
edit: although just figuring out how to do “explicit module builds” with Swift and Clang would probably get you most of the way.
Copying data into and out of a disk image is probably going to be much slower and involve just as many syscalls if not more compared to setting up a “symlink forest”.
As far as I can tell, the containerization framework seems like it’s for running Linux microvms, and doesn’t seem applicable to people trying to do macOS builds. I mean, if you just want to run Bazel in a Linux VM sure it will do fine, but you can already run Bazel in a Linux vm on your Mac with Docker.app. Maybe I missed something with the containerization docs but all I saw was EXT4, OCI Linux images, etc. no Mac thingies.
It's amazing that the conclusion it's that sandboxing would have had to use NFS, which is the approach that the vesta build system took 20 years earlier.
If you semi-trust your tool binaries enough not to do something silly like making syscalls directly, what about using the `LD_PRELOAD` equivalent to intercept `open` etc.? (Yes there's a long tail in that "etc.")
Or does using Go ruin everything again?
(Also it seems like it should in principle be possible to keep the symlink forest around and only delete other files)
Recently, macOS added a built-in FUSE-like API:
https://developer.apple.com/documentation/fskit
No idea what the performance is like.
However, over the last few years, Apple’s compilers have gotten even more enthusiastic than before about caching and “content addressable storage”:
https://llvm.org/devmtg/2024-10/slides/techtalk/Rastogi-Fine...
Which is normally a good thing, but may exacerbate the issue described in the post where, by enforcing isolation, you end up cutting off the compiler from its caches and making the build slower.
I think the ideal solution would be for Bazel to somehow know about and integrate with LLVM’s CAS.
edit: although just figuring out how to do “explicit module builds” with Swift and Clang would probably get you most of the way.
Seems like the new ASIF sparse image format will solve a lot of this, combined with their new containerization framework
https://eclecticlight.co/2025/06/12/macos-tahoe-brings-a-new...
Copying data into and out of a disk image is probably going to be much slower and involve just as many syscalls if not more compared to setting up a “symlink forest”.
As far as I can tell, the containerization framework seems like it’s for running Linux microvms, and doesn’t seem applicable to people trying to do macOS builds. I mean, if you just want to run Bazel in a Linux VM sure it will do fine, but you can already run Bazel in a Linux vm on your Mac with Docker.app. Maybe I missed something with the containerization docs but all I saw was EXT4, OCI Linux images, etc. no Mac thingies.
No idea if this will be of any help but with a little research found this on the docs https://developer.apple.com/documentation/virtualization/run...
there's also osx-kvm (non-apple) https://github.com/kholia/OSX-KVM
It's amazing that the conclusion it's that sandboxing would have had to use NFS, which is the approach that the vesta build system took 20 years earlier.
MacOS security has been making the platform unfriendly to developers in a similar way that Windows has since Vista.
Is Bazel using Landlock LSM yet for sandboxing? That's what I use with GNU Make and it's great. Nothing is faster.
The downside is it requires ~3 syscalls per file. If only I could send it all the mappings at once like you did.
If you semi-trust your tool binaries enough not to do something silly like making syscalls directly, what about using the `LD_PRELOAD` equivalent to intercept `open` etc.? (Yes there's a long tail in that "etc.")
Or does using Go ruin everything again?
(Also it seems like it should in principle be possible to keep the symlink forest around and only delete other files)
> Or does using Go ruin everything again?
Go isn't the only language ecosystem that likes to make statically linked binaries. Rust, OCaml and Haskell etc also prefer this.
Or am I missing something?
I think dynamic linking is mainly popular in the C (and perhaps C++) world? And I guess for commonly interpreted languages like Python, more or less.
Rust, OCaml and Haskell (ghc) do dynamically links against libc by default, though. What they "statically link" is their own libraries.
Yes.
Though you can also make them statically link against libc. I think that's more common, if you use musl?
In any case, I'm not sure all filesystem operations would come out of libc? (Especially if you use io_uring or other fancy io options.)