| commit | 2363a2b162cac1946ae4a8677a473890da98dc10 | [log] [tgz] |
|---|---|---|
| author | Pirama Arumuga Nainar <pirama@google.com> | Tue Jul 02 14:55:35 2019 -0700 |
| committer | Oliver Nguyen <olivernguyen@google.com> | Mon Feb 03 19:03:45 2020 +0000 |
| tree | 8aedb626d7182504d7bb6ae0becf7633edc19bcb | |
| parent | baa54c6ed830a7cd1cb7fe5405c7a33b65c9a2cc [diff] |
Refactor libprofile-extras to be added as a whole static library Bug: http://b/134177005 Bug: http://b/116873221 Previously, the libprofile-extras dependency was added as a LateStaticLib and the constructor in this library was included during linking with the '-uinit_profile_extras' linker flag. This was done because at the deps() stage, the exact binaries that need coverage are not known (in fact the coverage-enabled variants are not created yet). This meant that for a link command, if one of the shared libraries already exported the constructor, the output of the link command did not load/link libprofile-extras. For other reasons, we now want to add more symbols to this library that need to be linked into all libraries and executables. To accomplish that, refactor the dependency handling so libprofile-extras can be added as a 'WholeStaticLib'. This is done by creating a new dependency type (with a coverageDepTag dependency tag) to add libprofile-extras as a dependency for all modules that can potentially link with coverage. During the flags() call, this dependency is moved as a WholeStaticLib dependency iff coverage is enabled in this link step. There are a few NFC changes as well: - deps() takes a DepsContext parameter. - flags() has an extra PathDeps parameter and return value. - add useSdk() helper to cc.Module. Test: Build with coverage and check that we can generate coverage using SIGUSR1 and the debug.coverage.flush sysprop. Change-Id: I7e7d8201956a150febbda5bb1794f8ece016db8b Merged-In: I7e7d8201956a150febbda5bb1794f8ece016db8b (cherry picked from commit 82fe59b65684462cb70a17145336e54c3fe5c79c)
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.
See Simple Build Configuration on source.android.com to read how Soong is configured for testing.
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/docs/soong_build.html.
Properties that take a list of files can also take glob patterns. Glob patterns can contain the normal Unix wildcard *, for example "*.java". Glob patterns can also contain a single ** wildcard as a path element, which will match zero or more path elements. For example, java/**/*.java will match java/Main.java and java/com/android/Main.java.
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)int)"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. Integers can be summed up 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 provides the ability for modules in different directories to specify the same name, as long as each module is declared within a separate namespace. A namespace can be declared like this:
soong_namespace {
imports: ["path/to/otherNamespace1", "path/to/otherNamespace2"],
}
Each Soong module is assigned a namespace based on its location in the tree. Each Soong module is considered to be in the namespace defined by the soong_namespace found in an Android.bp in the current directory or closest ancestor directory, unless no such soong_namespace module is found, in which case the module is considered to be in the implicit root namespace.
When Soong attempts to resolve dependency D declared my module M in namespace N which imports namespaces I1, I2, I3..., then if D is a fully-qualified name of the form "//namespace:module", only the specified namespace will be searched for the specified module name. Otherwise, Soong will first look for a module named D declared in namespace N. If that module does not exist, Soong will look for a module named D in namespaces I1, I2, I3... Lastly, Soong will look in the root namespace.
Until we have fully converted from Make to Soong, it will be necessary for the Make product config to specify a value of PRODUCT_SOONG_NAMESPACES. Its value should be a space-separated list of namespaces that Soong export to Make to be built by the m command. After we have fully converted from Make to Soong, the details of enabling namespaces could potentially change.
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.
To load Soong code in a Go-aware IDE, create a directory outside your android tree and then:
apt install bindfs export GOPATH=<path to the directory you created> build/soong/scripts/setup_go_workspace_for_soong.sh
This will bind mount the Soong source directories into the directory in the layout expected by the IDE.
Email android-building@googlegroups.com (external) for any questions, or see go/soong (internal).