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] Why does CMakeToolchain's cache_variables convert recipe options to CMake bool but variables converts them to strings? #14590

Closed
1 task done
tgurriet opened this issue Aug 28, 2023 · 4 comments
Milestone

Comments

@tgurriet
Copy link

tgurriet commented Aug 28, 2023

What is your question?

Hello,

While exploring the files generated by the CMakeToolchain generator, I realized that when assigning an option to cache_variables, it resulted in a CMake boolean variable in the CMakePresets.json, wherease passing the same option to variables generated a CMake string variable in the conan_toolchain.cmake.

Is there a reason for that difference? I couldn't find anything in the doc about this.

The recipe:

from conan import ConanFile
from conan.tools.cmake import CMakeDeps, CMakeToolchain, cmake_layout

class helloRecipe(ConanFile):
    name = "my_lib"
    version = "1.0"

    settings = "os", "compiler", "build_type", "arch"
    options = {"option": [True, False]}
    default_options = {"option": True}
    exports_sources = "CMakeLists.txt", "src/*", "include/*"

    def layout(self):
        cmake_layout(self)

    def generate(self):
        dep = CMakeDeps(self)
        dep.generate()

        tc = CMakeToolchain(self)
        tc.variables["option"] = self.options.get_safe("option")
        tc.cache_variables["option"] = self.options.get_safe("option")
        tc.variables["option2"] = self.options.option
        tc.cache_variables["option2"] = self.options.option
        tc.variables["option3"] = True
        tc.cache_variables["option3"] = True
        tc.generate()

The generated CMakePresets.json:

...
"cacheVariables": {
  "option": "ON",
  "option2": "ON",
  "option3": "ON",
  "CMAKE_POLICY_DEFAULT_CMP0091": "NEW",
  "CMAKE_BUILD_TYPE": "Debug"
},
...

The generated conan_toolchain.cmake:

...
# Variables
set(option "True" CACHE STRING "Variable option conan-toolchain defined")
set(option2 "True" CACHE STRING "Variable option2 conan-toolchain defined")
set(option3 ON CACHE BOOL "Variable option3 conan-toolchain defined")
...

Have you read the CONTRIBUTING guide?

  • I've read the CONTRIBUTING guide
@tgurriet tgurriet changed the title [question] Why does CMakeToolchain's cache_variables convert options to CMake bool and variables doesn't? [question] Why does CMakeToolchain's cache_variables convert recipe options to CMake bool and variables converts them to strings? Aug 28, 2023
@tgurriet tgurriet changed the title [question] Why does CMakeToolchain's cache_variables convert recipe options to CMake bool and variables converts them to strings? [question] Why does CMakeToolchain's cache_variables convert recipe options to CMake bool but variables converts them to strings? Aug 28, 2023
@tgurriet
Copy link
Author

tgurriet commented Sep 5, 2023

@memsharded Should I generate a bug report with more info maybe?

@franramirez688
Copy link
Contributor

Hi, @tgurriet - Thanks a lot for the report.

Yes, this is known. CMakeToolchain has a mechanism to convert raw options for the cache_variables attribute, but not for the variables one.
Let me discuss with the team this issue to see which would be the best approach.

@tgurriet
Copy link
Author

Sounds good, thanks!

@memsharded
Copy link
Member

We have been checking this:

  • yes, there are some small differences in how variables and cache_variables are managed
  • This are mostly historical differences
  • We have considered trying to align a bit more the behavior, but it seems it would be breaking, so most likely not worth it.

The solution to make them behave similar would be to force the bool() type for variables when desired.

I am closing this ticket as responded, but please re-open or create a new one for any further question.

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

4 participants