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.

Sign up for GitHub

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

Jump to bottom

[feature] expose CMakeToolchain conf to be able to set CMAKE_GENERATOR_INSTANCE #16222

Closed
1 task
jcar87 opened this issue May 8, 2024 · 1 comment · Fixed by #16242
Closed
1 task

[feature] expose CMakeToolchain conf to be able to set CMAKE_GENERATOR_INSTANCE #16222

jcar87 opened this issue May 8, 2024 · 1 comment · Fixed by #16242
Assignees
@jcar87 @perseoGI
Milestone
2.4.0

Comments

@jcar87
Copy link
Contributor

jcar87 commented May 8, 2024

What is your suggestion?

When the CMake generator is a Visual Studio one, for example Visual Studio 17 2022 (see docs https://cmake.org/cmake/help/latest/manual/cmake-generators.7.html#visual-studio-generators), there are systems in which there are multiple instances of Visual Studio 2022 installed, for example:

  • Visual Studio Community and Professional can be installed side by side
  • Visual Studio Preview can be installed in addition to the "official" release

When not specified, CMake decides, as per documentation:

If the value of CMAKE_GENERATOR_INSTANCE is not specified explicitly by the user or a toolchain file, CMake queries the Visual Studio Installer to locate VS instances, chooses one, and sets the variable as a cache entry to hold the value persistently.

Each installation of Visual Studio can have different toolsets installed:

  • for example, we can have the v142 toolchain installed in Visual Studio 2022 Professional, but not in the community one
  • or we could have the v143 with MSVC 19.40 installed in Visual Studio 2022 preview, not but in Visual Studio 2022 Community

So we could end up with scenarios where the Conan profiles specify settings that can only be satisfied by one particular instance of Visual Studio, but then CMake doesn't choose that instance by default.

Proposed solution:

  • expose a conf tools.cmake.cmaketoolchain:generator_instance, such that if defined, conan_toolchain.cmake will contain an entry setting CMAKE_GENERATOR_INSTANCE with the value provided by the user

Have you read the CONTRIBUTING guide?

  • I've read the CONTRIBUTING guide
perseoGI added a commit to perseoGI/conan that referenced this issue May 8, 2024
@perseoGI
Added support for setting CMAKE_GENERATOR_INSTANCE (conan-io#16222)
b32bd70
@perseoGI perseoGI mentioned this issue May 9, 2024
Closed
@memsharded
Copy link
Member

I have been reviewing #16229, but then I had recall that we had discussed this policy before:

  • We don't want to add a new conf item for every CMake variable that a toolchain can defined.
  • We already defined a mechanism for users to inject any custom CMake variable they want, that is, injecting their own tools.cmake.cmaketoolchain:user_toolchain
  • The only inconvenience is that it is not directly encoded in a profile, but it requires a my.cmake toolchain file.

I have rejected feature requests from users very similar to this one.
What is different in this CMAKE_GENERATOR_INSTANCE that it deserves its own conf? Wouldn't the user toolchain be a viable solution?

perseoGI added a commit that referenced this issue May 13, 2024
@perseoGI
Added support for tools.cmake.cmaketoolchain:extra_variables (#16222)
033e2e0
@perseoGI perseoGI mentioned this issue May 13, 2024
Merged
5 tasks
perseoGI added a commit that referenced this issue May 13, 2024
@perseoGI
Added support for tools.cmake.cmaketoolchain:extra_variables (#16222)
d0491bd
perseoGI added a commit that referenced this issue May 21, 2024
@perseoGI
Added support for tools.cmake.cmaketoolchain:extra_variables (#16222)
21c4a86
RubenRBS pushed a commit to RubenRBS/conan that referenced this issue May 21, 2024
@perseoGI @RubenRBS
Added support for tools.cmake.cmaketoolchain:extra_variables (conan-i…
1400093 
…o#16222)
RubenRBS pushed a commit to RubenRBS/conan that referenced this issue May 21, 2024
@perseoGI @RubenRBS
Added support for tools.cmake.cmaketoolchain:extra_variables (conan-i…
9b53abd 
…o#16222)
perseoGI added a commit that referenced this issue May 29, 2024
@perseoGI
Added support for tools.cmake.cmaketoolchain:extra_variables (#16222)
7360e38
memsharded pushed a commit that referenced this issue Jun 3, 2024
@perseoGI
Added support for tools.cmake.cmaketoolchain:extra_variables (#16242)
e7b87a3 
* Added support for tools.cmake.cmaketoolchain:extra_variables (#16222)

* Moved extra_variable from GenericSystemBlock to new block which will be executed later

* Moved extra variables just before the try_compile block.

This will allow users to re-define variables

* Added extra parse layout for cmaketoolchain:extra_variables

Now it admits not only plain key:value pairs but dictionary values in
the form:
{'value': <value>, 'cache': <true/false>, 'type': <cache_type>, 'docstring': <cache docstring> }

* Fix comments
@memsharded memsharded added this to the 2.4.0 milestone Jun 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@jcar87 jcar87

@perseoGI perseoGI

Labels
None yet
Projects
None yet
Milestone
2.4.0
3 participants
@jcar87 @memsharded @perseoGI