[question] Packaging prebuilt projects with existing FooConfing.cmake and Generating Multiple CMake Presets

[sufuk]

What is your question?

Hello,

I apologize for my lack of English,
We use conan to package manage our projects that use cmake and are used in various operating systems (macos, linux, android) and architectures (arm64, x86_64, x86, armv7, armv6). We can only use Conan for already compiled binaries because we need complex build systems to compile projects and even have to use docker for armv6 because the GCC version we use is extremely old (4.2.3) and the toolchain can only run on x86 Linux.

While developing the projects, we wrote a script that loads these packages with conan for all architectures and operating systems and creates a CMakePresets.json containing separate presets for each configuration. The presets contain their own FOO_DIR cache values.

The problem is that we need to rewrite this script for each project, and we cannot use CMakeToolChain or CMakeDeps because the presets they create are for only one configuration.

I wonder if there is a way to force CMakeToolChain and CMakeDeps to create presets for multiple configurations?

Also we don't want to edit our CMake files for conan and we dont want to use conan as a build tool because cmake do this excellently and we are not comfortable to depend on conan entirely even if its self hosted.

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[memsharded]

Hi @sufuk

I apologize for my lack of English,

Not an issue! 🙂

I wonder if there is a way to force CMakeToolChain and CMakeDeps to create presets for multiple configurations?

I am not sure what is the issue. CMakeToolchain and CMakeDeps are already multi-config generators, they can handle multiple configurations without overwriting each other, and they can generate multiple folders for the builds and multiple different presets.

You can see in https://docs.conan.io/2/examples/tools/cmake/cmake_toolchain/build_project_cmake_presets.html, how it works for multi-config, but the same approach also works for more configurations, by defining the conf tools.cmake.cmake_layout:build_folder_vars (it can also be defined as self.folders.build_folder_vars in the recipe), check for example https://docs.conan.io/2/reference/tools/cmake/cmake_layout.html

Also we don't want to edit our CMake files for conan and we dont want to use conan as a build tool because cmake do this excellently and we are not comfortable to depend on conan entirely even if its self hosted.

Sure, Conan is not a build system, it is not a build tool, it just wraps and call Conan when necessary. Having a conanfile.py with a build() method that calls cmake.build() and it is still doing the same old cmake --build ... that you would do by hand. And it also works for the developers doing conan install + cmake --preset= ....

All the CMakeToolchain + CMakeDeps integration is designed to work without having to modify at all any CMakeLists.txt.

Conan can also work with xxx-config.cmake files inside packages, with some limitations (mostly due to cmake), please check: https://docs.conan.io/2/examples/tools/cmake/cmake_toolchain/use_package_config_cmake.html

So I'd say that things should work as you desire. If there is something that is not behaving like you expect, the best would be to put a simple and minimal reproducible example in a repo, so we can check it, reproduce and advice. Like some toy example conanfile.py recipes and the commands necessary to reproduce.

[sufuk]

Hello @memsharded

Thank you for your response,
I will try again with your recommendations and keep update the thread.

[sufuk]

Hello again @memsharded
It seems conan overrides configure presets every time when conan install is called. Is there a way to bypass this ?

# Conan generated presets should have only 1 configurePreset, no more, overwrite it
https://github.com/conan-io/conan/blob/7e0f025fd7a4b134241ae8d3d353118795bd6c19/conan/tools/cmake/presets.py#L180C2-L192C80

[memsharded]

The CMakePresets.json shouldn't be overriden if the right layout() definition is provided (or it should only be overriden when modeled as such). If the layout definition is correct, new presets will be added/appended to the existing ones, not overriding them.

The CMakeUserPresets.json might be overriden to point to the actual CMakePresets.json, but only if the CMakeUserPresets.json doesn't exist or was created by Conan (conan vendor field).

So I am not sure what could be happening, we would need to have something we could reproduce to understand the issue. Thanks!

[sufuk]

The CMakePresets.json shouldn't be overriden if the right layout() definition is provided (or it should only be overriden when modeled as such). If the layout definition is correct, new presets will be added/appended to the existing ones, not overriding them.

The CMakeUserPresets.json might be overriden to point to the actual CMakePresets.json, but only if the CMakeUserPresets.json doesn't exist or was created by Conan (conan vendor field).

So I am not sure what could be happening, we would need to have something we could reproduce to understand the issue. Thanks!

Ok I will try to make an reproducable example just to be sure My generator is not in Mutli config gens

is this affect this?

[memsharded]

It depends, if you are in Windows with msvc, by default it will be multi-config, because CMake Visual Studio generator is multi-config.

This is why the reproducible case is important, clarifying the files used, the commands, and also the inputs (OS, compiler), and reporting on the full output...

[sufuk]

Hello @memsharded it turns out key is using tools.cmake.cmake_layout:build_folder_vars="['settings.os', 'settings.arch']"
That way Any of the configureations (CMakePresets.json)doesn't overwrite each other, and I dont do anything special for CMakeUserPresets.json but it doesnt overwritten it appends new configurations just like I wanted. Now I can
configure my projects in same works space for android-(armv7, arm64, x86, x86_64), linux, macos.

I have only one question it not a problem I fixed it for me in conanfie.py generator method, but is there any way to use relative paths for for example toolchainFile in the CMakePresets.json and include paths for presets in User Preset file?

[memsharded]

t turns out key is using tools.cmake.cmake_layout:build_folder_vars="['settings.os', 'settings.arch']"
That way Any of the configureations (CMakePresets.json)doesn't overwrite each other, and I dont do anything special for CMakeUserPresets.json but it doesnt overwritten it appends new configurations just like I wanted. Now I can
configure my projects in same works space for android-(armv7, arm64, x86, x86_64), linux, macos.

Excellent, I am happy that my suggestion above (tools.cmake.cmake_layout:build_folder_vars (it can also be defined as self.folders.build_folder_vars) helped, thanks for the follow up!

I have only one question it not a problem I fixed it for me in conanfie.py generator method, but is there any way to use relative paths for for example toolchainFile in the CMakePresets.json and include paths for presets in User Preset file?

Yes, we try to make paths relative whenever possible, to allow some relocatibility. I am not sure why these paths are not relative, maybe it doesn't work, but we can give it another try.

[sufuk]

t turns out key is using tools.cmake.cmake_layout:build_folder_vars="['settings.os', 'settings.arch']"
That way Any of the configureations (CMakePresets.json)doesn't overwrite each other, and I dont do anything special for CMakeUserPresets.json but it doesnt overwritten it appends new configurations just like I wanted. Now I can
configure my projects in same works space for android-(armv7, arm64, x86, x86_64), linux, macos.

Excellent, I am happy that my suggestion above (tools.cmake.cmake_layout:build_folder_vars (it can also be defined as self.folders.build_folder_vars) helped, thanks for the follow up!

I have only one question it not a problem I fixed it for me in conanfie.py generator method, but is there any way to use relative paths for for example toolchainFile in the CMakePresets.json and include paths for presets in User Preset file?

Yes, we try to make paths relative whenever possible, to allow some relocatibility. I am not sure why these paths are not relative, maybe it doesn't work, but we can give it another try.

Hello @memsharded thanks four your quick response again with absolute paths It is impossible to call conan install in the host and built project in the docker container(Mounted conan cache of host and project dir), but with relative paths it works quite good, I didn't see any problem,

[memsharded]

Hi @sufuk

I have opened PR #16015 to make these paths relative in the generated presets.
If you could run your project from source from my branch to validate it in your case, that would be great.

[memsharded]

#16015 has been merged and has closed this issue. It will be in next Conan 2.3.

If there is any further issue, please create a new ticket, thanks!