Conan: [question] Using CMake toolchainfile generator

[blackliner]

I do have the following snippet as part of my conanfile.py , and would expect the resulting conan_toolchain.cmake would set things like CMAKE_CXX_COMPILER , but it does not :disappointed: all that is in said autogenerated conan_toolchain.cmake is CMAKE_BUILD_TYPE=Release and some variables starting with CONAN...

def toolchain(self):
    tc = CMakeToolchain(self)
    tc.write_toolchain_files()

I am using the following command:

conan install .. -s build_type=Release --build=missing -s compiler=gcc -s compiler.libcxx=libstdc++11 -s compiler.version=8
cmake .. -GNinja -DCMAKE_TOOLCHAIN_FILE=conan_toolchain.cmake

Log:

Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=gcc
compiler.libcxx=libstdc++11
compiler.version=8
os=Linux
os_build=Linux
...
Using Conan toolchain through conan_toolchain.cmake.
-- The CXX compiler identification is GNU 7.5.0

To be able to reproduce this and analyze the exact environment, please have a look at:
https://github.com/blackliner/modern_cmake
Tag: 0.1.2
run pipeline.sh

• [x] I've read the CONTRIBUTING guide.

[memsharded]

Hi @blackliner

https://github.com/conan-io/conan/pull/8034/files for next 1.32 will partially define the compiler for some cases, like when using Ninja in Visual. But this is very preliminary and experimental.

So far, the experimental toolchains are implementing the features and capabilities that were implemented in the previous build helpers. But setting the compiler was never one of them, the most that the cmake generator was doing was to validate that the current working compiler is the one that was used at conan install time.

We don't know yet to which extent the toolchains will implement this, as it is typically not enough to set the compiler as "gcc" for example. In some environments as Windows, with Visual Studio, passing the generator at command line with -G "Visual Studio 15 Win64" is very necessary. We will keep investigating and evolving the toolchains, please keep trying and giving feedback!

[blackliner]

We do embedded, safety critical software. To ensure reproducible builds, we have to strap down the exact compiler version, flags, tools etc via toolchain files. This also holds true for the dependencies we build and ship. So maybe I need to stick to export CONAN_CMAKE_TOOLCHAIN_FILE=$TOOLCHAIN_FILE for now.

[blackliner]

Oh but I see the problem: If I do not also tell conan all the compiler settings etc, how should it know that settings changed? Sounds like I need to maintain 2 systems: conan settings and a toolchainfile... :-/

EDIT: Oh nice, conan DOES see that something is wrong

CMake Error at conanbuildinfo.cmake:401 (message):
  Detected a mismatch for the compiler version between your conan profile
  settings and CMake:

  Compiler version specified in your conan profile: 7

  Compiler version detected in CMake: 8.4

So, maintaining profile and toolchainfiles now? Hmm...

[memsharded]

The thing is that a complete, accurate toolchain is impossible to be deduced from profiles. A profile is an abstraction that defines the binary compatibility and high level configuration of dependencies, but many users will have very specific toolchains that require complex setups, from environment scripts, to cmake-toolchains, to proprietary tools...

In that sense, it is possible, for example, in cmake, to verify that the real current compiler version matches the one that was used in the install. But there will be many other things, like the sysroot, flags, linker, etc., that Conan will not know how to validate.

The plan is to keep improving the toolchains, so they can automate as much as possible, for as many different tools and platforms, but specially in advanced cross-compilation setups, it is very possible that providing configuration in the native build-system, like CMake toolchain-files might still be necessary.

[madebr]

Looking at cmake-toolchains,
I think most important variables to set for toolchains are CMAKE_SYSTEM_NAME and CMAKE_SYSTEM_PROCESSOR.
Also, it would be very nice to be able to override the mapping from self.settings.os/self.settings.arch to CMAKE_SYSTEM_NAME/CMAKE_SYSTEM_PROCESSOR.
As some projects detect 64bit arm as armv8 and others as arm64. Same goes for detecting 32-bit intel as x86 vs i[3-7]86.