Question about how to handle options from conan to CMake and from CMake to conan

[strattist]

I have a project that I want to be able to build and package with conan. In my conanfile.py I have made the work to have options passed to CMake using the CMakeToolchain generator. It works fine in a context where conan runs CMake.

I also want to be able to have the CMake runs conan for different reason, the most important being imo it'll ease adoption of conan and CMake is usually a more familiar tool. For that I would like to keep my predefined presets hence I'm disabling the CMakeToolchain.user_presets_path generation.

My question is about a case where my an option is shared accross the conanfile.py and CMake. I feel I have duplications where I need to map this option from conan to CMake and from CMake to conan (I haven't tries but I guess this is where CONAN_INSTALL_ARGS can be used in my case?). Do you guys have a tool that would mutualize options between conan and CMake?

[memsharded]

Hi @strattist

If you have to manage this in both ways (not very recommended, in general it is better to have one established way to do things, like the Python zen says, "better have one single way of doing one thing"), because you are forced and can't avoid having to define both flows, probably the best ways is to externalize the definition of options to a different file, not the conanfile.py, neither the CMakeLists.txt. For example:

• You could define a myoptions.cmake file with a very well known and fixed structure of option(key value) or set(variable value), that the CMakeLists.txt can include and the conanfile.py can parse and define the options more dynamically
• You could define the options in a yaml or json file, then read it from the conanfile.py and also from the CMakeLists.txt. You could even use the Conan conandata.yml and implement the reading and parsing of it in the CMakeLists.txt.

I also want to be able to have the CMake runs conan for different reason, the most important being imo it'll ease adoption of conan and CMake is usually a more familiar tool.

Our experience is that this is an approach that is at least suboptimal if not problematic.
It is like trying to avoid understading git by using for example a git2svn mapping, so developers don't have to learn git at all and can use their old known subversion commands. Or trying to hide the existence of CMake by using some scripts.

At the end of the days, tools are there, they are a critical part of how software is made, and developers must learn at least the basic usage. Hiding the tools only delays problems, or create bottlenecks where all build failures can be resolved only by 1 or 2 people in the organization, because they are the only ones that touch the build thing. We have seen in general better results and success in teams that embrace and own the tooling (not only Conan, but also CMake itself, the tests, the CI, etc), that the ones that try to hide everything, creating an extra layer of software that has to be also developed, documented, learned and maintained.

Specially in the era of AI/ML, that agents automatically learns how to use tools via MCPs, see for example https://blog.conan.io/mcp/ai/gpt/conan/conan-mcp/2025/12/04/From-Zero-to-Package-in-Seconds-the-new-Conan-MCP.html, this flow where developers need to keep using their same old cmake command only will further increase the competitive advantage of AI agents. And I am in general skeptical about AI/ML, but it is true that things keep improving very fast and there are some impressive results.