conan icon indicating copy to clipboard operation
conan copied to clipboard

[question] How to ensure clang installed with the MSCV compiler is used?

Open petermbauer opened this issue 2 years ago • 6 comments

What is your question?

Hi! I would like to ensure in the respective profile that the clang coming with the MSVC installation (2022 in this case) is used even if there is another clang/LLVM installation in the PATH. Already went through https://blog.conan.io/2022/10/13/Different-flavors-Clang-compiler-Windows.html but i could only find how to use the clang-cl coming with the MSVC installation.

Currently the relevant part of the profile is:

[settings]
compiler=clang
compiler.version=15
compiler.cppstd=20
compiler.runtime_version=v143

[conf]
tools.build:compiler_executables={'c':'clang','c++':'clang'}

So the problem is that clang is taken from the PATH and the question is how to set tools.build:compiler_executables without knowing the exact path of the clang executables in the MSVC installation?

Have you read the CONTRIBUTING guide?

  • [X] I've read the CONTRIBUTING guide

petermbauer avatar Mar 16 '23 08:03 petermbauer

Hi @petermbauer

Thanks for your question.

The clang from VS would be activated if using the Visual Studio cmake generator, that would activate it via the ClangCL cmake toolset. The relevant conf would be:

tools.cmake.cmaketoolchain:generator=Visual Studio 17

Note, sure you don't want to do ``tools.build:compiler_executables={'c':'clang','c++':'clang++'}?

memsharded avatar Mar 16 '23 08:03 memsharded

Hi @memsharded , thanks for the quick reply! We want to use Ninja so would this still work? I missed some parts of the profile as it is split up into several files, here is the full output:

$ conan profile show default
Configuration for profile default:

[settings]
os=Windows
arch=x86_64
compiler=clang
compiler.version=15
compiler.cppstd=20
compiler.runtime_version=v143
build_type=RelWithDebInfo
compiler.runtime=dynamic
compiler.runtime_type=Release
[options]
qt:device=None
...
[conf]
tools.build: compiler_executables={'c': 'clang', 'c++': 'clang++'}
tools.cmake.cmaketoolchain:generator=Ninja
tools.env.virtualenv:auto_use=True
[build_requires]
[env]

petermbauer avatar Mar 16 '23 08:03 petermbauer

Hi @petermbauer

I just came accross your issue and wanted to give it a try. I found that with this profile in conan 2 it works compiling for clang-cl and using the ninja generator:

[settings]
os=Windows
arch=x86_64
compiler=clang
compiler.version=17
compiler.cppstd=20
compiler.runtime_version=v143
build_type=Release
compiler.runtime=dynamic
compiler.runtime_type=Release
[conf]
tools.cmake.cmaketoolchain:generator=Ninja

Now, answering your question, I think this should pick the correct clang from the environment as this will activate the apropriate vcvars environment indicated in the profile. However I am not completely sure. Otherwise you will have to set the abtsolute compiler paths in the conf:

[conf]
tools.build:compiler_executables={'c': 'C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/Llvm/x64/bin/clang.exe', 'c++': 'C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/Llvm/x64/bin/clang++.exe'}

I guess however that this would be something you would like to avoid as much as possible.

Anyway, I was able to compile a smalle hello program with this setup using clang-cl, visual studio 2022 and ninja generator for CMake:

hello/1.0: Calling build()
hello/1.0: Running CMake.configure()
hello/1.0: RUN: cmake -G "Ninja" -DCMAKE_TOOLCHAIN_FILE="C:/Users/danielm/.conan2/p/b/hello04688b2cf789d/b/build/Release/generators/conan_toolchain.cmake" -DCMAKE_INSTALL_PREFIX="C:/Users/danielm/.conan2/p/b/hello04688b2cf789d/p" -DCMAKE_POLICY_DEFAULT_CMP0091="NEW" -DCMAKE_BUILD_TYPE="Release" "C:\Users\danielm\.conan2\p\b\hello04688b2cf789d\b"
-- Using Conan toolchain: C:/Users/danielm/.conan2/p/b/hello04688b2cf789d/b/build/Release/generators/conan_toolchain.cmake
-- Conan toolchain: C++ Standard 20 with extensions OFF
-- Conan toolchain: Setting BUILD_SHARED_LIBS = OFF
-- The CXX compiler identification is MSVC 19.29.30154.0
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.29.30133/bin/HostX64/x64/cl.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done (1.6s)
-- Generating done (0.0s)
-- Build files have been written to: C:/Users/danielm/.conan2/p/b/hello04688b2cf789d/b/build/Release

hello/1.0: Running CMake.build()
hello/1.0: RUN: cmake --build "C:\Users\danielm\.conan2\p\b\hello04688b2cf789d\b\build\Release" -- -j8
[2/2] Linking CXX static library hello.lib

danimtb avatar May 23 '24 14:05 danimtb

Hi @danimtb , thanks for looking into this and sharing. Have you also tried to install LLVM in addition to MSVC? In my experience, this adds the clang/clang-cl folder to the PATH and it will be picked up with priority over the ones coming with the MSVC installation.

To my understanding, Conan knows that the clang of the MSVC installation is supposed to be used (compiler.runtime_version=v143) so theoretically it should be possible to resolve the path based on what vcvarsall.bat does and write the absolute path to the clang.exe into the conan_toolchain.cmake

petermbauer avatar May 23 '24 15:05 petermbauer

Have you also tried to install LLVM in addition to MSVC? In my experience, this adds the clang/clang-cl folder to the PATH and it will be picked up with priority over the ones coming with the MSVC installation.

Not necessarily, when using the Conan specified profile, those paths in compiler_executables will be directly injected into CMake variables, and that have higher priority than the PATH env-var. In any case, it is most likely recommended to remove the external LLVM/CLang installed in the system outside VS if you plan to use the VS internal one, and make explicit in profiles which one (including when you want to use LLVM/CLang external).

memsharded avatar May 23 '24 17:05 memsharded

Yes, but i was refering to the "outside" PATH having priority over what vcvarsall.bat is setting. From time to time somebody has already installed LLVM and then the build fails, ending up on my table. Not a showstopper of course but one more thing to take care of.

petermbauer avatar May 23 '24 19:05 petermbauer