On 4/5/22 06:29, Henri Verbeet wrote:
On Fri, 1 Apr 2022 at 23:17, Zebediah Figura zfigura@codeweavers.com wrote:
Should libvulkan support be explicitly disabled with a configure argument instead?
I think so, or at least the implications of building without libvulkan should be more explicit. For example, this is going to make libvkd3d-utils largely non-functional because D3D12CreateDevice() depends on vkd3d's ability to load libvulkan by itself. Similarly, in most cases applications using vkd3d would be expected to pass NULL as "pfn_vkGetInstanceProcAddr", and would be broken on such a build. The commit message could use some elaboration on why someone might want to make such a build.
Right, I think that makes sense to me. I'll rework the patch.
An alternative worth considering may be to explicitly specify the library name to load at run-time to configure, instead of disabling loading the Vulkan library completely. I.e., a Win32 build could configure with something like SONAME_LIBVULKAN="vulkan-1.dll".
Being able to manually override the soname seems like a good idea as well. Given the motivation is "make it simpler to build MinGW vkd3d", specifying the soname would also allow that to happen without sacrificing any functionality.