commit | aa9f41a0085c38301e7e36a16e6ac8b7a21285a8 | [log] [tgz] |
---|---|---|
author | Spandan Das <spandandas@google.com> | Tue May 23 17:45:37 2023 +0000 |
committer | Cherrypicker Worker <android-build-cherrypicker-worker@google.com> | Thu Jun 08 04:14:55 2023 +0000 |
tree | 3ccb8f416eee59b867199788183298824349cf02 | |
parent | 240278dfc74c8bb18285f21ecb8609eea05e7857 [diff] |
Create default PRODUCT_INCLUDE_TAGS in product_config In the current setup in partner branch, we 1. Add blueprint_package_includes to prebuilts/module_sdk/* 2. Add the correct PRODUCT_INCLUDE_TAGS to partner_modules This means in those setups,none of the prebuilts are visible to aosp products since they they do not inherit partner_module makefiles. ``` e.g. prebuilts/module_sdk/art/current/Android.bp prebuilts/module_sdk/art/<go_specific>/current/Android.bp // aosp_arm cannot find either ``` To solve this, this CL creates a default inclusion tag for all products that do not set any PRODUCT_INCLUDE_TAGS explicitly. In the previous example, Soong analysis of aosp_* will use prebuilts/module_sdk/art/current/Android.bp. This should be a no-op for aosp and internal branches since none of the Android.bp files today contains blueprint_package_includes Test: m nothing for aosp_arm in the test branch of b/278604467#comment20 Test: m nothing for partner product that uses big android sdk Test: m nothing for partner product that uses go sdk Bug: 278604467 (cherry picked from https://android-review.googlesource.com/q/commit:2e69ea622877e7f88b82db4adbc284b9342f8c2c) Merged-In: I322b52c34ed339989207609dd0fd23c27ed1f697 Change-Id: I322b52c34ed339989207609dd0fd23c27ed1f697
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.