[feature] --conf option for CMakeToolchain.user_presets_location

[praetorian20]

What is your suggestion?

Hi, The request is to add a command line option to configure CMakeToolchain.user_presets_location. The functionality I'm looking for was present in the first revision of #11917, but was removed during review.

This is my use case: I have a subset of recipes from conan-center-index in a private repo. We don't plan on making any changes to the recipes. Currently, calling conan create leaves me with a dirty repo because it creates several files under test_package. For instance, with gtest I get

?? recipes/gtest/all/test_package/CMakeUserPresets.json
?? recipes/gtest/all/test_package/build/

I just want to build a binary package and upload it to artifactory, so I don't need CMakeUserPresets to be generated. Being able to set user_presets_location = False from the command line would allow me to avoid having to patch the recipe.

---

I have a related question in this area too. I tried to disable CMakeUserPresets by modifying the recipe but the files are generated regardless (I'm using conan 2.0.0). This is the change I made to the gtest conanfile.py from conan-center-index, what am I doing wrong here?

diff --git a/recipes/gtest/all/conanfile.py b/recipes/gtest/all/conanfile.py
index 198ee6f..4c2da3c 100644
--- a/recipes/gtest/all/conanfile.py
+++ b/recipes/gtest/all/conanfile.py
@@ -118,6 +118,7 @@ class GTestConan(ConanFile):
         if Version(self.version) < "1.12.0":
             # Relocatable shared lib on Macos
             tc.cache_variables["CMAKE_POLICY_DEFAULT_CMP0042"] = "NEW"
+        tc.user_presets_path = False
         tc.generate()

     def _patch_sources(self):

Have you read the CONTRIBUTING guide?

• [X] I've read the CONTRIBUTING guide

[memsharded]

Hi @praetorian20

Thanks for your suggestion.

The configuration for changing user_presets_location was not introduced because changing the location of the presets would be useless, as the presets can't work in other location rather than the CMakeLists.txt folder, so it seems that a conf that would put it in another location wouldn't make sense.

Regarding your attempt for disabling, it seems you disabled it in the conanfile.py, but you would need to disable it in the test_package/conanfile.py instead.

If you do that, and the test_package/conanfile.py contains a layout() method, the files would be generated in a build folder, that should be relatively easy to .gitignore, otherwise maybe the git clean -xdf can be also useful.

[praetorian20]

Hi @memsharded, Thanks for explaining why setting user_presets_path via command line wouldn't work, and for the tip that I need to modify test_package/conanfile.py, of course that was the issue.

Back to the user preset, how about a command line option to disable generation of CMakeUserPresets.json? This would essentially be the same as setting user_presets_path=False in the conanfile.py.

I tried implementing such an option here, I can add unit tests and create a PR if it looks useful.

By setting my disable_user_presets option, I'm able to disable generation of recipes/gtest/all/test_package/CMakeUserPresets.json, but I still have recipes/gtest/all/test_package/build/ directory. Is there any way of controlling conanfile.build_folder externally so I can set it to my CMake binary dir instead?

[praetorian20]

Just want to add that neither of these are terribly important features. As you said, since the names are predictable, it's easy to add them to .gitignore.

[vsaulue]

Hi, I would like to +1 the possibility to disable the generation of a CMakeUserPresets.json in the source tree of the project. For me this isn't a "nice to have" option: it's a fix for an easily workaroundable, but still breaking change from Conan 1.x.

I work on a cross-platform project. In my workflow, I regularly compile the project manually on my local machine and from different local VMs. With Conan 1.x I could use a unique source folder mounted in all the VMs and run builds concurrently without any issue, because builds didn't modify the source tree. With Conan 2.x polluting the source tree with a CMakeUserPresets.json file, concurrent builds from the same source tree cause problems. The preset file left by the last conan install breaks all the other builds.

Anyway that's not a high priority, as for my case the workaround is trivial: remove the problematic preset file after any conan install command.

[rafzi]

I'd like to present a use-case where I don't have a workaround yet. We mount our repo as read-only into a container. We can configure everything to be put outside the mount, but the CMakeUserPresets.json.

The test_package build folders can be set with the profile. Something similar for disabling the user presets file would be nice.

[conf] tools.cmake.cmake_layout:test_folder=/tmp/conan_test_build tools.cmake.cmaketoolchain.do_not_generate_user_presets=true

[memsharded]

Hi @rafzi

I understand that you don't want to fully disable the generation of the CMakeUserPresets.json, because maybe developers need it locally, but you don't find a way to optionally disable the generation for that automatied flow in the container, did I get it right?

[rafzi]

Hi, sorry if that was unclear. The use case is the same as in the OP:

This is my use case: I have a subset of recipes from conan-center-index in a private repo. We don't plan on making any changes to the recipes. Currently, calling conan create leaves me with a dirty repo because it creates several files under test_package. [...]

I just want to build a binary package and upload it to artifactory, so I don't need CMakeUserPresets to be generated. Being able to set user_presets_location = False from the command line would allow me to avoid having to patch the recipe.

with the additional restriction that that repo may be mounted as read-only volume.

[memsharded]

This is my use case: I have a subset of recipes from conan-center-index in a private repo. We don't plan on making any changes to the recipes. Currently, calling conan create leaves me with a dirty repo because it creates several files under test_package. [...]

Got it, thanks for the feedback. As a possible quick workaround, using conan create . -tf="" will inhibit running the test_package. It is not ideal, but at least you will be able to move forward today.