On 11/20/19 11:48 AM, Henri Verbeet wrote:
On Mon, 18 Nov 2019 at 21:22, Hans-Kristian Arntzen post@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@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@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.
I guess I'll just add the stub libraries to my build system instead.
Cheers, Hans-Kristian