Choose MinGW triplets when building vcpkg with MinGW

[dg0yt]

This commit enables build and use of vcpkg on Windows systems which only have a MSYS2 MinGW environment.

This PR is complemented by #31 and a pending change to bootstrapping (dg0yt/vcpkg@31c31d9, pointless without #31).

Tested only with x64-mingw-dynamic and zlib.

[strega-nil]

I would prefer the use of VCPKG_DEFAULT_TRIPLET + VCPKG_DEFAULT_HOST_TRIPLET.

[dg0yt]

VCPKG_DEFAULT_TRIPLET + VCPKG_DEFAULT_HOST_TRIPLET are environment variables IIUC. They are useful to change the triplet ad-hoc or in an automated CI environment.
But I want to enable simple bootstrap and usage of vcpkg in environments without MSVC. Building with MinGW instead of MSVC is a strong indicator for such an environment.

Instead of using the MINGW macro, an explicit option in CMakeLists.txt (plus a project-defined macro to pass this choice the build) might be an alternative which even better complements the explicit -useMinGW option from dg0yt/vcpkg@31c31d9.

[dg0yt]

I discovered more spots which need changes in order to support of MinGW as "native" WIN32 toolchain (alternative to MSVC).

• There is a std::filesystem::rename issue affecting vcpkg (cf. gcc-mirror/gcc@1dfd95f).
• MinGW may mix \ and / path separators. At least in user facing messages, this looks strange and might need an adjustment.
• The cmake scripts in vcpkg do even have their own bootstrapping of MSYS2 (for packages like libiconv). This bootstrapping is not (always) desired when the host toolchain is MSYS2/MiNGW.
  In particular, Azure Pipelines Windows images come with a fairly complete MSYS2/MinGW toolchain preinstalled. It is a significant waste of resources to not use it.

I can continue on exploring the required changes. However I would like to know upfront how to handle the vcpk-tool build:
(A) Just rely on detecting a MINGW build configuration (#if defined(__MINGW32__) as used in this PR, and similar in CMakeLists.txt), or
(B) Add an explicit configuration option in CMakeLists.txt.
Of course the user may still override the host triplet at runtime, so the vcpkg scripts need a different treatment.

Given the presence of MSYS2 in Azure Pipelines, support of MinGW as "native" WIN32 toolchain could be covered by CI. (And eventually, bootstrapping an additional MSYS2 vcpkg tool during Azure Pipelines image generation would validate that toolchain.)

[strega-nil]

@dg0yt hmm, okay. I'll mark as requires:discussion so we can talk about it tomorrow.

[ras0219-msft]

support of MinGW as "native" WIN32 toolchain (alternative to MSVC).

Just to be clear, could you lay out the full scenario that you're trying to enable? For example, we generally intend the vast majority of Windows users to consume the precompiled, signed binaries that we are producing from our official pipeline (that's what bootstrap-vcpkg.bat does now -- just a download, no MSVC required). That isn't to say that we we don't want MinGW to be able to compile the vcpkg tool, but just that a feature like this will impact a vanishingly small number of people (and likely generate just as many bug reports of unexpected behavior).

Additionally, even if the vcpkg tool embedded something like x64-mingw-dynamic as the default triplet, that would only change classic mode and wouldn't affect manifest mode for most users (which is controlled by vcpkg.cmake/MSBuild).

You might be happiest using overlay triplets or modifying your fork of vcpkg's x64-windows.cmake to actually be mingw; this would "just work" with manifest mode integration and the default host/target triplets. Otherwise, just define VCPKG_DEFAULT_TRIPLET and VCPKG_DEFAULT_HOST_TRIPLET in your system environment / bashrc / etc.

[dg0yt]

Background:
I'm already using a home-grown cmake-based superbuild project for a number of packages including Qt and GDAL. From one cmake script per package, I handle dependencies, downloads (Debian tarballs and patches), and builds, for Windows, macOS, Linux and Android. While there still are some advantages over vcpkg (in particular parallel builds of multiple packages, even for different target "triplets"), I would like to transition to and rebase my build rules on vcpkg which is much ahead in a number of other features.

Why MSYS2:
For public releases, I would prefer to still provide my own ports, giving me full control over the scripts, sources and patches for quality and for legal aspects. In this scenario, I would (continue to) strongly benefit from a Windows environment centered around MSYS2 where the configuration and build scripts don't need much adaptation. My experience was quite positive over the last years.

Why changes in vcpkg-tool:
To be honest, since I usually start from a MINGW64 bash, and with the README.md requiring MSVC for Windows, I never considered invoking bootstrap-vcpkg.bat at all. Maybe it will just do what I need with the mentioned environment variables set. This could be good enough for most use cases
On the other hand, a "native MSYS2" version would simplify this use case for new developers, and it might be able to make better use of this environment. It might even encourage broader adoptation of vcpkg.
Ideally this would also extend to manifest mode, at least for the cmake integration.
It all boils down to lowering the entry barriers.

Last not least
I acknowledge the aspect of additional bug reports. OTOH the basic support in vcpkg is already there, for Linux and macOS. The key aspect of modification is breaking the assumption that WIN32 implies MSVC and the related triplets.

[dg0yt]

I can confirm that the default binary vcpkg.exe basically works fine even for a pure MinGW environment.

However, there is evidence for people struggling with such setups, e.g. microsoft/vcpkg#17092. Some issues might be mitigated by a better documentation entry point, for example similar to https://vcpkg.readthedocs.io/en/latest/users/android/. Other than modifying vcpkg.exe tool, improving documentation should actually help to reduce the number of bug reports.

[ras0219-msft]

Agreed that some docs on how to use vcpkg in a pure mingw environment would be great. Based on my understanding, for classic mode this should be as simple as

set VCPKG_DEFAULT_HOST_TRIPLET=x64-mingw-dynamic
set VCPKG_DEFAULT_TRIPLET=x64-mingw-dynamic

For manifest mode, users currently would need to do

set VCPKG_DEFAULT_HOST_TRIPLET=x64-mingw-dynamic
cmake -DVCPKG_TARGET_TRIPLET=x64-mingw-dynamic .. /* usual arguments */

Alternatively, in both cases, a user can copy+rename triplets/x64-mingw-dynamic.cmake to some user location (%LOCALAPPDATA%/.vcpkg/triplets/x64-windows.cmake) and simply set

set VCPKG_OVERLAY_TRIPLETS=%LOCALAPPDATA%/.vcpkg/triplets

which should Just Work for all modes, since x64-windows effectively becomes mingw.

[dg0yt]

Agreed that some docs on how to use vcpkg in a pure mingw environment would be great.

Now started at microsoft/vcpkg#17219.

[ras0219-msft]

@dg0yt Now that microsoft/vcpkg#17219 has been merged, do you think this should be closed?

[dg0yt]

@ras0219-msft It is okay to close it now.
This doesn't mean there wouldn't be desire for a different default in some installation but this isn't limited to mingw.