Feature request: support `VCPKG_BUILD_TYPE debug` similarly to `VCPKG_BUILD_TYPE release`

[daumantas-kavolis-sensmetry]

Continuation of microsoft/vcpkg#52690 and microsoft/vcpkg#52690 (comment).

It would be great if VCPKG_BUILD_TYPE debug was supported in triplets to build only debug binaries, main use case is CI pipelines where a single worker only builds a single type. Currently, config files are installed into nested debug folders which are removed by ports expecting them to be mirrored from release builds but release is never built so the configs do not exist after port completes.

Instead if VCPKG_BUILD_TYPE is explicitly set to debug (or any non-empty value in general case), config files and binaries could be installed directly into root directories mirroring current release behaviour which works. This would not require changes to ports themselves, however post build validation would need to accept debug binaries in the root directory.

[BillyONeal]

Unfortunately this is not practical given that several single config components must come from the release version, such as /include. You can get the same effect of this by setting it to release and just putting debug build flags in there.

[daumantas-kavolis-sensmetry]

Unfortunately this is not practical given that several single config components must come from the release version, such as /include.

Could that not be solved by not using debug suffix for install dir if VCPKG_BUILD_TYPE is set explicitly? Package cache entries are already suffixed with the triplet name so there should be no filename clashes - build type would instead be included as part of the triplet name. CMake installs should not care about build type, and contain /include and /share dirs even in debug builds. I thought that vcpkg used debug suffix to support multi-config builds as the current default, and why ports have to explicitly remove directories with duplicate files, e.g. /include/debug and /share/debug.

You can get the same effect of this by setting it to release and just putting debug build flags in there.

Sounds like a good workaround except CMake adds additional default flags per build type which VCPKG_BUILD_TYPE controls. In addition, windows toolchain uses build type to select CMAKE_MSVC_RUNTIME_LIBRARY and overrides CMAKE_<LANG>_FLAGS_<CONFIG> directly (no _INIT), which also include build type dependent flags like CRT linkage and optimization level.

Unless I am missing something, debug builds would also require debug toolchains to use correct debug flags — triplets are not enough.

[BillyONeal]

Could that not be solved by not using debug suffix for install dir if VCPKG_BUILD_TYPE is set explicitly?

Hypothetically yes but it would require explicit handling in every build system for an extremely rarely tested configuration that doesn't actually solve any problems (given that "just put your /Od /MTd et al. into "release" flags works just fine).

Sounds like a good workaround except CMake adds additional default flags per build type which VCPKG_BUILD_TYPE controls. In addition, windows toolchain uses build type to select CMAKE_MSVC_RUNTIME_LIBRARY and overrides CMAKE_FLAGS directly (no _INIT), which also include build type dependent flags like CRT linkage and optimization level.

The surgery that will be needed to support this in a reasonable way will vastly exceed the complexity of setting CMAKE_MSVC_RUNTIME_LIBRARY.

Unless I am missing something, debug builds would also require debug toolchains to use correct debug flags — triplets are not enough.

I don't know what you mean by "debug toolchains"; toolchains don't have debug/release-ness. Triplets describe toolchains so if it goes in the toolchain triplets are by definition enough.