forked from DerpFest-AOSP/build
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Usage.txt
88 lines (69 loc) · 3.63 KB
/
Usage.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
Android build system usage:
m [-j] [<targets>] [<variable>=<value>...]
Ways to specify what to build:
The common way to specify what to build is to set that information in the
environment via:
# Set up the shell environment.
source build/envsetup.sh # Run "hmm" after sourcing for more info
# Select the device and variant to target. If no argument is given, it
# will list choices and prompt.
lunch [<product>-<variant>] # Selects the device and variant to target.
# Invoke the configured build.
m [<options>] [<targets>] [<variable>=<value>...]
<product> is the device that the created image is intended to be run on.
This is saved in the shell environment as $TARGET_PRODUCT by `lunch`.
<variant> is one of "user", "userdebug", or "eng", and controls the
amount of debugging to be added into the generated image.
This gets saved in the shell environment as $TARGET_BUILD_VARIANT by
`lunch`.
Each of <options>, <targets>, and <variable>=<value> is optional.
If no targets are specified, the build system will build the images
for the configured product and variant.
A target may be a file path. For example, out/host/linux-x86/bin/adb .
Note that when giving a relative file path as a target, that path is
interpreted relative to the root of the source tree (rather than relative
to the current working directory).
A target may also be any other target defined within a Makefile. Run
`m help` to view the names of some common targets.
To view the modules and targets defined in a particular directory, look for:
files named *.mk (most commonly Android.mk)
these files are defined in Make syntax
files named Android.bp
these files are defined in Blueprint syntax
During a build, a few log files are generated in ${OUT} (or ${DIST_DIR}/logs
for dist builds):
verbose.log.gz
every command run, along with its outputs. This is similar to the
previous `m showcommands` option.
error.log
list of actions that failed during the build, and their outputs.
soong.log
verbose debug information from soong_ui
For now, the full (extremely large) compiled list of targets can be found
(after running the build once), split among these two files:
${OUT}/build-<product>*.ninja
${OUT}/soong/build.ninja
If you find yourself interacting with these files, you are encouraged to
provide a more convenient tool for browsing targets, and to mention the
tool here.
Targets that adjust an existing build:
dist Copy into ${DIST_DIR} the portion of the build
that must be distributed
Flags
-j <N> Run <N> processes at once
-j Autodetect the number of processes to run at once,
and run that many
Variables
Variables can either be set in the surrounding shell environment or can be
passed as command-line arguments. For example:
export I_AM_A_SHELL_VAR=1
I_AM_ANOTHER_SHELL_VAR=2 m droid I_AM_A_MAKE_VAR=3
Here are some common variables and their meanings:
TARGET_PRODUCT The <product> to build # as described above
TARGET_BUILD_VARIANT The <variant> to build # as described above
DIST_DIR The directory in which to place the distribution
artifacts.
OUT_DIR The directory in which to place non-distribution
artifacts.
There is not yet known a convenient method by which to discover the full
list of supported variables. Please mention it here when there is.