[vcpkg] link to debug sdl in debug mode

[Yamakaky]

When building in debug mode, it would be nice to link to the debug version of SDL, since it is built anyway. That would be libSDL2d.a and libSDL2maind.a instead of libSDL2.a and libSDL2main.a. I do it manually by renaming the debug variants to the release variants in target/vcpkg.

[waych]

See #1092 for changes that allow "bundled" to build the underlying sdl2 as Debug mode if you'd like to try it.

I believe it works for both Windows and Linux (though I haven't looked at it in a few months). I'm hesitant to have it merged however as I discovered "Debug" vs "Release" behavior is an ecosystem thing that affects overall link and use of crt, on Windows in particular. This becomes a problem for me in my own project where I have several crates with cc and cmake build dependencies, together with vcpkg. The combination of these in the same project causes problems if any single one of them wants to switch out the crt. At best it would have to be flagged behind a feature and the user still would have to reason this for all other cc and cmake dependencies pulled into their project.

Maybe it could still be merged but flagged behind a new feature. I haven't needed nor done that yet.

It feels like an ecosystem problem and that the solution would required cc, cmake and vcpkg to collaboratively understand the debug vs non-debug crt requirement.

[Yamakaky]

I'm not sure I understand, the debug version is already built in the current version, at least on linux. target/vcpkg/installed/x64-linux/debug/lib/pkgconfig/sdl2.pc can be used to get the link flags. Maybe this is a missing feature in the vcpkg crate?

[waych]

Re use-vcpkg:

Yes, cargo-vcpkg doesn't currently have a way to separate building of both debug and release variants of libraries in the underlying vcpkg tree, so you will always see the debug version as well as the release version. See mcgoo/cargo-vcpkg#3

cargo-vcpkg could use a feature to have a particular lib use the debug version rather than the release version, that could be filed as a feature request there. Probably not too difficult to implement, modulo problems that arise as described below:

---

Re bundled:

The debug version gets built and linked when #1092 is applied. Currently it is setup to use the underlying default behavior that the cmake crate uses which is debug builds get 'Debug' and release builds get 'Release'.

This ends up having a lot more implications than just having debug info and less optimization however, as it impacts the options used in compilation for selecting the runtime options. This hasn't been a problem for me at all on Linux (where I am usually compiling statically), but on Windows, it causes all sorts of problems unless you can guarantee the options match for each module that is eventually linked. Specifically I'm talking about the /MT /MD and /LD and their 'd'-suffix variants documented here: https://docs.microsoft.com/en-us/cpp/build/reference/md-mt-ld-use-run-time-library?view=msvc-160

Specifically calling attention to this paragraph:

All modules passed to a given invocation of the linker must have been compiled with the same run-time library compiler option (/MD, /MT, /LD).

For the bundled path at least, allowing the cmake crate to choose Debug seemed to result in this flag changing in a way that isn't coordinated across all the other cc and cmake and even vcpkg derived libraries in a user's project. This is what I meant by 'ecosystem' problem.