Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[question] Should cmake_additional_variables_prefixes generate {{prefix}}_FOUND and {{prefix}}_VERSION? #17483

Open
1 task done
AbrilRBS opened this issue Dec 17, 2024 · 2 comments

Comments

@AbrilRBS
Copy link
Member

AbrilRBS commented Dec 17, 2024

What is your question?

In conan-io/conan-center-index#26063, a gap in the current CMakeDeps cmake_additional_variables_prefixes property shows up:

  • Upstream defines uppercase variants of the FOUND and VERSION variables, alongside the rest of them, so I used cmake_additional_variables_prefixes to generate those.
  • This works great, up until the point where any of the FOUND/VERSION variables is used. Conan does not generate them by default, leaving CMake to do it on its own

But a issue arises as cmake_additional_variables_prefixes does not generate extra versions of FOUND and VERSION, which forces me to define them in the CMakeToolchain to make the recipe compile

cc/ @franramirez688

Have you read the CONTRIBUTING guide?

  • I've read the CONTRIBUTING guide
@memsharded
Copy link
Member

Just to make sure, the _FOUND variables are only generated for the modules, but not for Config files:

{% if is_module %}
        include(FindPackageHandleStandardArgs)
        set({{ file_name }}_FOUND 1)

Is this issue related to modules? Does curl uses zstd by default using a module and not a config.cmake file?

@valgur
Copy link
Contributor

valgur commented Dec 18, 2024

The issue is quite widely applicable, I would say. There's a number of recipes on CCI that export a CMake config and also upper-case CMake vars:

Also, a sizable fraction of patches on CCI are for injecting Conan dependencies into CMake projects, where the project does something like find_package(Eigen ...) and then continues to use it like if(EIGEN_FOUND) .... It could be worked around by setting deps.set_property("eigen", "cmake_find_mode", "module"), but it would be great if that could be avoided.

On the other hand, generating XYZ_FOUND and XYZ_VERSION might indeed be somewhat difficult for CMakeDeps, since it's something that is handled by CMake itself, usually.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants