Juan Ramos

> As a sidenote, this `cmake` practice feels like a textbook monopolistic strategy. > Let's leverage a dominant position by adding requirements that only the dominant system naturally fulfills, >...

I believe this issue can be marked as resolved thanks to the added unofficial CMake support though. Since the original users closed their linked issue by using the `cmake_unofficial` after...

@asoffer feel free to close this issue. Or any other google test maintainer (@dinord / @derekmauro ). The original reason it was opened doesn't exist anymore.

What about when you have a complicated matrix for testing? We have a pretty involved matrix right now: ```yml - uses: hendrikmuhs/[email protected] with: key: ${{ matrix.config }}-${{ matrix.compiler }}-${{ matrix.os...

The vulkan validation layers currently uses `glslangConfig.cmake` right now: https://github.com/KhronosGroup/Vulkan-ValidationLayers/blob/9534456051ec513b731f22f56860368cef445a92/tests/CMakeLists.txt#L222 What support is missing exactly?

I think this issue can be closed as far as I can see. Although it would be good to add additional testing to ensure it doesn't accidentally break. But that's...

> What do you have in mind? Providing a CMakeLists.txt in the `native_app_glue` directory. It would look something like this: ```cmake project(ANDROID_NATIVE_APP_GLUE LANGUAGES C) add_library(android_native_app_glue STATIC) add_library(Android::NativeAppGlue ALIAS android_native_app_glue) target_include_directories(android_native_app_glue...

In case others see this thread. I'd advise using an object library. See this PR: https://github.com/KhronosGroup/Vulkan-ValidationLayers/pull/6343/files ``` add_library(android_glue OBJECT) target_include_directories(android_glue PUBLIC ${native_app_glue_dir}) target_sources(android_glue PRIVATE ${native_app_glue_dir}/android_native_app_glue.c ${native_app_glue_dir}/android_native_app_glue.h ) ``` This fixed...

Note. We are going to use current ToT (https://github.com/GPUOpen-LibrariesAndSDKs/VulkanMemoryAllocator/commit/0e89587db3ebee4d463f191bd296374c5fafc8ea) for the upcoming Vulkan SDK. Based on input from @adam-sawicki-a and @neurotok.

Note: Vulkan SDK 1.3.250 uses 0e89587db3ebee4d463f191bd296374c5fafc8ea instead of the 3.0.1 tag. If there is a new release of Vulkan-Memory-Allocator the gpuopen webpage should also be updated. It's currently listing 3.0.0...