Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[bug] Conan generate the wrong CMake Presets when building for MSVC 194 #17115

Open
elvisdukaj opened this issue Oct 4, 2024 · 4 comments
Open

Comments

@elvisdukaj
Copy link
Contributor

elvisdukaj commented Oct 4, 2024

Describe the bug

After updating Visual Studio my conan projects based on Conan broke during the building because the Visual C++ runtime was not found. The new Visual C++ toolset is v194 but when calling conan install the generated CMakePreset.json still refers to the older toolchain:

"toolset": {
  "value": "v143",
  "strategy": "external"
},

Trying to call cmake with the preset results in the following error:

-- The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:2 (project):
  No CMAKE_CXX_COMPILER could be found.

  Tell CMake where to find the compiler by setting either the environment
  variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full path
  to the compiler, or to the compiler name if it is in the PATH.


-- Configuring incomplete, errors occurred!

In CLion, instead the fails to load the cmake configuration because is passing -vcvars_ver=14.3 instead of vcvarsall.bat" amd64 -vcvars_ver=14.4

On CLion, if I manually changing the toolset value in the generated cmake user preset to v194, the configuration works again. This is not true when calling cmake --preset conan-release.

-- Using Conan toolchain: C:/xrsw/repos/projects/test_vc194/t2/build/Release/generators/conan_toolchain.cmake
-- Conan toolchain: Setting CMAKE_MSVC_RUNTIME_LIBRARY=$<$<CONFIG:Release>:MultiThreadedDLL>
-- Conan toolchain: C++ Standard 23 with extensions OFF
-- The CXX compiler identification is MSVC 19.41.34120.0
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files/Microsoft Visual Studio/2022/Professional/VC/Tools/MSVC/14.41.34120/bin/Hostx64/x64/cl.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done (2.4s)
-- Generating done (0.2s)
-- Build files have been written to: C:/xrsw/repos/projects/test_vc194/t2/build/Release

[Finished]

How to reproduce it

  1. Install the latest Visual C++ toolchain (_MSC_VER 1941) coming with Visual Studio 17.11.4.

  2. Use the following profile:

    [settings]
    arch=x86_64
    build_type=Release
    compiler=msvc
    compiler.cppstd=23
    compiler.runtime=dynamic
    compiler.runtime_type=Release
    compiler.version=194
    os=Windows
    [conf]
    tools.cmake.cmaketoolchain:generator=Ninja
    
  3. Create a project with conan new cmake_exe -d name=msvc194 -d version=1

  4. Call conan install: conan install . -s compiler.version=194

  5. Calling cmake with the preset: cmake --preset conan-release

@elvisdukaj
Copy link
Contributor Author

elvisdukaj commented Oct 4, 2024

I am not fully sure if the issue is conan or CMake or MSVC side. Interestingly, calling conan build . activates the right environment and I don't have this issue.

There is also a relate MR in CMake: VS: Fix '-T version=14.4x' under VS 17.1x

Looking at <Microsoft Visual Studio>/2022\Professional\VC\Auxiliary\Build\vcvarsall.bat I found:

Looking at conanvcvars.bat the right environment is called:

@echo off
set __VSCMD_ARG_NO_LOGO=1
set VSCMD_SKIP_SENDTELEMETRY=1
echo conanvcvars.bat: Activating environment Visual Studio 17 - amd64 - winsdk_version=None - vcvars_ver=14.4
set "VSCMD_START_DIR=%CD%" && call "C:\Program Files\Microsoft Visual Studio\2022\Professional\VC/Auxiliary/Build/vcvarsall.bat"  amd64 -vcvars_ver=14.4

Indeed in C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Auxiliary\Build\vcvarsall.bat there is no -vcvars_ver=14.3 option:

Syntax:
    vcvarsall.bat [arch] [platform_type] [winsdk_version] [-vcvars_ver=vc_version] [-vcvars_spectre_libs=spectre_mode]
where :
    [arch]: x86 | amd64 | x86_amd64 | x86_arm | x86_arm64 | amd64_x86 | amd64_arm | amd64_arm64
    [platform_type]: {empty} | store | uwp
    [winsdk_version] : full Windows 10 SDK number (e.g. 10.0.10240.0) or "8.1" to use the Windows 8.1 SDK.
    [vc_version] : {none} for latest installed VC++ compiler toolset |
                   "14.0" for VC++ 2015 Compiler Toolset |
                   "14.xx" for the latest 14.xx.yyyyy toolset installed (e.g. "14.11") |
                   "14.xx.yyyyy" for a specific full version number (e.g. "14.11.25503")
    [spectre_mode] : {none} for libraries without spectre mitigations |
                     "spectre" for libraries with spectre mitigations

The store parameter sets environment variables to support Universal Windows Platform application
development and is an alias for 'uwp'.

For example:
    vcvarsall.bat x86_amd64
    vcvarsall.bat x86_amd64 10.0.10240.0
    vcvarsall.bat x86_arm uwp 10.0.10240.0
    vcvarsall.bat x86_arm onecore 10.0.10240.0 -vcvars_ver=14.0
    vcvarsall.bat x64 8.1
    vcvarsall.bat x64 store 8.1

@memsharded
Copy link
Member

Hi @elvisdukaj

I think the problem is that the compiler version 194, with toolset version 14.4 uses the toolset platform v143, so this looks correct in that regard.

the problem could be that you are not calling the generated build/Release/generators/conanbuild.bat, which is necessary for Ninja generator. Unless you really don't want to use the Ninja generator, it is not clear if that profile is the default one, or you are not really calling it, because calling with -s compiler.version=194 seems pointless if it is already defined in the profile.

@elvisdukaj
Copy link
Contributor Author

@memsharded thank you for the reply. I am still a bit puzzled: I never called the conanbuild.bat when using the cmake preset, as it was working out of the box and cmake or ninja were automatically detecting the msvc toolset. Maybe I was doing that erroneously.

The fact that CLion fails to configure cmake because of the preset could be a bug CLion side than.

Thank you for following up.

For reference I am posting the full profile I used:

======== Input profiles ========
Profile host:
[settings]
arch=x86_64
build_type=Release
compiler=msvc
compiler.cppstd=23
compiler.runtime=dynamic
compiler.runtime_type=Release
compiler.version=194
os=Windows
[tool_requires]
*: ninja/1.12.1, cmake/3.30.1
[conf]
tools.cmake.cmaketoolchain:generator=Ninja
tools.env.virtualenv:powershell=False

Profile build:
[settings]
arch=x86_64
build_type=Release
compiler=msvc
compiler.cppstd=14
compiler.runtime=dynamic
compiler.runtime_type=Release
compiler.version=193
os=Windows
[conf]
tools.cmake.cmaketoolchain:generator=Ninja
tools.env.virtualenv:powershell=True

I have similar results also when using "Visual Studio 17 2022" as cmake generator.

@memsharded
Copy link
Member

The fact that CLion fails to configure cmake because of the preset could be a bug CLion side than.

It depends on how you use it. If you do it via CMakePresets it is different than done by the CLion plugin.
The CMake presets might contain the necessary information to locate the tool-requires too.

What is exactly the full failure?
Because I see that you have in your "build" profile: compiler.version=193, which would be incorrect, if the thing fails to build a tool_requires in the build context, that would explain it.
If you post the full output of conan install . -s compiler.version=194 that would help

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants