commit | 5c80acaec733e0b7c43cb0584cdeb7cebc826aa9 | [log] [tgz] |
---|---|---|
author | Leopold Schabel <leo@nexantic.com> | Tue Oct 22 15:48:58 2019 +0200 |
committer | Leopold Schabel <leo@nexantic.com> | Tue Oct 22 15:48:58 2019 +0200 |
tree | f7db6de47e4ef38599da89dd4f1082c65569ca03 | |
parent | a71b5a4c36d5cae089666eaad57514c64baf6f24 [diff] |
Replace build system with a Bazel-based one This pins our external dependencies and introduces a mostly-hermetic build where all dependencies are explicitly declared and rebuilt if needed. Necessary prerequite for a proper CI workflow. Since Bazel can cache build artifacts, we can remove the hardcoded binary artifacts from the repo. As suggested in our discussions, the genrule that builds mkfs.xfs is basically doing the same as the previous build_artifacts.sh script (see source code comments for rationale). The main issue at this point is that the `build/linux_kernel:image` target rebuilds the kernel each time any of its inputs (like cmd/init) change. This is very hard to fix without compromising on hermeticity, porting kbuild to Bazel (no thanks) or injecting the initramfs into the kernel image in a separate rule (might just work, but the kernel build rule would either have custom code, or a massive set of outputs). Perhaps we could use a separate initramfs for development? Or deliberately poke holes into Bazel's sandbox to reuse kernel build? Test Plan: Run this in a fresh container with empty Bazel cache: bazelisk run scripts:launch ... and watch as Bazel rebuilds the world. X-Origin-Diff: phab/D197 GitOrigin-RevId: 21eea0e213a50e1c4ad25b2ac2bb87c53e36ea6d
The build uses a Fedora 30 base image with a set of dependencies.
Start container shell:
modprobe kvm podman build -t smalltown-builder . podman run -it --rm \ -v $(pwd):/work \ -v /dev/null:/work/.git \ -v /dev/null:/work/.idea \ -v /dev/null:/work/.arcconfig \ --device /dev/kvm \ --net=host \ smalltown-builder bash
Launch the VM:
bazelisk run scripts:launch
Exit qemu using the monitor console: Ctrl-A c quit
.
If your host is low on entropy, consider running rngd from rng-tools for development.