LOCAL_USE_VNDK property refers if the module uses VNDK, and this
property is being used to check if the module is installed in vendor or
product. However, the term no longer makes sense with VNDK deprecation,
so it should be renamed. Similar to change in aosp/2897612, rename
LOCAL_USE_VNDK as LOCAL_IN_VENDOR or LOCAL_IN_PRODUCT.
Bug: 316829758
Test: AOSP CF build succeeded
Change-Id: I2da2e2027ccabbcfbb444abc6828addeb3b22e13
LOCAL_USE_VNDK property refers if the module uses VNDK, and this
property is being used to check if the module is installed in vendor or
product. However, the term no longer makes sense with VNDK deprecation,
so it should be renamed. Similar to change in aosp/2897612, rename
LOCAL_USE_VNDK as LOCAL_IN_VENDOR or LOCAL_IN_PRODUCT.
Bug: 316829758
Test: AOSP CF build succeeded
Change-Id: Icfd1707953eba2e29044468ab6728b39d7998048
My change to clean up obsolete copy headers would remove valid ones if
thhe LOCAL_COPY_HEADERS_TO path wasn't cleaned. I'm seeing this most
with values that just end in '/', so we end up with a '//' in the path,
which isn't textually equivalent, and we remove it.
Test: No longer seeing constant removals on internal products
Test: Set LOCAL_COPY_HEADERS_TO := ..
Test: Set LOCAL_COPY_HEADERS_TO := ../foo
Test: Set LOCAL_COPY_HEADERS_TO := /foo
Change-Id: Idbeeb207a2bb2a8da766473dbded877cec7c9cc1
There are no users left, so remove all of this.
Test: lunch aosp_arm-eng; m -j native
Test: build/tools/kati_all_products.sh on aosp and internal master
Change-Id: I32f5c8b470a43dd203d7e20c192167630e4e6888
Add BOARD_VNDK_VERSION and LOCAL_USE_VNDK to specify the version of the
VNDK that will be used globally, and whether to use the VNDK on a module
basis.
If the board is using the VNDK:
* LOCAL_COPY_HEADERS may only be used by modules defining LOCAL_USE_VNDK
* LOCAL_USE_VNDK modules will compile against the NDK headers and stub
libraries, but continue to use the platform libc++.
* LOCAL_USE_VNDK modules will not have the global includes like
system/core/include, but it will use device-specific kernel headers.
This change does not attempt to enforce any linking constraints, that
will come in a later patch.
Test: out/build-aosp_arm.ninja is identical before/after
Change-Id: Icce65d4974f085093d500b5b2516983788fe2905
Creates a build_system_stats.txt build artifact that contains statistics
on how many BUILD_* modules are defined in a build. Also writes out
information about the Soong module types sent from the Soong build.
Merged-In: Iaf0c7062f542dc6942b5349854f3d49267cac4a5
Change-Id: Iaf0c7062f542dc6942b5349854f3d49267cac4a5
When more than one makefile tries to copy a header to the same
destination, the warning is not clear, and hard to track down and assign
blame:
build/core/copy_headers.mk:15: warning: ignoring old commands for target `out/target/product/bullhead/obj/include/qcom/display/copybit.h'
With this change, the same behavior is kept, but the warning message is
more descriptive, and contains the offending Android.mk files:
build/core/Makefile:54: Duplicate header copy: out/target/product/bullhead/obj/include/qcom/display/copybit.h
build/core/Makefile:54: Defined in: hardware/qcom/display/msm8994/libcopybit/Android.mk hardware/qcom/display/msm8994/libcopybit/Android.mk
In this case, a $(CLEAR_VARS) is missing, so the same Android.mk file is
copying the same headers twice.
Bug: 27302058
Change-Id: Icf8f580ae71a78741db21c1d8f3213424459e637
If LOCAL_COPY_HEADERS_TO is not set, then the copy headers rule
target is set to out/target/product/../obj/include//header.h.
If another rule depends on the header without the //, it will
fail. Don't insert LOCAL_COPY_HEADERS_TO if it is blank.
Change-Id: Ideac7f8e01288ab5cca98645b307945d6ae9e97c
