This change broke several of our CI builds on GitHub Actions and Azure Pipelines (we use the presence of VCPKG_ROOT being set to indicate that a user wants to opt-in to building dependencies with vcpkg rather than ones installed on the system). Some form of announcement about this change would have been nice.

• Windows builds on Azure Pipelines started timing out: installing the Boost packages takes an excessively long time, given we only use the headers (last I checked there wasn't a vcpkg for grabbing just the headers and not compile anything), adding about 16 minutes to the overall build time
• MSYS2 builds for our MINGW package started failing (conflict between the vcpkg version of Boost and the mingw copy? not sure)

To get things working again our solution has been to liberally add unset VCPKG_ROOT to our CI workflows and a new option for our CMake builds that forces it to not use vcpkg even if VCPKG_ROOT is set.

@nightlark thank you for the feedback and workaround! we will investigate the issue.

This change broke several of our CI builds on GitHub Actions and Azure Pipelines (we use the presence of VCPKG_ROOT being set to indicate that a user wants to opt-in to building dependencies with vcpkg rather than ones installed on the system). Some form of announcement about this change would have been nice.

• Windows builds on Azure Pipelines started timing out: installing the Boost packages takes an excessively long time, given we only use the headers (last I checked there wasn't a vcpkg for grabbing just the headers and not compile anything), adding about 16 minutes to the overall build time
• MSYS2 builds for our MINGW package started failing (conflict between the vcpkg version of Boost and the mingw copy? not sure)

To get things working again our solution has been to liberally add unset VCPKG_ROOT to our CI workflows and a new option for our CMake builds that forces it to not use vcpkg even if VCPKG_ROOT is set.

@michaelbprice could you please comment on this? It seems it's not so safe to add that variable

I've left a more detailed comment over at #6196 (comment).

We'll see how this shakes out, but it seems to me that if tools expect to use VCPKG_ROOT as an indication of where vcpkg is installed, it should not also serve the purpose of an opt-in, unless that opt-in is strictly predicated on the tool being installed in such an identifiable way.

My recommendation would be to change that opt-in behavior to depend on an environment variable more clearly within the control of the users' environment, by doing something like prepending an org identifier to the environment variable, such as MY_AWESOME_PROJECT_USING_VCPKG_ROOT.

@michaelbprice could you please comment on this? It seems it's not so safe to add that variable

In the sense that it's never safe to add any environment variable, as you cannot predict if someone downstream might already be using it for some other purpose.