Is there any good way to get a PATH variable injected into the launch.vs.json file used for debugging a target. What I want is to avoid having to manually edit any configuration json files that Visual Studio uses. I would also like to have different environment for different executable cmake targets. (The actual environment differs between machines and operating systems, so I’d like to stay away from a CMakeSettings.json checked into the repository as well.)
- Copy all dll:s depending upon to the location of the executable target. This is not really an option, since we have a lot of third party libraries. We also have several executable targets, so copying into each and every intermediate directory of those is not a good option. Another similar approach used by Conan, is to generate symlinks, but that requires the developer to be administrator which is quite restricting (and this is really not a valid reason for that).
- Setup the global PATH variable prior to starting Visual Studio. Not really good either. For one, each and every target will have the same environment and two, it will be cumbersome updating versions of the third party libraries. And what about libraries built by the project itself?
- Prepopulate launch.vs.json files? How should that be done…? It doesn’t feel like a good option anyway and puts to way much effort into a specific development environment as well. It would probably be a fragile solution as well.
- Install all project generated runtimes into a single folder. This has been a standard way when using solution files. (I have avoided that and injected the proper environment instead.) But doing this with the “Open Folder” approach doesn’t seem feasible anyway. But I’d like to here if it’s possible from cmake only.
Generating a solution file and loading that into VS2019 is no problem in itself (using the VS_* target properties works fine), but using msbuild is so awfully slow. Using the “Open Folder” approach allows using Ninja which is much faster.
I think this should be trivial, but it seems to even having a executable target using a library target built within the project is problematic without manually editing configuration files, which should not be needed, since that’s why we use cmake in the first place. (Building and installing is not a problem, it’s developing/debugging that doesn’t work.)