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

Open
1 task done
SpaceIm opened this issue Aug 29, 2023 · 0 comments · May be fixed by #16314
Open
1 task done

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

SpaceIm opened this issue Aug 29, 2023 · 0 comments · May be fixed by #16314

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 memsharded linked a pull request May 21, 2024 that will close this issue
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.

1 participant