Stl: CMake build failure in presence of gcc's c++.exe in the PATH

[malkia]

Describe the bug
I've synced (on Windows) to latest (as of today): git clone https://github.com/microsoft/STL --recursive

Command-line test case
Per documentation, that was my command:
cmake -G Ninja -DCMAKE_TOOLCHAIN_FILE=d:\p\microsoft\STL\vcpkg\scriptsbuildsystems\vcpkg.cmake -S . -B out123

I've made sure "out123" is not present.

The problem now was that CMake build tool found gcc's c++.exe (installed from chocolatey), although I was in the x64 VS2019 Command line prompt, and "cl.exe" was first in the PATH (though it does not matter much in this case, as they have different names).

Since I'm not much familiar with CMAKE, googled, and found that this should improve it:

cmake -G Ninja -DCMAKE_TOOLCHAIN_FILE=d:\p\microsoft\STL\vcpkg\scriptsbuildsystems\vcpkg.cmake -DCMAKE_C_COMPILER="cl.exe" -DCMAKE_CXX_COMPILER="cl.exe" -DMSVC_TOOLSET_VERSION=142 -S . -B out123

e.g. explicitly specifying the compiler driver ("cl.exe"), and the toolset (142 for VS2019)

With this I've got ninja generated (though then I realized I need the preview 19.25 compiler, and the highest I had was 19.14).

[StephanTLavavej]

@BillyONeal @barcharcraz @cbezault Should we update the README here, or can/should we modify the CMake build system to specify that we always want MSVC and it has to be the 2019 release series (if multiple toolsets are installed)?

[cbezault]

@malkia you should resolve this by setting the CXX and CC environment variables. Not by force defining CMAKE_CXX_COMPILER.

Otherwise the preferred compiler does seem to be c++ as per this. It looks like we could set CMAKE_CXX_COMPILER_NAMES before we call project to force cl to be selected. It isn't clear to me how to force a vs2019 compiler to be selected if there is a non vs2019 compiler in the path but we could fast fail pretty easily by checking the compiler version.

[StephanTLavavej]

https://github.com/microsoft/STL/blob/2b2746dd78d06493cb204e8616beec7991d72840/stl/inc/yvals_core.h#L454-L456
will cause an attempted build with an outdated MSVC to fail quickly, but checking in CMake might be better.

[malkia]

@malkia you should resolve this by setting the CXX and CC environment variables. Not by force defining CMAKE_CXX_COMPILER.

Thanks! That seems better approach (less typing, easier to remember). I'm just not that familiar with CMake that well, and that was the first thing I've found in stack overflow (to actually work).

[cbezault]

@StephanTLavavej having yvals_core.h fail the build sounds fine. Maybe we could do more niceness and fail a little earlier in the CMake but I don't feel like it's worth any additional complexity unless contributors seem to start having trouble often.

[StephanTLavavej]

We talked about this and we're uncertain whether this is a vcpkg bug. If it's not, we have a weak consensus that the README should mention this category of failures and how to avoid it.

[cbezault]

It's unclear to me how this issue could be related to vcpkg. Are we somehow hooking into the vcpkg compiler detection logic?

[StephanTLavavej]

See the command line in the original report: -DCMAKE_TOOLCHAIN_FILE=d:\p\microsoft\STL\vcpkg\scripts\buildsystems\vcpkg.cmake

(I am a total novice here, this is just what I recall from our weekly meeting.)

[cbezault]

Ah, of course, blanked on that.

[cbezault]

Just took a look through the toolchain file (I may have been working on it not even 3 months ago but I couldn't remember the details). I don't see anything in there which should affect the selected compiler. I don't think this has anything to do with vcpkg.