Skip to content

FetchContent's sub build should ignore the CMAKE_TOOLCHAIN_FILE environment variable

This problem was first reported in the CMake forums, starting with this comment in a longer discussion thread: https://discourse.cmake.org/t/using-a-fetched-cross-compiler-toolchain/1895/8

When FetchContent sets up its sub-build to do the content population, it doesn't need to compile anything. All it needs is a build tool. The main project passes through CMAKE_MAKE_PROGRAM to the sub-build so that it will always find the right build tool. If a toolchain file is set in the main project, we don't want to use it in the sub-build because the toolchain file may itself be getting downloaded by FetchContent before the main project's first project() call.

A problem arises when the CMAKE_TOOLCHAIN_FILE environment variable is set. In the sub-build, CMake will use that environment variable to initialise the CMAKE_TOOLCHAIN_FILE CMake variable. We don't want that, but the sub-build doesn't currently do anything to prevent it. This exact scenario occurs with Visual Studio 2022 when it sees a preset that specifies a toolchain file. It sets both the CMake variable and the environment variable, even though the latter is not necessary and should have no effect. I consider that to be a bug in Visual Studio, but FetchContent should still handle it and ensure CMAKE_TOOLCHAIN_FILE is unset before it calls project() in the sub-build.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information