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

[POC] Initial cache for CMake #12034

Closed

Conversation

franramirez688
Copy link
Contributor

@franramirez688 franramirez688 commented Sep 5, 2022

Changelog: Feature: Added a conan_intial_cache[_BUILD_TYPE].cmake file to let CMake build helper run cmake -C conan_intial_cache[_BUILD_TYPE].cmake ... and load all the cache variables (-Dxxxx ones passed CLI).
Docs: https://github.com/conan-io/docs/pull/XXXX

@franramirez688 franramirez688 force-pushed the poc/cmake_initial_cache branch from ab1345d to 76a9ec4 Compare September 6, 2022 08:32
conan/tools/cmake/cmake.py Outdated Show resolved Hide resolved
conan/tools/cmake/cmake_initial_cache.py Outdated Show resolved Hide resolved
conan/tools/cmake/cmake_initial_cache.py Outdated Show resolved Hide resolved
Copy link
Contributor

@lasote lasote left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the CMake build helper should still read the CMakePresets instead of the new cache file. Some reasons: You still read the self._generator from there, all the information in the Presets is all you need, and maybe in the future we add some configuration to inherit some presets from the user. So, unless we keep upgrading the CMake build helper reading the CMakePresets it won't work.

In addition to that, the purpose of the CMakePresets regarding tools, IDEs, etc is exactly that, parse the json and call cmake accordingly.

Nevertheless, I consider the new file very useful and a simpler way for the consumer in the command line, with CMake version restrictions, to call it easier, but as a "fail safe" feature in case it cannot use Presets.

Copy link
Contributor

@lasote lasote left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still see the new "cache" too coupled to the "CMake" tool and I think they should be isolated even if they share a bit of code for extracting the information from the "CMakePresets".

conan/tools/cmake/cmake.py Outdated Show resolved Hide resolved
conan/tools/cmake/cmake.py Outdated Show resolved Hide resolved
conan/tools/cmake/cmake.py Outdated Show resolved Hide resolved
conan/tools/cmake/cmake_initial_cache.py Outdated Show resolved Hide resolved
Copy link
Contributor

@lasote lasote left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking better!

@franramirez688 franramirez688 added this to the 1.53 milestone Sep 13, 2022
@franramirez688 franramirez688 marked this pull request as ready for review September 13, 2022 16:56
@czoido
Copy link
Contributor

czoido commented Sep 21, 2022

Finally, we have decided that this should be postponed until we get real feedback of users. The intention of this PR was to cover the case of people using older CMake versions (<3.19) that do not support CMakePresets to let them define the same toolchain cache_variables that are defined in the CMakePresets passing -c initial_cache_vars_file when configuring.
Instead of that, we will output the line with all the -D variables so users can do that manually until we get more feedback about this.

@czoido czoido modified the milestones: 1.53, 2.X Sep 21, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants