[feature] CMakeToolchain generator doesn't adequately represent settings nor does it follow a standard method of overriding C, CXX, and linker flags

[jwillikers]

The CMakeToolchain generator lacks critical functionality for implementing various Conan settings from the settings.yaml file, and it doesn't provide adequate control for consumers to control settings across dependencies.
The new CMakeToolchain generator is very helpful for orchestrating building and packaging CMake projects, but isn't robust enough to properly propagate settings from consumers to their dependencies.
Environment variables appear to be the only way to adequately propagate necessary compiler settings across dependencies using various build systems.
The new CMakeToolchain generator doesn't use the flags from these variables, but instead requires injecting a toolchain file for a dependency to inherit specific settings.
This seems to go against the idea of Conan's settings / profiles being used to influence configurations of dependencies across various projects and their dependencies since its specific to both the underlying build system of each project and also the Conan generators used by the project.

For a simple bare-metal embedded project which doesn't wish to modify the recipes for all of its dependencies, it must use only CMake dependencies if it wishes to use the CMakeToolchain generator and it has to do this through the profile configuration of either user_toolchain or toolchain_file.
This requires manually translating Conan settings to compiler flags in a toolchain file, which is error-prone and redundant since the compiler flags are capable of being deduced from the Conan settings configured in profiles, such as the architecture being translated to the necessary -m flags.

To properly translate Conan settings to compiler flags in the CMakeToolchain, the user can control the templating of the default CMakeToolchain generator, but this must be done for every single dependency and even using python_requires this just isn't feasible for people that want to use existing package recipes from Conan Center.

It seems like there should be way more settings in settings.yaml to translate down to all the various compiler flags for this to work and / or a standard way to inject arbitrary C, CXX, and linker flags across all the various build-system generators directly from profiles.

• I've read the CONTRIBUTING guide.

[memsharded]

Hi @jwillikers

I am not sure what you mean with:

The new CMakeToolchain generator is very helpful for orchestrating building and packaging CMake projects, but isn't robust enough to properly propagate settings from consumers to their dependencies.

The purpose of CMakeToolchain has always been to map from the Conan settings to the CMake configuration. It didn't intend so far to propagate and inject any arbitrary flag or configuration, because that is something way more challenging, can also affect binary compatibility without any model at all, and that is problematic. We have enabled a way to have [conf] items to affect the package_id if necessary, but that is not properly documented yet, because first we need to figure out the implications and possible rough edges.

If there is some current settings that is not correctly processed by CMakeToolchain and is not creating the right conan_toolchain.cmake, please let us know, we would love to improve that.

To properly translate Conan settings to compiler flags in the CMakeToolchain, the user can control the templating of the default CMakeToolchain generator, but this must be done for every single dependency and even using python_requires this just isn't feasible for people that want to use existing package recipes from Conan Center.

This is exactly one of the problems. You cannot just inject things into ConanCenter recipes, because the quality of the build scripts is varying, and there is no general way to fix it. Many ConanCenter recipes apply patches just to avoid the build scripts to hardcode things like the shared/static, or the Visual Studio runtime.

Not to say, that this is only part of the problem, because ConanCenter recipes uses other build systems as well. Then, the expectations would be that Conan can inject any compiler flags from downstream to any package upstream, and that is very challenging in practice. Conan is a package manager, not a build system, and as such, it cannot act as a generic meta-build system that can customize any build of any package. There is an abstraction layer over that, and that is the settings/option/conf one. The helpers like CMakeToolchain are responsible of translating this abstraction to the specifics of the build system, up to their knowledge.

We will eventually consider augmenting the model of build system integrations with more things, like generic compiler flags, but that is not a bug, but a new feature request. It will need to wait until we first stabilize and make mainstream these new integrations. I will label it as feature request. If you thing there is some bug in translating the current settings to cmake toolchain, please report the details in a separate issue.

[jwillikers]

@memsharded Thanks, you addressed my primary concern by pointing out that the CMakeToolchain should handle converting the settings to the necessary toolchain configuration and compiler linker flags. I'll open individual issues for each specific piece that's not implemented in the CMakeToolchain generator yet. These are mostly around embedded systems. Thanks again.

[memsharded]

Thanks, you addressed my primary concern by pointing out that the CMakeToolchain should handle converting the settings to the necessary toolchain configuration and compiler linker flags. I'll open individual issues for each specific piece that's not implemented in the CMakeToolchain generator yet. These are mostly around embedded systems. Thanks again.

Amazing, we are looking forward to keep improving the CMakeToolchain for embedded systems, thanks very much! (we also have pending the issue of adding some basic, common semantics to settings.yml like an os: embedded value or something like that)