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.
dangoodmanUT · 3h ago
Seems like the new ASIF sparse image format will solve a lot of this, combined with their new containerization framework
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.
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)
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.
https://eclecticlight.co/2025/06/12/macos-tahoe-brings-a-new...
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.
there's also osx-kvm (non-apple) https://github.com/kholia/OSX-KVM
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)