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!
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
more find_library calls?
Is there a downside from configure taking an unknown amount of time? My
expectation was that there is no timeout for the configure step.
Cheers,
Matthäus
Am 24.09.2015 um 22:30 schrieb Bill Hoffman:
> On 9/24/2015 4:26 PM, Matthäus G. Chajdas wrote:
>> Hi,
>
E BOOL "" FORCE)
> endif()
>
> In the latter case there's no need to write the variables into a script
> since the fetcher runs in the same scope.
>
> Tamas
>
>
> On Wed, Sep 23, 2015 at 9:49 PM, Matthäus G. Chajdas <mailto:cm...@anteru.net>>
Hi,
I'm trying to solve the following the problem: I have a C++ application
and a dependency fetching script. I want to simplify the initial build
such that the following happens: On the first run of cmake, the compiler
ID and version is passed to an external script, which fetches some
pre-build b
