| commit | 7a29da75fe8ff2fdd52d80e3ef79dc53e813f97c | [log] [tgz] |
|---|---|---|
| author | Rashid Zaman <rashidz@meta.com> | Fri Jun 07 11:23:40 2024 -0700 |
| committer | Rashid Zaman <rashidz@meta.com> | Fri Jun 07 14:46:16 2024 -0700 |
| tree | ed562655cf4df758afd79f0ea9c76cee407f8803 | |
| parent | d7c448f0f7fc5cf036b09ba52bbd785e9e4a1138 [diff] |
Fix expansion of _include_stack in _import-node During product configuration after a subgraph has been fully imported, i.e. a makefile and all makefiles it inherits from have been imported, the makefile representing the root node of this subgraph is meant to be removed from _include_stack in the _import-node macro via the call to the wordlist function. Instead, _include_stack is being cleared because the last argument to the wordlist function is escaped so when it is expanded before being passed to wordlist instead of expanding to the value of _include_stack the reference to _include_stack is unescaped. Fix this by removing the escaping of the variable reference. This issue has no impact on product configuration but the correct value of _include_stack helps when debugging product configuration because, for example, the dumpconfig generated by 'product-config' contains the value of _include_stack when nodes are imported. Bug: 345709996 Test: lunch aosp_cf_x86_64_phone-trunk_staging-userdebug && \ m nothing shows no change to build.ninja files Test: Run product-config and dumpconfig.csv shows correct include stack, e.g. for telephony_product.mk Change-Id: I5a9b22fffc147ceea3d49e298b1bbad45f71332c Signed-off-by: Rashid Zaman <rashidz@meta.com>
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.