search

microsoft / DirectXTK

The DirectX Tool Kit (aka DirectXTK) is a collection of helper classes for writing DirectX 11.x code in C++
https://walbourn.github.io/directxtk/
MIT License
2.55k stars 506 forks source link

provide cmake support #74

Closed sdcb closed 5 years ago

sdcb commented 7 years ago

I hope you can provide the cmake support.

Reference here: https://github.com/Microsoft/vcpkg/pull/538

In the long them I think this library as well as DirectX* ones should be switched to (possibly pushed upstream) cmake builds. It shouldn't be hard as all of them are rather simple. This could allow us to:

Easily support more than one VS version and UWP builds. Possibly enable dynamic build with cmake's autoexport (as long as there are no data symbols in public interface) Support static builds with either static or dynamic CRT. Currently dynamic one is always used and *-windows-static triplets fail (post-build checks complain about mismatch). Alternatively we could pass some flag to msbuild to fix CRT linkage (I didn't try this, but I think it's possible) and maybe implement some logic to find correct project (for example for VS2017), but I find this solution inferior as it's possible there won't be project available for given configuration (for example DirectXTK seems to be missing VS2017 UWP project). With cmake all configurations that make sense will just work.

By switch build from msbuild to cmake, directxtk can easier to port to dynamic linkage,I created a test CMakeLists.txt here: https://gist.github.com/sdcb/8ee863c79a70406d4ed8a9e3f10019a2

But it's still not done yet because the dllimport/dllexport is not specified.

walbourn commented 7 years ago

I'm certainly open to the idea of maintaining cmake support, so I'll keep it in mind.

That said, I've yet to find any sound technical reason why having DirectXTK as a DLL is at all desirable. The main value of a DLL is being able to replace the binary DLL code without having to change the client of the DLL, which requires a consistent ABI. There is no such ABI for DirectXTK. It doesn't use COM or C-linkage, minimal use of virtual indirection, and I make no guarantees from version to version of a consistent public interface in terms of linkage. Furthermore, since I make use the Standard C++ Library, there's no consistent ABI between versions of Visual C++ so you still need to generate version-specific DLLs. Plus I make use of inline functions in a number of public interfaces.

Past experience with the D3DX utiltiy library as a DLL has also shown that it's quite problematic in terms of distribution and matinainence, with little upside. DLL exporting means turning all methods into indirect calls with little value to the runtime selection flexibility, and since I make use of pImpl many methods would actually become double-indirections. This also greatly limits the optmization options of LTCG, in game scenarios it introduces aditional attack surface for cheaters, and can potentially lead to multiple versions of the CRT being bound to a process simultaenously.

southie commented 6 years ago

Just to chime in, I would suggest directing those interested to use vcpkg for out of the box cmake support. It takes a lot of the burden off the project maintainers and moves it to a consistent platform for finding and installing packages. The only downside is if you have a lot of customization, you have to learn a new package management system. We only continue to use a custom cmake file because our version of directxtk is highly modified.

https://github.com/Microsoft/vcpkg

walbourn commented 5 years ago

Note that this pull request includes cmake files. With VS 2019 Update 1, it's a lot easier for me to maintain now and get some value out of if by using clang for conformance validation.