Google Git
Sign in
cos / mirrors / cros / chromiumos / bazel / refs/heads/stabilize-15563.B
commit19e1b07da0712ec99383f679069d63eff7011bfc[log] [tgz]
authorMaksim Ivanov <emaxx@chromium.org>Fri Jul 28 03:12:00 2023 +0000
committerChromeos LUCI <chromeos-scoped@luci-project-accounts.iam.gserviceaccount.com>Fri Jul 28 19:14:23 2023 +0000
treeb5de1e4dfbc897fb151dffe610ef088beac4dae7
parent3606d518db03446ecc03e5dcc0aee3d9ae4a339d [diff]
Fix ordering of eclass paths in Alchemy

Eclass search paths should be the inverse of the overlay's "masters"
order, to respect the intended semantics:

  "The masters list is in reverse priority order: later entries take
  precedence."

This commit fixes the divergence of the Alchemy's eclass inheritance
simulation from the real Portage's one. Note that it only makes
difference for same-named eclasses located in different places, which in
practice only means the fix is relevant for "toolchain-funcs.eclass"
(for the correct selection between its portage-stable and
chromiumos-overlay implementations).

BUG=b:293522502
TEST=add debug logging about inherited eclasses paths, build chromeos-base/chromeos-config-bsp, verify "chromiumos-overlay/eclass/toolchain-funcs.eclass" is used (and not "portage-stable/eclass/toolchain-funcs.eclass")

Change-Id: I6b33030fc1c3d66d592f51bff4c4155ecf790f47
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/bazel/+/4729041
Tested-by: Maksim Ivanov <emaxx@chromium.org>
Commit-Queue: Maksim Ivanov <emaxx@chromium.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
2 files changed
tree: b5de1e4dfbc897fb151dffe610ef088beac4dae7
  1. bash/
  2. bazelrcs/
  3. build_defs/
  4. cc/
  5. cros_pkg/
  6. go/
  7. images/
  8. module_extensions/
  9. platforms/
  10. portage/
  11. python/
  12. repo_defs/
  13. rust/
  14. transitions/
  15. workspace_root/
  16. .gitignore
  17. BUILD.bazel
  18. design.md
  19. DIR_METADATA
  20. go.mod
  21. go.sum
  22. link_files.py
  23. OWNERS
  24. OWNERS.clover
  25. PRESUBMIT.cfg
  26. README.md
README.md

ChromeOS Bazelification

This repository provides the implementation to build ChromeOS with Bazel.

Checking out

Building ChromeOS with Bazel is currently possible only on a special branch for Bazel development. Use the following repo command to check out the branch with a few additional repositories.

$ mkdir ~/chromiumos
$ cd ~/chromiumos
$ repo init -u https://chrome-internal.googlesource.com/chromeos/manifest-internal -b stabilize-15429.B -g default,bazel
$ repo sync -c -j 4
$ cd src

After checking out, you have to run the following command to create a few necessary symlinks. This is needed only on the first time.

$ bazel/link_files.py

Unless otherwise specified, examples in this doc assume that your current directory is ~/chromiumos/src.

Installing Bazel/Bazelisk

You need to use a certain version of Bazel for the build to succeed. The current supported Bazel version is denoted in ~/chromiumos/src/.bazelversion. The easiest way to use Bazel of the correct version is to use Bazelisk, which automatically downloads a Bazel binary according to .bazelversion.

To install Bazelisk, make sure you have Go toolchain installed, and run the following command:

$ GOBIN=$HOME/go/bin go install github.com/bazelbuild/bazelisk@latest

This command installs bazelisk at ~/go/bin/bazelisk. You‘ll also need to get Bazelisk onto your PATH, to be executed before any Bazel that’s already on your PATH, and we‘d like to invoke Bazelisk whenever we run bazel. Create a symlink to bazelisk in a directory that’ll be on your PATH before any other bazels, and name the link bazel. Example:

$ ln -s ~/go/bin/bazelisk ~/bin/bazel

Building packages

Now you're ready to start building. To build a single Portage package, e.g. sys-apps/attr:

$ BOARD=amd64-generic bazel build @portage//sys-apps/attr

To build all packages included in the ChromeOS base image:

$ BOARD=amd64-generic bazel build @portage//virtual/target-os:package_set

Inside CrOS SDK chroot

Inside CrOS SDK chroot (i.e. the build environment you enter with cros_sdk command), you should be able to run the same bazel build command.

You can also run build_packages --bazel --board=$BOARD to run build_packages with Bazel.

Building images

We have the following targets to build images:

  • //bazel/images:chromiumos_minimal_image: Minimal image that contains sys-apps/baselayout and sys-kernel/chromeos-kernel only.
  • //bazel/images:chromiumos_base_image: Base image.
  • //bazel/images:chromiumos_dev_image: Dev image.
  • //bazel/images:chromiumos_test_image: Test image.
