Repository: conan-io/conan-center-index

Issue:
[package] protobuf/3.20.0: Mismatched library names between debug and release
<!-- 
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.
-->

### Package and Environment Details (include every applicable attribute)
  * Package Name/Version: **protobuf/3.20.0**
  * Operating System+version: **Windows 10 x64**
  * Compiler+version: **MSVC 17**
  * Conan version: **conan 1.47.0**
  * Python version: **Python 3.9.7**

### Steps to reproduce (Include if Applicable)
Simply require protobuf

The protobuf recipe produces libraries that differ in name between debug and release, which is utterly useless and causes issues.
Conan has separate directory structures for debug and release, so it makes even less sense to have different library names.
Having different library names causes issues with linking (when not using cmake in the consumer anyway) as the file name is different.
Other packages properly produce a unified library name (e.g. zlib).

</details>



Discussion:
conan-center honors upstream lib names: https://github.com/protocolbuffers/protobuf/blob/cdc11c2d2d314ce0382fe0eaa715e5e0e1270438/CMakeLists.txt#L74-L75

There is no policy in conan-center to produce unified library name, and you can easily find many recipes with different names based on build_type, static or shared, version of the library, or even vc runtime.

I don't know why zlib recipe renames libs afterwards to provide a unified name, but perhaps because there are so many libraries depending on zlib with fragile build files (basically anything not relying on CMake config file or pkgconfig), it's just easier to not honor all the strange names in upstream CMakeLists.
So there is no chance of a PR that were to change this atrocious habit of producing different file names to be accepted?
Which would basically mean everyone not using cmake is fucked and has to run a fork of such recipes to fix atrocious and utterly stupid behavior... Because this recipe is basically useless for anyone who does not run cmake in the final product and wants the ability to build both debug and release configurations.

The other question of course is why would anyone have to have separate file names within conan, which has completely different folders for different build configurations anyway? It makes zero sense (and very little to begin with regardless of conan having different folders).
we usually package files "as is", following the convention of the upstream, not renaming anything, unless there is a strong reason to do it.
unfortunately, some projects tend to choose sophisticated naming for their libraries, and file name may depend on the platform, configuration (debug vs release), compiler and so on.
for instance, `zlib` library might be named:
- libz
- libzlib
- libzlibstatic
- libzlibstaticd
- z
- zlib

but renaming it to the unified value only makes it worse - as some projects tend to hard-code expected library name (like using `-lz` in their makefiles unconditionally), that then requires patching these makefiles to make it work properly for all the variants. but that's not just renaming, as executable and shared libraries bake the name of the dependency they are looking for, so it needs patching in earlier stage in build system, so everything is properly linked (in other words, if your executable looks for `libz.so`, you can't just rename `libzlib.so` to `libz.so`, you have to rebuild or patch the executable).

usually, you don't need to know the library name, as you use higher level abstractions, such as `pkg-config` files or `cmake` modules. in that case, you don't care what's the name on the file system, is it a single library or multiple or just header-only thing, are there any transitive dependencies, what's the linking order and so on. if possible, you should try to use that higher level abstractions. 

but that's not a silver bullet, and project tend to produce different target names per configuration 🤦  (e.g. `flatbuffers` vs `flatbuffer-shared`).




Resolving patch:
diff --git a/recipes/protobuf/all/conanfile.py b/recipes/protobuf/all/conanfile.py
--- a/recipes/protobuf/all/conanfile.py
+++ b/recipes/protobuf/all/conanfile.py
@@ -24,6 +24,7 @@ class ProtobufConan(ConanFile):
         "with_zlib": [True, False],
         "with_rtti": [True, False],
         "lite": [True, False],
+        "debug_suffix": [True, False],
     }
     default_options = {
         "shared": False,
@@ -31,6 +32,7 @@ class ProtobufConan(ConanFile):
         "with_zlib": True,
         "with_rtti": True,
         "lite": False,
+        "debug_suffix": True,
     }
 
     short_paths = True
@@ -112,6 +114,8 @@ def _configure_cmake(self):
         cmake.definitions["protobuf_WITH_ZLIB"] = self.options.with_zlib
         cmake.definitions["protobuf_BUILD_TESTS"] = False
         cmake.definitions["protobuf_BUILD_PROTOC_BINARIES"] = True
+        if not self.options.debug_suffix:
+            cmake.definitions["protobuf_DEBUG_POSTFIX"] = ""
         if tools.Version(self.version) >= "3.14.0":
             cmake.definitions["protobuf_BUILD_LIBPROTOC"] = True
         if self._can_disable_rtti:
@@ -231,7 +235,7 @@ def package_info(self):
         self.cpp_info.set_property("cmake_build_modules", build_modules)
 
         lib_prefix = "lib" if (self._is_msvc or self._is_clang_cl) else ""
-        lib_suffix = "d" if self.settings.build_type == "Debug" else ""
+        lib_suffix = "d" if self.settings.build_type == "Debug" and self.options.debug_suffix else ""
 
         # libprotobuf
         self.cpp_info.components["libprotobuf"].set_property("cmake_target_name", "protobuf::libprotobuf")


Test patch: