| commit | ee58f98cc0333be170c1c70f7b22eb61fcfd88cc | [log] [tgz] |
|---|---|---|
| author | Mårten Kongstad <amhk@google.com> | Fri Dec 15 08:31:51 2023 +0100 |
| committer | Mårten Kongstad <amhk@google.com> | Fri Dec 15 08:31:51 2023 +0100 |
| tree | 20e3bc1eed4236d4811a57c20fa5c05855537323 | |
| parent | 0c6a2fac775f179a533320dd521332760f998ea8 [diff] |
aconfig: support custom `dump format` specs
Teach `dump --format=<arg>` to format the output according to a
user-defined format string. The format string now accepts these
arguments:
- "protobuf": output all data as binary protobuf (as before)
- "textproto": output all data as text protobuf (as before)
- any other string: format according to the format spec, see below
Custom format spec: placeholders, enclosed in { and } and named after
the fields of ProtoParsedFlag, will be replaced by the actual values.
All other text is output verbatim. As an example:
- "{name}={state}" -> "enabled_ro=ENABLED"
Some fields support an alternative formatting via {<field>:<format>}. As
an example:
- "{name}={state:bool}" -> "enabled_ro=true"
Note that the text replacement does not support escaping { and }. This
means there is no way to print the string "{name}" without expanding it
to the actual flag's name. If needed this feature can be introduced in a
later CL.
For backwards compatibility, the following format strings have special
meaning and will produce an output identically to what it was before
this change:
- "text"
- "verbose"
- "bool"
A follow-up CL will add a new `dump --filter=` argument to limit which
parsed flags are included in the output.
Test: atest
Bug: b/315487153
Change-Id: If7c14b5fb3e7b41ea962425078bd04b4996318f4
This is the Makefile-based portion of the Android Build System.
For documentation on how to run a build, see Usage.txt
For a list of behavioral changes useful for Android.mk writers see Changes.md
For an outdated reference on Android.mk files, see build-system.html. Our Android.mk files look similar, but are entirely different from the Android.mk files used by the NDK build system. When searching for documentation elsewhere, ensure that it is for the platform build system -- most are not.
This Makefile-based system is in the process of being replaced with Soong, a new build system written in Go. During the transition, all of these makefiles are read by Kati, and generate a ninja file instead of being executed directly. That's combined with a ninja file read by Soong so that the build graph of the two systems can be combined and run as one.