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

[feature] CMakeDeps: define IMPORTED_LINK_INTERFACE_LANGUAGES in case of static C++ lib #14607

Closed
1 task done
SpaceIm opened this issue Aug 29, 2023 · 1 comment · Fixed by #16964
Closed
1 task done

Comments

@SpaceIm
Copy link
Contributor

SpaceIm commented Aug 29, 2023

What is your suggestion?

Config files generated by CMakeDeps have several flaws compared to regular CMake config files generated by CMake.
One of them is that they miss IMPORTED_LINK_INTERFACE_LANGUAGES "CXX" property in case of C++ static lib (see also this summary I made in #13560 (comment)).

When this property is missing, linking a static C++ lib with C API into a pure C executable or shared lib can't work out of the box -while it should with a proper CMake config file (information comes transitively from imported target linked into C executable or shared lib)- because CMake doesn't know that it should use C++ linker.

Currently, package_info() doesn't provide a way to specify which lib in a recipe is a C++ lib, nor if it's static or not (though for this one there is the global shared option, or package_type value eventually but it's not sufficient when there are components which might not be all shared or static), so it's a little bit hard to implement such feature without some improvements in package_info() and an abstraction allowing to specify if a component refers to a C or C++ lib.

Have you read the CONTRIBUTING guide?

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

We are releasing in Conan 2.9 a completely new CMakeDeps generator in #16964 that has closed this ticket, with many pending features and fixes:

  • Allow defining cpp_info.default_components and using that information to generate CMake targets by default for packages
  • Allow defining cpp_info.exe to model executable imported targed generation
  • Creating always actual SHARED/STATIC/INTERFACE imported targets, with their IMPORTED_LOCATION, the IMPORTED_IMPLIB, the IMPORTED_CONFIGURATIONS
  • This solves issues with try_compile and other CMake source-compiling checks
  • No artificial library or package targets
  • Allow using the package languages attribute or a new cpp_info.languages information to define IMPORTED_LINK_INTERFACE_LANGUAGES
  • Define config files for executable targets for the "build" context automatically, without any special configuration
  • Use the correct CONFIGURATION from the package instead of the consumer one
  • Generate a new conan_cmakedeps_paths.cmake file, that can be used for integrations that cannot use a CMakeToolchain, like cmake-conan
  • Allow using executable targets from the host context if not cross-building (and not tool-requires that would prioritize those executable targets)

Current known pending functionality (to be added soon):

  • Not managing Apple frameworks
  • Not generating find modules, only CMake Config files

The new CMakeDeps generator is intended for testing and validation only, being a transparent replacement of the old one, so it is behind a new conf. To use it, use the -c tools.cmake.cmakedeps:new=will_break_next, and that will use the new generator instead of the old one. Note the will_break_next value means exactly that, that value will change in next release to force a break, so no one can depend on this generator in production yet.

Your feedback is very important

As this is a major change, we will only remove the conf gate when we get confirmation from users that it works and solve the issues. Please try the new generator for your project, and let us know if it works. If it doesn't, please re-open this ticket and let us know what failed. Thanks very much!

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 a pull request may close this issue.

2 participants