[PATCH v5 5/5] vkd3d: Load d3d12 dynamically in d3d12 tests.

[Henri Verbeet]

On Mon, 18 Nov 2019 at 21:22, Hans-Kristian Arntzen
<post at arntzen-software.no> wrote:
> On 11/18/19 6:17 PM, Henri Verbeet wrote:
> > On Mon, 18 Nov 2019 at 20:24, Hans-Kristian Arntzen
> > <post at arntzen-software.no> wrote:
> >> There are no d3d12 headers or -ld3d12 available in MinGW-w64 on msys2 at
> >> least.
> >>
> > Vkd3d builds its own d3d12 import libraries, d3d12.cross32.a and
> > d3d12.cross64.a, as part of the crosstest target.
>
> Sounds like we can remove those then? (This came up in a CMake build
> since autotools doesn't work when building on Windows.)
>
No, that would break the demos. But ignoring that, an out-of-tree
build system doesn't seem like a very good reason to make things
uglier. I must say I'm slightly confused about what you're trying to
do though. It's true that MSVC doesn't play all that well with
autotools unless you use some kind of wrapper script like cccl, but
this patch is supposed to be for MinGW-w64, which should work fine
with autotools.

On Mon, 18 Nov 2019 at 21:46, Hans-Kristian Arntzen
<post at arntzen-software.no> wrote:
> To clarify, it's mostly minor inconvenient things, and I need debugging
> in CLion/MSVC for some things, so ideally, I'd prefer a solution which
> can work without having to go through autotools, and dynamically loading
> d3d12 would make it simpler in all cases I think as there is no longer a
> reason to build stub import libraries.
>
For the case where you're building with MSVC, the platform SDK comes
with d3d12 import libraries of course, but I don't think MSVC should
have an issue with building the vkd3d version of the import libraries
either. If the only reason to use MSVC is PDB support though, it may
be much easier to build with Clang instead, which should have PDB
support as well these days.