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

Do not enforce using explicit build types with cmake_multi. #7376

Merged
merged 1 commit into from Aug 30, 2020

Conversation

rasjani
Copy link
Contributor

@rasjani rasjani commented Jul 17, 2020

cmake_multi enforced existence of conanbuildinfo_release.cmake &
conanbuildinfo_debug.cmake had to be present or the build would fail if
conanbuildinfo_multi.cmake was loaded. This is now changed so that
only generated conanbuildinfo files are loaded.

Fixes #7253

Changelog: Fix: Avoid requiring the existence of all conanbuildinfo_xxx.cmake files in cmake_multi generator.
Docs: Omit

  • Refer to the issue that supports this Pull Request.
  • If the issue has missing info, explain the purpose/use case/pain/need that covers this Pull Request.
  • I've read the Contributing guide.
  • I've followed the PEP8 style guides for Python code.

Note: By default this PR will skip the slower tests and will use a limited set of python versions. Check here how to increase the testing level by writing some tags in the current PR body text.

cmake_multi enforced existence of conanbuildinfo_release.cmake &
conanbuildinfo_debug.cmake had to be present or the build would fail if
conanbuildinfo_multi.cmake was loaded. This is now changed so that
only generated conanbuildinfo files are loaded.

Fixes conan-io#7253
@memsharded memsharded added this to the 1.29 milestone Aug 3, 2020
jgsogo
jgsogo approved these changes Aug 13, 2020
Copy link
Contributor

@jgsogo jgsogo left a comment

LGTM

@memsharded memsharded merged commit bd0da4d into conan-io:develop Aug 30, 2020
2 checks passed
@memsharded
Copy link
Member

memsharded commented Aug 30, 2020

This had a reason at the moment, mostly to protect users that did install other configurations later, after cmake project generation, that weren't being automatically loaded without regenerating. I agree this was mostly an anti-feature, better to be more flexible and allow users to do what they want without unnecessarily protecting them.

Thanks very much for contributing this.

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

Successfully merging this pull request may close these issues.

[bug] cmake_find_package_multi generator should not enforce that certain buildtypes are used.
3 participants