[CMake] Find Vulkan on 32 bit builds

[Matthäus G. Chajdas]

Hi,

I've filed a bug report with LunarG. The issue is here:
https://vulkan.lunarg.com/issue/view/587509589ab0fa2af19621ca

In the meantime, I'll prepare an update which can handle /lib, /lib32
and adds the NO_DEFAULT_PATH in case of 32-bit Windows. Thanks for the
report!

Cheers,
  Matthäus

Am 10.01.2017 um 17:11 schrieb 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
> <mailto:cmake at anteru.net>> wrote:
> 
>     Hi,
> 
>     the problem here is that the Vulkan SDK helpfully adds
>     D:/VulkanSDK/1.0.37.0/Bin <http://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> <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>
>     >> <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
>