Add qdbm/1.8.78

[friendlyanon]

Specify library name and version: qdbm/1.8.78

Issue: #8618

---

• I've read the guidelines for contributing.
• I've followed the PEP8 style guides for Python code in the recipes.
• I've used the latest Conan client version.
• I've tried at least one configuration locally with the
  conan-center hook activated.

[Croydon]

Could you please explain your motivation for writing your own CMake file instead of using the upstream build system?

[friendlyanon]

Sure, it's much easier to hook into the build from Conan if it's a CMake build instead of an Autotools gobbledygook. It also builds trivially across every platform.

Additionally, I rather spend a couple hours writing a CML that I can guarantee to work correctly than spend multiple days trying to untangle some Autotools mess that I hope works correctly. See the net-snmp recipe for an example where I'm not sure things work properly despite the amounts of bandaids I had to apply.

[uilianries]

We avoid creating extra files for multiple reasons. First, maintenance, one file more requires more effort. Second, expected behavior, the autotools can be a mess, but it results a file with an expected behavior, if we provide cmake or any other file and forget any flag, it will result in a different artifact (libs, bin, ...).
There are some cases where we use autootools for gcc and clang, but Visual Studio we really need a custom cmake file, but it's an exception.
Said that, please, keep autotools as the first option, if you get stuck, you still can ask for help here.

[friendlyanon]

I'd contest that by pointing out that QDBM hasn't seen an update since 2005 and CMake works better on all platforms, so there is nothing to maintain in that regard and the conanfile is much simpler and shorter than it would otherwise be, which makes it easier to maintain. On a second look, I will give you that maybe the .def file (which I took it from the PHP repository) file should be dropped, because there are already export/import attributes in the source code.

[Croydon]

@jgsogo Same here as in #8668 (comment). Bug in Epochs?

[SSE4]

@jgsogo Same here as in #8668 (comment). Bug in Epochs?

yes, not only there, seems like many more PRs are affected

[jgsogo]

@jgsogo Same here as in #8668 (comment). Bug in Epochs?

Indeed, now it should be fixed. We are triggering those PRs that failed.

[jgsogo]

IMHO, the CMakeLists file provided is simple enough and it probably won't require too much maintenance. If the project goes live again we can reevaluate this again and see if their re-bumped build-system better suits our needs. If not, better to add one simple file and have the library available than to have nothing at all.

[jgsogo]

We prefer to use cmake_find_package[_multi] generator, as it is more aligned with the future CMakeDeps in Conan v2.

Suggested change

	add_executable(test_package test_package.c)
	target_link_libraries(test_package PRIVATE CONAN_PKG::qdbm)
	find_package(qdbm REQUIRED)
	add_executable(test_package test_package.c)
	target_link_libraries(test_package PRIVATE qdbm::qdbm)

[friendlyanon]

That would require adding "unofficial" CMake targets. Feedback from @SpaceIm was that this is not desirable.

[SpaceIm]

conan fallbacks to Find<recipeName>.cmake/<recipeName>Config.cmake and <recipeName>::<recipeName> (and <recipeName>::<componentName> for components) imported targets in these generators (cmake_find_package, cmake_find_package_multi & CMakeDeps).
What I suggest is to not enforce an unofficial name in package_info(), not even enforce the default values generated by conan (just leave conan generate default names for this recipe).
Indeed, it's very hard and time consuming to keep CCI recipes in good health regarding CMake names (specially because many contributors don't care to define proper names of upstream in the first place, or don't know how to deduce these names from a CMakeLists, which may not be obvious in obfuscated CMakeLists). Therefore I prefer to not see CMake names in package_info() when a library doesn't have official CMake Find/Config file.

But you can use cmake_find_package_multi in test package (there will be no other choice in conan v2 anyway, it will be CMakeToolchain + CMakeDeps, so no more CONAN_LIBS variable or CONAN_PKG::<recipeName> target). IMOO, it's not so important for the moment, but there is a consensus to always use cmake_find_package_multi in test package currently, so let's use it regardless of whether CMake names are explicitly set in package_info().

[friendlyanon]

I was not aware. Thank you!

[jgsogo]

Suggested change

	settings = ("os", "compiler", "build_type", "arch")
	generators = ("cmake",)
	settings = ("os", "compiler", "build_type", "arch")
	generators = "cmake", "cmake_find_package"

[conan-center-bot]

All green in build 7 (d94ebff2c8d26edc82087bafb09709d6de2f152f):

• qdbm/1.8.78@:
  All packages built successfully! (All logs)