Catapult is intended to be a set of performance tools, mostly based on tracing, for developers of Chromium and other software to analyze that software’s performance. It has a lot of supporting libraries and tooling to make this happen. We’d like to create an organizational structure that makes it easy to find the performance tooling developers want, and hard to accidentally depend on something internal. Furthermore, we’d like to make it easy for code in catapult to eventually grow to its own repo, when possible. To that end, we use these guidelines to decide where code should live.
toplevel
.catapult_build
.common/
We have some rules on directory structure to add consistency and avoid overloaded python imports.
x
is a toplevel directory, x/__init__.py
does not exist. Directories in common/
do not have this restriction.common
should centralize all their path computation and sys.path manipulation in their master init file (example).x/x_build/
tracing/tracing/base/math.html
is /tracing/base/math.html
for an HTML import, and tracing/tracing/base/math.py
is tracing.base.math
in python.x/bin
. bin/
must not be a module, e.g. contain __init__.py
, as such a name would create namespace conflicts. Executable files should not have a .py
extension.$catapult/bin/run_dev_server
; and have per-project bin/run_dev_server_tests
scripts.$catpult/catapult_build
instead of $catapult/build
.Catapult supports two types of tests:
bin/run_dev_server_tests
python executable like this.bin/run_py_tests
executable like this.Both types of tests should be added to the configuration in build_steps.py. Please see the comments in that file for full documentation on specifying test commands, arguments, disabled platforms, and required environment variables.