<div dir="ltr">That makes sense! Removing the variable from PATH does indeed fix the issue.<div><br></div><div>It is not a blocking issue for me.  <br><br>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.<div><br>Thanks Matthäus and Andreas for your help!<div><br class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">On Tue, Jan 10, 2017 at 10:38 AM Matthäus G. Chajdas <<a href="mailto:cmake@anteru.net" class="gmail_msg" target="_blank">cmake@anteru.net</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br class="gmail_msg">
<br class="gmail_msg">
the problem here is that the Vulkan SDK helpfully adds<br class="gmail_msg">
D:/VulkanSDK/<a href="http://1.0.37.0/Bin" rel="noreferrer" class="gmail_msg" target="_blank">1.0.37.0/Bin</a> into PATH, while the Vulkan module dutifully<br class="gmail_msg">
searches Bin on x64 and Bin32 on x86. However, because /Bin is in the<br class="gmail_msg">
PATH, and because the libraries for both architectures are named the<br class="gmail_msg">
same, it will pick up the one from /Bin first (as the search order for<br class="gmail_msg">
find_library is system paths first, and PATHS/HINTS variable second).<br class="gmail_msg">
<br class="gmail_msg">
There's a couple of ways to fix this; for instance, on Windows I could<br class="gmail_msg">
use NO_DEFAULT_PATH on the find_library call and that would resolve the<br class="gmail_msg">
issue. The main reason why I haven't done this yet is because I think<br class="gmail_msg">
that's a packaging bug in the Vulkan SDK side which I was going to<br class="gmail_msg">
report there (I want to ask them to move the libraries into a lib/<br class="gmail_msg">
subfolder, and ideally use different names for different architectures.)<br class="gmail_msg">
<br class="gmail_msg">
For now the easiest workaround is to remove the path to the Vulkan SDK<br class="gmail_msg">
from PATH; and I'll try to report this with the LunarG SDK and see how<br class="gmail_msg">
far I get there. If this doesn't work out, I'll guess I'll have to<br class="gmail_msg">
special-case the find_library call to ignore default paths on Windows &<br class="gmail_msg">
32-bit only.<br class="gmail_msg">
<br class="gmail_msg">
If this is a blocker for you, please file an issue and I'll fix it on<br class="gmail_msg">
the CMake end before even starting the discussion with LunarG.<br class="gmail_msg">
<br class="gmail_msg">
Cheers,<br class="gmail_msg">
  Matthäus<br class="gmail_msg">
<br class="gmail_msg">
Am 08.01.2017 um 14:36 schrieb Andreas Naumann:<br class="gmail_msg">
> Hello,<br class="gmail_msg">
> Am 08.01.2017 um 07:22 schrieb Saad Khattak:<br class="gmail_msg">
>> Hello,<br class="gmail_msg">
>><br class="gmail_msg">
>> When I run "find_package(VULKAN)" in a CMakeLists for a Visual Studio<br class="gmail_msg">
>> 2015 32-bit project, the ${Vulkan_LIBRARY} and ${Vulkan_LIBRARIES}<br class="gmail_msg">
>> variables both point to the "Bin" folder for the Vulkan installation<br class="gmail_msg">
>> instead of the "Bin32" folder.<br class="gmail_msg">
>><br class="gmail_msg">
>> I looked at the FindVulkan.cmake module and even put MESSAGE(STATUS<br class="gmail_msg">
>> ...) on the "elseif(CMAKE_SIZEOF_VOID_P EQUAL 4)" to see if I made a<br class="gmail_msg">
>> mistake setting up. The message does indeed print confirming that my<br class="gmail_msg">
>> pointer size is 4 and thus the current toolchain selected is 32 bit.<br class="gmail_msg">
>><br class="gmail_msg">
>> What's perplexing is that when I do a MESSAGE(STATUS<br class="gmail_msg">
>> ${Vulkan_LIBRARY}) the path is:<br class="gmail_msg">
>><br class="gmail_msg">
>><br class="gmail_msg">
>> D:/VulkanSDK/<a href="http://1.0.37.0/Bin/vulkan-1.lib" rel="noreferrer" class="gmail_msg" target="_blank">1.0.37.0/Bin/vulkan-1.lib</a> <<a href="http://1.0.37.0/Bin/vulkan-1.lib" rel="noreferrer" class="gmail_msg" target="_blank">http://1.0.37.0/Bin/vulkan-1.lib</a>><br class="gmail_msg">
>><br class="gmail_msg">
>><br class="gmail_msg">
>> instead of<br class="gmail_msg">
>><br class="gmail_msg">
>><br class="gmail_msg">
>> D:/VulkanSDK/<a href="http://1.0.37.0/Bin32/vulkan-1.lib" rel="noreferrer" class="gmail_msg" target="_blank">1.0.37.0/Bin32/vulkan-1.lib</a><br class="gmail_msg">
>> <<a href="http://1.0.37.0/Bin32/vulkan-1.lib" rel="noreferrer" class="gmail_msg" target="_blank">http://1.0.37.0/Bin32/vulkan-1.lib</a>><br class="gmail_msg">
>><br class="gmail_msg">
>><br class="gmail_msg">
>> It makes no sense. Line 47 of FindVulkan.cmake has Bin32. Why is CMake<br class="gmail_msg">
>> ignoring 32?<br class="gmail_msg">
>><br class="gmail_msg">
> You should think the other way around: Why should cmake look in a<br class="gmail_msg">
> special directory, when it finds a library with an appropriate name<br class="gmail_msg">
> before this one?<br class="gmail_msg">
> This decision should be in the corresponding FindVulkan.cmake, i.e. the<br class="gmail_msg">
> corresponding find_library call should be constrained to<br class="gmail_msg">
> ${VULKAN_DIR}/Bin32 in the 32bit case.<br class="gmail_msg">
>><br class="gmail_msg">
>><br class="gmail_msg">
><br class="gmail_msg">
> Regards,<br class="gmail_msg">
> Andreas<br class="gmail_msg">
<br class="gmail_msg">
</blockquote></div></div></div></div></div>