Defining self.cpp_info.name for a package changes (at least) two file names: cmake module FindFOO files, and pkg-config files. The problem is that in the wild, the name used for cmake module files and pkg-config files are not always identical, for example zlib has FindZLIB, but zlib.pc, and expat has FindEXPAT but expat.pc.
recipes consuming these two packages via pkg-config are broken since these two recipes set self.cpp_info.name to uppercase, the workaround being to rename generated ZLIB.pc to zlib.pc and EXPAT.pc to expat.pc.
If pkg-config files are always the lower-case version of corresponding findFOO cmake file, the simplest fix would be to modify pkg-config generator to use self.cpp_info.name.lower() instead of self.cpp_info.name. If not, a solution would be to make self.cpp_info.name a dictionary mapping generators to name.
Is it possible that this is addressed by https://github.com/conan-io/conan/pull/5973? this will be released in 1.19.3 asap.
I don't think so
@ericLemanissier is the casing of the name of the lib (zlib) different inside the file? I mean, the issue is just the file name or the name of the lib inside the contents of that file too?
More generally it seems that we are currently setting self.cpp_info.name to match what we need for CMake to work, but we've got no guarantee that the case will be the same for every build system. Inconsistencies and related issues are very likely.
The library name appears in the pkg-config file, and is currently in uppercase, but it does not seem to have an impact(renaming the file without modifying content solves the problem). According to https://people.freedesktop.org/~dbn/pkg-config-guide.html, name is A human-readable name for the library or package. This does not affect usage of the pkg-config tool, which uses the name of the .pc file.
Thanks @ericLemanissier!
How to handle case where cmake and pkgconfig file have not the same name. For example, freetype generate "freetype2.pc" and "freetype-config.cmake", and CMake provide FindFreetype.cmake.
cpp_info.name should be Freetype when use cmake{*} generator, but freetype2 when use pkg_config generator.
I think for that case we might think of a feature that will define different names for different build systems, like a dict system-name, instead of a single name.
You would probably have to keep a default name as well for backward compatibility with already written recipes.
I'm not a guru python coder, but, I think we can implement a class that accept self.cpp_info.name (default value) and self.cpp_info.name['my_generator'], and return default value when generator value is not found.
Hi @ledocc
I'm not a guru python coder, but, I think we can implement a class that accept self.cpp_info.name (default value) and self.cpp_info.name['my_generator'], and return default value when generator value is not found.
yes, this is definitely the way to go. I'd suggest it as a feature for the next 1.21 release.
Hi @memsharded
This bug break the build of package that use freetype, and probably others, in conan-center-index.
Can you keep it in 1.19.3 release ?
I can provide a PR in few days.
It is being released.
This issue is not fixed by https://github.com/conan-io/conan/pull/5988 (eg freetype2 vs freetype is not a simple case change).
EDIT: ok, I did not realize that this feature was tracked in https://github.com/conan-io/conan/issues/5993
Hi @ledocc
Sorry, but 1.19.3 is already out. There were things to be released that couldn't wait.
And Conan 1.20 is to be opened very soon.
The issue #5993 is tracking this, please follow conversation there. Conan-center-index is still in EAP (not stable), but in any case we will try to release this fix fast, so no hurries, but please keep us updated if you are able to provide that PR. Many thanks!
Most helpful comment
The library name appears in the pkg-config file, and is currently in uppercase, but it does not seem to have an impact(renaming the file without modifying content solves the problem). According to https://people.freedesktop.org/~dbn/pkg-config-guide.html, name is
A human-readable name for the library or package. This does not affect usage of the pkg-config tool, which uses the name of the .pc file.