From bcc19508865dc94ea18ada22e53ae6a195c26ff8 Mon Sep 17 00:00:00 2001 From: Gurchetan Singh Date: Tue, 3 Sep 2024 15:31:46 -0700 Subject: [PATCH] vulkan: fix glibc AOSP build Certain AOSP targets feature a glibc or musl-based build, where (__ANDROID__) isn't defined, but: - ANDROID is defined - the relevant headers are present. For such builds, buffer_handle_t shouldn't be defined internally. Reviewed-by: Roman Stratiienko Part-of: --- include/vulkan/vk_android_native_buffer.h | 22 ++++++++++++++++++++-- 1 file changed, 20 insertions(+), 2 deletions(-) diff --git a/include/vulkan/vk_android_native_buffer.h b/include/vulkan/vk_android_native_buffer.h index 80e5d26c8ee..21f82ef57a2 100644 --- a/include/vulkan/vk_android_native_buffer.h +++ b/include/vulkan/vk_android_native_buffer.h @@ -1,5 +1,23 @@ -/* MESA: A hack to avoid #ifdefs in driver code. */ -#ifdef __ANDROID__ +/* + * MESA: buffer_handle_t is defined by all Mesa builds, even if + * one is building for a non-Android target. This avoids unnecessary + * conditionals in driver code. + * + * We don't need to define buffer_handle_t locally when (__ANDROID__) + * or ANDROID are set. Here's the distinction between the two: + * + * - AOSP always defines ANDROID, since it just means one is using the + * AOSP tree. It means the build environment is Android, roughly. + * - __ANDROID__ is defined by the toolchain. This typically means the + * build target is Android. + * + * If the build environment is Android, AOSP can provide common Android + * headers, such as . This allows one to build + * and test certain aspects of Android window system code, on the host + * system rather the build target. + */ + +#if defined(__ANDROID__) || defined(ANDROID) #include #if ANDROID_API_LEVEL < 28