| commit | 269a8c78e7c33a0253073ea6b136583650ab7051 | [log] [tgz] |
|---|---|---|
| author | Dan Willemsen <dwillemsen@google.com> | Wed May 03 17:15:47 2017 -0700 |
| committer | Dan Willemsen <dwillemsen@google.com> | Fri May 05 16:25:40 2017 -0700 |
| tree | c4e28d19bdf0ad9cb07626231996ffa721d805b0 | |
| parent | 37a2aeb95a7a94a17059e85327796fe7418395a4 [diff] |
Add exec.Cmd wrapper for logging / sandboxing Wrap os/exec.Cmd to use our Context and Config interfaces for automatic logging and error handling. It also simplifies environment modification based on the Config's environment. This also adds sandboxing on Macs using sandbox-exec. A simple profile is provided that only logs on violations, though multiproduct_kati on AOSP has no violations. This isn't applied to ninja, only make / soong / kati to start with. I measured <5% time increase in reading all makefiles, and no noticable difference when kati doesn't regenerate. I'd like to spin up a process to dump violation logs into our log file, but the log reporting changed over the range of Mac versions that we support, so that's going to be more complicated. Opening Console.app works in all cases if you're local -- just search/filter for sandbox. Linux sandboxing will be implemented later -- the sandbox definition is opaque enough to support a different implementation. Test: multiproduct_kati on AOSP master on Mac Change-Id: I7046229333d0dcc8f426a493e0f7380828879f17
Soong is the replacement for the old Android make-based build system. It replaces Android.mk files with Android.bp files, which are JSON-like simple declarative descriptions of modules to build.
By design, Android.bp files are very simple. There are no conditionals or control flow statements - any complexity is handled in build logic written in Go. The syntax and semantics of Android.bp files are intentionally similar to Bazel BUILD files when possible.
A module in an Android.bp file starts with a module type, followed by a set of properties in name: value, format:
cc_binary {
name: "gzip",
srcs: ["src/test/minigzip.c"],
shared_libs: ["libz"],
stl: "none",
}
Every module must have a name property, and the value must be unique across all Android.bp files.
For a list of valid module types and their properties see $OUT_DIR/soong/.bootstrap/docs/soong_build.html.
An Android.bp file may contain top-level variable assignments:
gzip_srcs = ["src/test/minigzip.c"],
cc_binary {
name: "gzip",
srcs: gzip_srcs,
shared_libs: ["libz"],
stl: "none",
}
Variables are scoped to the remainder of the file they are declared in, as well as any child blueprint files. Variables are immutable with one exception - they can be appended to with a += assignment, but only before they have been referenced.
Android.bp files can contain C-style multiline /* */ and C++ style single-line // comments.
Variables and properties are strongly typed, variables dynamically based on the first assignment, and properties statically by the module type. The supported types are:
true or false)"string")["string1", "string2"]){key1: "value1", key2: ["value2"]})Maps may values of any type, including nested maps. Lists and maps may have trailing commas after the last value.
Strings, lists of strings, and maps can be appended using the + operator. Appending a map produces the union of keys in both maps, appending the values of any keys that are present in both maps.
A defaults module can be used to repeat the same properties in multiple modules. For example:
cc_defaults {
name: "gzip_defaults",
shared_libs: ["libz"],
stl: "none",
}
cc_binary {
name: "gzip",
defaults: ["gzip_defaults"],
srcs: ["src/test/minigzip.c"],
}
Soong includes a canonical formatter for blueprint files, similar to gofmt. To recursively reformat all Android.bp files in the current directory:
bpfmt -w .
The canonical format includes 4 space indents, newlines after every element of a multi-element list, and always includes a trailing comma in lists and maps.
Soong includes a tool perform a first pass at converting Android.mk files to Android.bp files:
androidmk Android.mk > Android.bp
The tool converts variables, modules, comments, and some conditionals, but any custom Makefile rules, complex conditionals or extra includes must be converted by hand.
host_supported: true. The androidmk converter will produce multiple conflicting modules, which must be resolved by hand to a single module with any differences inside target: { android: { }, host: { } } blocks.The build logic is written in Go using the blueprint framework. Build logic receives module definitions parsed into Go structures using reflection and produces build rules. The build rules are collected by blueprint and written to a ninja build file.
Soong deliberately does not support conditionals in Android.bp files. Instead, complexity in build rules that would require conditionals are handled in Go, where high level language features can be used and implicit dependencies introduced by conditionals can be tracked. Most conditionals are converted to a map property, where one of the values in the map will be selected and appended to the top level properties.
For example, to support architecture specific files:
cc_library {
...
srcs: ["generic.cpp"],
arch: {
arm: {
srcs: ["arm.cpp"],
},
x86: {
srcs: ["x86.cpp"],
},
},
}
See art/build/art.go or external/llvm/soong/llvm.go for examples of more complex conditionals on product variables or environment variables.
Email android-building@googlegroups.com (external) for any questions, or see go/soong (internal).