Add cmake_extra_variables property for CMakeConfigDeps and CMakeDeps

[AbrilRBS]

Changelog: Feature: Add cmake_extra_variables property for CMakeConfigDeps.
Changelog: Feature: Add cmake_extra_variables property for CMakeDeps.
Docs: conan-io/docs#4257

Closes #18683, this comes from a discussion with the team where it could help around some shortcomings in a few CCI recipes

[memsharded]

Looks good to me.

[memsharded]

Maybe we need to provide this for CMakeDeps as well? As CMakeConfigDeps will still take a bit to be production ready, do we want to have this available for ConanCenter sooner?

[AbrilRBS]

Note quite sure if the config is the best place for this, I write them here for symmetry with CMakeConfigDeps where they are written next to the cmake_additional_variables_prefixes too, maybe we want to move them elsewhere?

[jcar87]

I would probably suggest:

• cmake_config_variable_definitions to reflect what it actually is

And my only comment is to make sure that we generate these variables (the set(....) invocations) in the -config.cmake rather than the files included by it. I'm not sure I would bother with the find modules in the legacy CMakeDeps

[memsharded]

I would probably suggest:
cmake_config_variable_definitions to reflect what it actually is

It was named cmake_extra_variables to align with the conf tools.cmake.cmaketoolchain:extra_variables, because it has a very similar meaning, from the consumer point of view is mostly the same.
But then it is true that it could create some expectations about priority/precedence, overwriting from profiles, etc., which is not happening, it is processed separately.
I think that we should better analyze these possible collisions and expectations, might need some reworking because I think it can create user frustration if users define tools.cmake.cmaketoolchain:extra_variables, but that is ignored because some dependency is defining the same variables and they take precedence, contradicting the Conan principle that the "downstream user" should have control.
I am moving this to next release to analyze this with @AbrilRBS

And my only comment is to make sure that we generate these variables (the set(....) invocations) in the -config.cmake rather than the files included by it. I'm not sure I would bother with the find modules in the legacy CMakeDeps

Yes ,this is already this way in CMakeDeps, and there is the ticket #18836 to do it for CMakeConfigDeps (but this goes together with moving the legacy xxx_INCLUDEDIRS variables, so better do it separately.

[jcar87]

tools.cmake.cmaketoolchain:extra_variables cause variables to be defined in the Toolchain, not the config file. It should very very rarely and exceptionally be used in the package_info() of a recipe

the recommendation for what variables should be covered by tools.cmake.cmaketoolchain:extra_variables should be: "whatever cmake recommends or requires to be defined in a toolchain file", and nothing else.

so it's probably okay for a toolchain related recipe (e.g. if I have a recipe for a compiler, or a build tool, and there's something for convenience that I'd like users to generate in a toolchain file), but less okay to use in a recipe for a library (our goal for this is to match upstream config files generated by the project, and those cannot define variables for a toolchain (obviously, as by the time you reach find_package, project() has already run).

There are no uses of tools.cmake.cmaketoolchain:extra_variables in Conan Center.

The only concern would be, users relying on tools.cmake.cmaketoolchain:extra_variables in their own recipes because the feature in this PR does not exist yet.

[memsharded]

tools.cmake.cmaketoolchain:extra_variables cause variables to be defined in the Toolchain, not the config file. It should very very rarely and exceptionally be used in the package_info() of a recipe

Yes, it is very rarely used there, it is not the intention. But it is widely used by users defining it in profile files.
I am not concerned about recipes defining tools.cmake.cmaketoolchain:extra_variables in its conf_info for their consumers.

My concern is a user defining tools.cmake.cmaketoolchain:extra_variables in their profile for example CMAKE_SOME_VAR, and their provided value being ignored because there is a package up the graph that defines the new cmake_extra_variables property in its package_info, and it defines the same CMAKE_SOME_VAR variable, but with a different value.

If this is the case, at this moment, the dependency value will have priority over the profile value, which is unexpected and can be frustrating for users.

[memsharded]

Yes, I think this approach is a bit more understandable than the other with CMake vars 👍