There is an existing CMake project I want to improve for easier development experience on non-production platforms (production is Debian, development is anything from Ubuntu to Mac on Apple silicon) and CI.
CLion plugin is generating conanbuild.py and adds -DCMAKE_PROJECT_TOP_LEVEL_INCLUDES="conan_provider.cmake" to the CMake command line.
Ideally, I'd love to have a static conanbuild.txt committed into the repo, have developer (or CI pipeline) to manually run conan install ... and from that point on just have CMake do the right thing. And have the setup future-proof, not orthogonal to how majority of project use Conan with CMake.
Am I thinking in the right direction with conanbuild.txt? How to get it to agree on the build dirs naming convention between CLion and Conan?
Apologies for a bit vague formulation, still scoping the topic.
If the intention is to recover control and use your own written conanfile, and use conan install, then neither the CLion plugin nor the cmake-conan integration (the one using the conan_provider.cmake file) are really necessary.
The normal conan install command, when using the CMakeToolchain generator will create some files, like the conan_toolchain.cmake and CMakePresets.json file (and possibly a CMakeUserPresets.json file too). These files can be automatically used by different IDEs, for example VSCode with the cmake-tools can automatically load and use existing presets files.
CLion can also use these generated presets file for the build, it might be possible to specify the presets in the IDE