The chromite shell is intended to be the central clearing house for all build-related commands in Chromium OS. Before the chromite shell, developers would run a multitude of different shell scripts to perform build steps. With chromite, we want to have a centralized and testable system for building.
If you're in a hurry and just want to try some commands, you can do something like this:
That will build an x86-generic image. Type
The chromite shell consists of two parts: the chromite wrapper and the main chromite source code.
The chromite wrapper is installed with depot_tools, so you should already have it if you followed the Chromium OS Developer Guide. If you don't, try running any
The main chromite source code is part of the Chromium OS source code. That means it gets updated each time you do a
SIDE NOTE: The chromite source code is split up into two parts for a good reason: you want the
Running the chromite shell is simple. All you need to do is change into any directory in your source tree and run the
Every chromite command is a little different. However, they all have similar ways to specify parameters.
All chromite commands have one thing in common: they act upon a given chroot. If you’re already inside the chroot, that will always be the one acted on. If you’re not already inside the chroot, the default chroot is the one located in the
A "chroot" is described in a "chroot.spec". This describes how to create the chroot, how to enter it, and where it is located. Chroot specs are currently located in:
In order to (hopefully) be more user friendly and more discoverable, the chromite shell works interactively. That means that if you run
1. build - Build the chroot (if needed), the packages for a target, and the image.
2. clean - Clean out built packages for a target; if target=host, deletes chroot.
3. ebuild - Run ebuild.
4. emerge - Run emerge.
5. equery - Run equery.
6. portageq - Run portageq.
7. shell - Start a shell in the chroot.
8. workon - Run cros_workon.
For "full fledged" chromite commands, you can continue to use interactive mode to use chromite. These are commands like
If you choose a less full fledged command (one that’s just a wrapper of another script), interactive mode is less useful since we don’t have menus for everything. We’ll eventually fall back to asking for arguments. This is a bit ugly, and I’d love suggestions for what to do there... This will look like:
The chromite shell tries to speed developer efficiency by allowing you to partly specify command-line arguments. For commands, you can use any prefix of the command. For build specs, you can use any substring. So, for instance, you can do:
Since the above are unique, they run without any interaction from the user. If you specify things that are less than unique, you’ll get a menu with all possible completions. At the moment, this might not be too useful for commands (I don’t think people will run
Build specs work a lot like chroot specs. They can be found in the directory:
Whenever they are read, chromite also reads the
That means you can setup a new target that just uses defaults for everything by a simple command like this:
Eventually the format of build specs will change as the underlying commands for building change. The current format is hopefully described pretty well by the
If you looked closely at one of the above menus, you may have noticed a build target called
In general, commands should do something reasonable if the user chooses
You should feel free to tweak spec files to adjust how your own personal build happens. For instance:
Remember that the build specs will eventually change (as we migrate from being a simple wrapper of existing scripts in
Whenever we read a chroot spec, we first start off reading the
If you’re running chromite from outside the chroot, you can specify to use this alternate chroot by simply passing
Since the location of a chroot is (by default) the name of the spec file, your alternate chroot will be located in the directory
Here are a few sample commands, and what they do:
It seems like you could just have a bunch of scripts, instead of having one main script that calls others. Some of the reasons for the subcommand architecture are:
Perhaps it makes sense to think about other, similar instances. The
Since chromite is in python, we can write unit tests for it. With the unit tests, people should be able to feel more comfortable modifying existing code (instead of adding new scripts that do similar things to other scripts).