[ Conan2 Library Types] Allow explicit library types in libs definition

[Untzelmann]

What is your suggestion?

Hey,

some libraries have some way of defining libraries, that can not modeled by the current scripts generated by CMake Deps. Looking at the recipe of Qt, the names of the plugins do not even show up in the generated CMake files.

Also some libraries contain static or shared libraries, independent of the recipe configuration.

CMake allows the 4 library types:

• Configuration (Static or Shared, depending on CMake BUILD_SHARED_LIBS),
• Static (Always)
• Shared (Always),
• Module (only runtime library, see Qt Plugin)

However in a recipe, we can not model this behaviour, currently only the first one (Configuration) can be specified. If a
CMake file defines the library as always SHARED (by doing add_library(Lib SHARED)), the corresponding DLL files can not be found, if the conan package is not build as a shared module. On the same hand, if a conan package is build as shared and a library was defined as always static, it reports, that the DLL could not be found. Modules, that only have a DLL file on windows can not be found at all by the current generator.

Additionally, currently it is assumed, that the name of the DLL file always matches the .lib file in windows. However, for some projects this does not match. For example zlib generates the lib file zdll.lib, however the DLL is named zlib1.dll. In this case the recipe could be adjusted, but it might be that DLL and lib file have different names, which can not be modeled.

I would propose this to address this issue:

• Add the 4 library types to the cpp_info.libs

For example:

cpp_info.libs = [
"static_or_shared", <- As defined now. The generator will assume shared for shared and static for static libraries
SharedLib("zdll", "zlib1"), <- Explicitly define a shared library, optionally with a name of the DLL file on windows
StaticLib("libstatic"), <- Explicitly define a static library. The library is always static independent of configuration
PluginLib("qsqlpsql", "sqldrivers") <- Define a module/plugin library. Only expect a DLL or .so file. Provide a sync path, that is relative to the plugin directory. The generator could search only the DLL and provide a target parameter to be able to provide a desired location for syncing
]

So the libs could take in 4 types: str, SharedLib, StaticLib and PluginLib

This way the qt recipe could define the plugin locations better. Including a location where they should be put in an installer. The zlib recipe could define their shared library configuration on windows.

What do you think about this idea? Is there already a better way and the recipes are not up-to-date? Or is that something you would support?

If this proposal is accepted, I would be happy to implement that.

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[memsharded]

Hi @Untzelmann

Thanks very much for your suggestion.
Indeed, this is something that we have thought for some time, related to this one #13018. We need better modeling of libraries to be able to specify CMake target properties, for example, in the CMakeDeps generator.

This is not an easy feature, but is important, so assigning it to our roadmap 2.X.

[SpaceIm]

I guess #12815 is connected.