Windows flaw when building with bazel in modern CMake due to erroneous policy CMP0091

[wrowe]

At the envoy project, we have been very successful ensuring that Bazel's elections of compilation and linker flags are respected by using the -GNinja target with CMAKE_BUILD_TYPE "Bazel" for cmake_external() components.

This causes all of the various CMAKE_C_FLAGS_RELEASE, CMAKE_C_FLAGS_DEBUG choices etc. to be silently dropped. (If we wish, bazel's cmake_external() could pass CMAKE_C_FLAGS_BAZEL, but this is unnecessary since they are just passed as CMAKE_C_FLAGS.) Each bazel invocation of rules_foreign_cc invokes cmake to configure the appropriate CMAKE_C_FLAGS and other command line options.

In the curl project, we encountered the following problem with their explicit cmake rulesets;
cmake_minimum_required(VERSION 3.2...3.16 FATAL_ERROR)

This triggers a new CMake 3.15 rule CMP0091, which introduces a bug on Windows. That rule causes CMAKE_MSVC_RUNTIME_LIBRARY to be set to a fixed runtime, overriding the BAZEL target elections. If this policy is unset, the original behavior is restored, and the runtime elections are left in CMAKE_C_FLAGS_RELEASE etc, where they are harmless.

It turns out that toggling the CURL_STATIC_CRT works around this policy flaw in this specific case, but only by coincidence. We should avoid spelling out static/dynamic runtime elections to each CMake-based component of a given project, and always control the runtime election through bazel's own logic using toggles such as --features=fully_static_link --features=static_link_msvcrt and --dynamic_mode=off.

We would suggest that cmake_external() should inject the following line into crosstool_bazel.cmake within CMake_script.sh, which would suppress this flaw, irrespective of which version of CMake is invoked;

cmake_policy(SET CMP0091 OLD)

[wrowe]

According to the final paragraph of documentation on this problematic CMake behavior;

"This policy was introduced in CMake version 3.15. Use the cmake_policy() command to set it to OLD or NEW explicitly. Unlike many policies, CMake version 3.18.4 does not warn when this policy is not set and simply uses OLD behavior." https://cmake.org/cmake/help/v3.18/policy/CMP0091.html

Contrary to the following auto-appended Note, it seems clear this unwise change will permanantly default to 'OLD' (correct) behavior, and the 'NEW' behavior is actually deprecated. I don't see any action the bazel rules_foreign_cc can take to dodge this misapplication of the policy by the curl project, and so this should just be treated as closed/CANT_FIX.