[CMake] Find Vulkan on 32 bit builds

[Saad Khattak]

That makes sense! Removing the variable from PATH does indeed fix the issue.

It is not a blocking issue for me.

I agree that this is a Vulkan packaging issue. However, since you are
looking for $ENV{VULKAN_SDK} in the find module and assuming it exists,
then it 'should' override the other path? I do see what you are saying in
that this now becomes a special case just because Vulkan SDK didn't package
the libs properly.

Thanks Matthäus and Andreas for your help!

On Tue, Jan 10, 2017 at 10:38 AM Matthäus G. Chajdas <cmake at anteru.net>
wrote:

Hi,

the problem here is that the Vulkan SDK helpfully adds
D:/VulkanSDK/1.0.37.0/Bin into PATH, while the Vulkan module dutifully
searches Bin on x64 and Bin32 on x86. However, because /Bin is in the
PATH, and because the libraries for both architectures are named the
same, it will pick up the one from /Bin first (as the search order for
find_library is system paths first, and PATHS/HINTS variable second).

There's a couple of ways to fix this; for instance, on Windows I could
use NO_DEFAULT_PATH on the find_library call and that would resolve the
issue. The main reason why I haven't done this yet is because I think
that's a packaging bug in the Vulkan SDK side which I was going to
report there (I want to ask them to move the libraries into a lib/
subfolder, and ideally use different names for different architectures.)

For now the easiest workaround is to remove the path to the Vulkan SDK
from PATH; and I'll try to report this with the LunarG SDK and see how
far I get there. If this doesn't work out, I'll guess I'll have to
special-case the find_library call to ignore default paths on Windows &
32-bit only.

If this is a blocker for you, please file an issue and I'll fix it on
the CMake end before even starting the discussion with LunarG.

Cheers,
  Matthäus

Am 08.01.2017 um 14:36 schrieb Andreas Naumann:
> Hello,
> Am 08.01.2017 um 07:22 schrieb Saad Khattak:
>> Hello,
>>
>> When I run "find_package(VULKAN)" in a CMakeLists for a Visual Studio
>> 2015 32-bit project, the ${Vulkan_LIBRARY} and ${Vulkan_LIBRARIES}
>> variables both point to the "Bin" folder for the Vulkan installation
>> instead of the "Bin32" folder.
>>
>> I looked at the FindVulkan.cmake module and even put MESSAGE(STATUS
>> ...) on the "elseif(CMAKE_SIZEOF_VOID_P EQUAL 4)" to see if I made a
>> mistake setting up. The message does indeed print confirming that my
>> pointer size is 4 and thus the current toolchain selected is 32 bit.
>>
>> What's perplexing is that when I do a MESSAGE(STATUS
>> ${Vulkan_LIBRARY}) the path is:
>>
>>
>> D:/VulkanSDK/1.0.37.0/Bin/vulkan-1.lib <http://1.0.37.0/Bin/vulkan-1.lib>
>>
>>
>> instead of
>>
>>
>> D:/VulkanSDK/1.0.37.0/Bin32/vulkan-1.lib
>> <http://1.0.37.0/Bin32/vulkan-1.lib>
>>
>>
>> It makes no sense. Line 47 of FindVulkan.cmake has Bin32. Why is CMake
>> ignoring 32?
>>
> You should think the other way around: Why should cmake look in a
> special directory, when it finds a library with an appropriate name
> before this one?
> This decision should be in the corresponding FindVulkan.cmake, i.e. the
> corresponding find_library call should be constrained to
> ${VULKAN_DIR}/Bin32 in the 32bit case.
>>
>>
>
> Regards,
> Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170110/e9df3d1e/attachment-0001.html>