Two major changes to c/c++ codegen
(1) explicit setter for each flag instead of a generic flag setter
void override_flag(std::string name, bool val) is replaced with
void <flag name>(bool val) for each flag name
This has several advantages:
(a) generated code is more c++ idomatic
(b) no longer need to create flag name string constants
(c) any typo in the code is caught early in the build time
(2) remove flag setter and flag override reset methods/functions when
generating code targets for production. If developers want to update
their main function to take command line arg for flag overrides, they
can use compile time macros to decide if the flag override code should
be included.
Bug: b/279483801
Test: atest aconfig.test
Change-Id: I6141f7f979b32fe0426154d578edeb997ae5ff7c
If adb is not found on PATH, which will silently fail and evaluate to
the empty string. This will cause the remaining arguments to be
interpreted as a command to run in the shell, which is generally
undesirable. (Consider, for example, "adb reboot" -> "reboot".)
Bug: 24473359
Test: Just run adb before lunch so it's not on PATH
Change-Id: I6b20722add6c67d1d2627f963dc66095502ab816
Signed-off-by: Saagar Jha <saagarjha@google.com>
c codegen can be done at the same time with cpp codegen, the idea is to
create a c compatible header that defines the flag apis, including flag
override apis for test. then in the corresponding cpp file, the
implementation simply calls into cpp api.
c header supports static method interface, and unit test override, but
it does not support injection pattern compared to cpp header
Bug: b/279483801
Test: atest aconfig.test
Change-Id: Ie62b76d6524e443de5d3c2f9000f7f66623ab571
* changes:
Do not install required modules from order-only deps
Install vintf_fragments/init_rc along with targets
Install vintf_fragments even when they are shared
Master branch has been renamed to main, the build id needs to reflect
this change.
Ignore-AOSP-First: Merge conflict resolutions
Bug: 290400015
Change-Id: I77884da7587fecae362f9c82fee9f45ff9878cc0
Merged-In: Ieb8b84d340f2308255ad2f23e5ac23635fb680de
Merged-In: Ife1860b73bc83d32a61817d5a9fe25c2deb1e37d
Merged-In: I132433a625848a210603a2e0ad102c12435b3ba4
Merged-In: I740ef3225c4c291ef7313d3ff1fe5d78389497f5
metalava no longer prints an ASCII banner, and has removed its
--no-banner argument. Update all call sites accordingly.
Test: presubmit
Bug: 286023667
Change-Id: I0159cad6571c62d672da5aeb3ff422abb97c7ac9
This change allows ARC to define ARC-specific system properties in
Android build without changing these property definitions for other
Android builds. Please see go/arc-sigprop-changes and
go/arc-android-sigprop-sync for additional details.
Bug: 195609932
Test: built bertha_x86_64 with forward declarations
Change-Id: I22bd9d60c2491506fe5c633dbbb9e7516f529b35
the sidecar issue in GSI was fixed.
Bug: 111538404
Test: presubmit
Change-Id: Ia48ce2e076edc4f13f85e58d9bbbe15b8e6a4438
Signed-off-by: Roman Kiryanov <rkir@google.com>
When a vintf_fragments or init_rc file is shared by two modules,
unintended modules are installed due to the shared file.
This was caused by add-all-target-to-target-required-modules-deps.
With the following definitions:
cc_binary {
name: "foo",
vintf_fragments: ["shared.xml"],
required: ["foo-req"],
}
cc_binary {
name: "bar",
vintf_fragments: ["shared.xml"],
}
When installing "bar", surprisingly, "foo-req" is installed due to the
link between "shared.xml" and "foo-req" added by
add-all-target-to-target-required-modules-deps.
To fix that, in this change, vintf_fragments and init_rc files are
marked as "order-only" deps. In
add-all-target-to-target-required-modules-deps, order-only deps are not
used to add links to "required" modules.
Now, with the same definitions, installing "bar" won't installs
"foo-req".
Bug: 198818343
Test: (see above)
Change-Id: I16be0dcb84564c559cb2f4223e2812321ee14729
Even though `m foo` installs vintf_fragments and init_rc files. There
was no direct dependency from the installed target to
vintf_fragments/init_rc files.
With the following:
cc_binary {
name: "foo",
vintf_fragments: ["foo.xml"]
}
`m out/target/product/vsoc_x86_64/system/bin/foo` didn't install
foo.xml.
This change adds the order-only deps from the target install to
vintf_fragments/init_fc files.
Bug: 198818343
Test: (see above)
Change-Id: I4656d43d15407a85fea7c95b22e4bbe19fb86aee
Python's zipfile doens't restore file permission by default, so we need
to manually restore permission.
Test: th
Bug: 290643514
Change-Id: I89c1e2ee178b534fa7e3f02afd04d170100d37e7
Move server_configurable_flags header include away from exported header,
instead put it in the flag provider headers. Otherwise, it can cause
compilation error if the source code who wants to use the generated c flag lib has
not added dependency on server_configurable_flags yet.
Bug: b/279483801
Test: atest aconfig.test
Change-Id: Ib75877ee88f995caf72b3fd2554c3da195032c14
Improve the error message returned when `aconfig dump` is fed multiple
declarations of the same flag: include the paths to the declaration
files.
In general all error messages from the protos::*::verify_* functions
should include paths to the offending files. This will be handled in a
follow-up CL.
Bug: 290300657
Test: atest aconfig.test
Test: manual: add duplicate flag and run `m all_aconfig_declarations`, inspect error message
Change-Id: I46dc23f7128dd5c68ced9f2e8518cfa89d81c2df
Vintf_fragments should be installed regardless when they are shared with
other modules or not.
cc_binary {
name: "foo",
vintf_fragments: ["shared.xml"],
}
cc_binary {
name: "bar",
vintf_fragments: ["shared.xml"],
}
Either `m bar` or `m foo` should install `shared.xml`.
Previously, only *new* vintf_fragments were installed, which means, one
of "foo" or "bar" didn't trigger the installation of "shared.xml".
Bug: 198818343
Test: (see above)
Change-Id: I52b831df046b585db41449f06a6f9c684d623468