mesonbuild
Dependency on Windows DIA SDK possible?
I am trying to use Microsoft Debug Interface Access SDK (DIA SDK) in a project built by Meson. DIA SDK is a Windows-only library, installed as a part of Visual Studio.
To use it in your project, you need to do following:
- Add include directory "$(VSInstallDir)/DIA SDK/include"
- Add library path "$(VSInstallDir)/DIA SDK/lib/amd64" (where "amd64" is the target CPU architecture)
- Provide executable with some way to load the corresponding "$(VSInstallDir)/DIA SDK/bin/amd64/msdia140.dll" at runtime. Either the DLL must be registered in the OS using regsvr32.exe (for CoCreateInstance), or available to the executable to load it manually without registering (using NoRegCoCreate). Simplest solution is to just copy the msdia140.dll to the target executable directory and let it load manually. Note that the version number "140" in DLL filename changes with DIA version.
Paths to DIA SDK are not set by Visual Studio Developer Prompt / vcvars*.bat. You need to add them manually to your project.
Hardcoded include/lib paths relative to VSInstallDir seem to be the "official" way to use this library. See: https://learn.microsoft.com/en-us/visualstudio/debugger/debug-interface-access/getting-started-debug-interface-access-sdk?view=vs-2022 https://learn.microsoft.com/en-us/visualstudio/debugger/debug-interface-access/dia2dump-sample?view=vs-2022
There is also a maybe more general, but undocumented(?) method, used by some CMake projects. It invokes vswhere.exe utility to locate some package, which the DIA SDK is a part of. See: https://github.com/microsoft/DirectXShaderCompiler/blob/main/cmake/modules/FindDiaSDK.cmake
So, what would be the correct way to use the DIA SDK in meson project? Write custom meson module for it? Barring that, is there any feasible workaround, without having to manually specify -D for each meson setup?
Rather than a module, a custom dependency would be the most correct thing. You might be able to use a cmake dependency (dependency('DiaSDK', method='cmake')), though no guarantees that would work.
If you wanted to take a stab at writing such a dependency method I'd be happy to give some pointers and review it. I tried to find something that I thought would be a good starting point, but I don't really see one. VSWhere isn't really a ConfigToolDependency, so I'd probably call it a SystemDependency and call vswhere like the CMake find method does, if it breaks we at least point to that and say "we were doing what the DirectXShaderCompiler does/did"
Yes, I'd like to try to add this dependency properly. Your help would be welcome and needed, as I have no experience with meson sources, and relatively little experience with meson itself (eg. no cross-compilation etc.).
In the meantime, I already tried experimenting with adding a custom module. So far I was able to add the module, it detected required files at the paths relative to $VSInstallDir, returned them to meson.build, etc. . But I struggled with adding a custom external dependency.
It seems the good starting point for writing a dependency could be dependencies/__init__.py? The comment at the beginning seems quite instructive. I'll read through it, do some experiments and let you know when I have advance.
Where should the dependency go to? dependencies/dev.py, as it is a SDK?
I'd put it in dev.py, yeah. If you run into any issues feel free to ping this or ping me on IRC/Matrix. I wrote that giant blob of text, so if anything doesn't make sense or is out of date I'd be happy to update it
There is one interface problem: The application needs some way to access the corresponding redistributable DLL file. These redistributables are installed in DIA SDK directory, for example $VSInstallDir\bin\amd64\msdia140.dll. The application installer must either register the DLL (with regsvr32 msdia*.dll), or the msdia*.dll file must be present somewhere where application can load it from dynamically. Often the DLL is bundled with the application. The DLL file name changes with new versions, eg. it can be msdia80.dll, msdia120.dll, msdia140.dll, etc.
To support various usage scenarios, I think we need:
- provide path/filename of DLL file to meson.build, so it can be passed to configuration.
- way in meson.build script to copy the DLL file into the build directory, if desired
The problem with #1 is, whether there is any clean interface to return the DLL path / filename from dependency object. The problem #2 requires custom functionality? IIRC the fs module can only copy from source directory.
Is there a way to do this with dependency? Or do we have to use module to accomodate all these steps, after all?
Also, if someone wanted DIA SDK support for C# projects, there are apparently some further steps needed: https://stackoverflow.com/questions/697541/how-do-i-use-the-ms-dia-sdk-from-c
Right now our C# support is super bare bones, so unless you want to spend a lot of time working on Meson + C# stuff, I wouldn't worry about that (Says the guy who spent a lot of time fixing Meson + Rust stuff).
Meson internally will try to convert link libraries into full paths, so we should have the full c:\...\msdiaNNN.dll (or at least the .lib) somewhere. I suspect the question of "how do we deal with distrubuting libs found via dependency()" will need some wider thought than we have here, as there's likely other cases for this as well. Internally the mechanism that fs.copyfile uses is basically a very barebones cp implementation in python, so the machinery is all there.
Meson internally does quite a bit of work to make built programs able to run using meson devenv. It doesn't really make any efforts at the moment to try to solve the idea of creating redistributable installers that bundle their externally provided DLLs. Personally, I would suggest statically linking where possible, since almost by definition Windows doesn't allow you to share a shared library... but that is likely not possible for a DLL that Microsoft provides. ;)
There's some examples at https://github.com/mesonbuild/meson/tree/master/manual%20tests/4%20standalone%20binaries and in the docs at: https://mesonbuild.com/Creating-Linux-binaries.html https://mesonbuild.com/Creating-OSX-packages.html
The current general suggestion amounts to "write a deploy script that knows where your SDKs are".
If someone wanted to implement a feature in meson that allows bundling up a project's externally detected dependencies for deploying, I'd be fascinated to hear more. I'm just not sure how it would work. This is a hard problem to solve generically and would probably require fiddling and a lot of project overrides.