For historical reasons, the output file name of the dev image is chromiumos_image.bin, not chromiumos_dev_image.bin.

As of June 2023, we primarily test our builds for amd64-generic and arm64-generic. Please file bugs if images don't build for these two boards. Other boards may or may not work (yet).

Building a ChromeOS image takes several hours. Most packages build in a few minutes, but there are several known heavy packages, such as chromeos-base/chromeos-chrome that takes 2-3 hours. You can inject prebuilt binary packages to bypass building those packages. See Injecting prebuilt binary packages for more details.

After building an image, you can use cros_vm command available in CrOS SDK to run a VM locally. Make sure to copy an image out from bazel-bin as it's not writable by default.

$ cp bazel-bin/bazel/images/chromiumos_base_image.bin /tmp/
$ chmod +w /tmp/chromiumos_base_image.bin
$ chromite/bin/cros_vm --start --board=amd64-generic --image-path /tmp/chromiumos_base_image.bin

You can use VNC viewer to view the VM.

$ vncviewer localhost:5900

You can also use cros_vm command to stop the VM.

$ chromite/bin/cros_vm --stop

Directory structure

  • portage/ ... for building Portage packages (aka Alchemy)
    • bin/ ... executables
    • common/ ... common Rust/Go libraries
    • build_defs/ ... build rule definitions in Starlark
    • repo_defs/ ... additional repository definitions
      • prebuilts/ ... defines prebuilt binaries
    • sdk/ ... defines the base SDK
    • tools/ ... misc small tools for development
  • images/ ... defines ChromeOS image targets
  • workspace_root/ ... contains various files to be symlinked to the workspace root, including WORKSPACE.bazel and BUILD.bazel

Misc Memo

Debugging a failing package

TODO: Fix the ability to get the build working directory. The method described here is no longer working.

If a package is failing to build, it‘s sometimes useful to view the package’s work directory. To do this run:

bazel build --sandbox_debug //your/ebuild

In the build output you will see a cd into the execroot:

cd /home/rrangel/.cache/bazel/_bazel_rrangel/ca19c0757f7accdebe9bbcbd2cb0838e/sandbox/linux-sandbox/842/execroot/__main__

This directory will contain a directory called build_package.*. It contains all the artifacts that were generated while building the package.

Build logs can be found in:

scratch/diff/build/arm64-generic/tmp/portage/logs/

The package work dir can be found in:

scratch/diff/build/<board>/tmp/portage/<category>/<package>-<version>

Debugging an ephemeral CrOS chroot

Sometimes you want to enter an ephemeral CrOS chroot where a package build is failing to inspect the environment interactively.

To enter an ephemeral CrOS chroot, run the following command:

$ BOARD=arm64-generic bazel run @portage//sys-apps/attr:debug -- --login=after

This command will give you an interactive shell after building a package. You can also specify other values to --login to choose the timing to enter an interactive console:

  • --login=before: before building the package
  • --login=after: after building the package
  • --login=after-fail: after failing to build the package

Injecting prebuilt binary packages

In the case your work is blocked by some package build failures, you can workaround them by injecting prebuilt binary packages via command line flags.

For every ebuild target under @portage//internal/packages/..., an associated string flag target is defined. You can set a gs:// URL of a prebuilt binary package to inject it.

For example, to inject a prebuilt binary packages for chromeos-chrome, you can set this option:

--@portage//internal/packages/stage1/target/board/chromiumos/chromeos-base/chromeos-chrome:114.0.5715.0_rc-r2_prebuilt=gs://chromeos-prebuilt/board/amd64-generic/postsubmit-R114-15427.0.0-49533-8783437624917045025/packages/chromeos-base/chromeos-chrome-114.0.5715.0_rc-r2.tbz2

You can run generate_chrome_prebuilt_config.py to generate the prebuilt config for the current version of chromeos-chrome.

% BOARD=amd64-generic portage/tools/generate_chrome_prebuilt_config.py

We have several named config groupings in prebuilts.bazelrc that define typical options to inject prebuilts. You can specify --config to use them.

  • --config=prebuilts/arm64-generic: Injects prebuilt binary packages needed to build arm64-generic images.

Extracting binary packages

In case you need to extract the contents of a binary package so you can easily inspect it, you can use the xpak split CLI.

bazel run //bazel/portage/bin/xpak:xpak -- split --extract libffi-3.1-r8.tbz2 libusb-0-r2.tbz2

Running tests on every local commit

If you'd like to run the tests every time you commit, add the following. You can skip it with git commit --no-verify.

cd ~/chromiumos/src/bazel
ln -s tools/run_tests.sh .git/hooks/pre-commit