[feature] Consider passing the buildenv via CMake Presets

[jcar87]

What is your suggestion?

CMake presets allow setting the environment that is "activated" during the CMake run: https://cmake.org/cmake/help/latest/manual/cmake-presets.7.html#id4

For example:

      "environment": {
        "MY_ENVIRONMENT_VARIABLE": "Test",
        "PATH": "$env{HOME}/ninja/bin:$penv{PATH}"
      },

Currently, in Conan it is advised to 'activate' the run environment:

source ./Release/generators/conanbuild.sh
generators\conanbuild.bat
# (and the one for powershell)

if we are able to gather the information and express it in the generated CMake presets by Conan, the workflow could be the same for all platforms:

conan install .
cmake --preset conan-release
cmake --build --preset conan-release

and it would do TheRightThing ™️

this would narrow the gap of having to run different commands on Windows / macOS / Linux depending on whether the generator is multi-generator, without multigenerator, or whether we are using windows cmd prompt, powershell, or bash. Just some quality of life imprvement

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[memsharded]

Hi @jcar87

Maybe this would be a duplicate of #14271?

[thorntonryan]

To help aid in discussion, some good points about this topic were brought up here:

• [question] How to pass cmake configuration option with modern conan? #10515 (comment)
• [question] How to pass cmake configuration option with modern conan? #10515 (comment)

CMake Preset support was introduced in CMake 3.19, but Conan 2.x wants to target CMake 3.15.

If I follow, this means that the Conan CMake build helper couldn't use cmake --preset , but as @puetzk pointed out, the build helper could still parse the CMakePresets.json file containing the buildenv info and preserve compatibility with CMake 3.15 while allowing folks using newer versions the opportunity to use/include the CMakePresets.json file directly.

[memsharded]

Yes, the feature cannot be exclusive, in the sense that the integration relies on having CMake>=3.19 for all cases.
But that doesn't mean that the feature cannot be implemented and users with a modern CMake>=3.19 can enjoy it.

The solution cannot be just using the CMake build helper, because that means that a flow with conan install + activate environment + cmake ... cannot work and it will always require to call conan build, which is a no-go for all users doing local development, with an IDE; etc. So for older CMake versions, it is likely that the flow with the conanbuild virtualenv.

[puetzk]

I think Ryan was just nodding at the general principle that the CMake helper could do things its own way (e.g. conanbuild.sh), and remain compatible down to CMake 3.15, while the preset file carries the information to let an modern CMake using --preset (or IDE with similar support) obtain an equivalent information configuration/environment etc.

[puetzk]

For this specific case, it seems like one would also want runenv (i.e. bindirs of requirments in profile:host) would also make it into a test preset, so that IDE features like a unit test runner can work with requires that had shared .dll (or .so) libraries in them. This again parallels the way the conan.tools.cmake helper overlays the runenv on top of the buildenv for CMake.test().

[memsharded]

#15192 has added environment to CMakePresets, it will be released in 2.0.15, feedback welcome