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 <cm...@anteru.net > <mailto:cm...@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 > -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake