Support zstd also via pkg-config

[DarthGandalf]

It doesn't always provide cmake config

[yhirose]

@davidalo, @sum01, could you please review this pull request for me? Thanks!

[sum01]

I suppose something like this could work for your TODO.

find_package(zstd QUIET)
	if(NOT zstd_FOUND)
		find_package(PkgConfig QUIET)
		if(PKG_CONFIG_FOUND)
			pkg_check_modules(zstd QUIET IMPORTED_TARGET libzstd)

			if(TARGET PkgConfig::zstd)
				add_library(zstd::libzstd ALIAS PkgConfig::zstd)
			endif()
		endif()
		# Both find_package and PkgConf seem to set a XXX_FOUND var
		set(HTTPLIB_IS_USING_ZSTD ${zstd_FOUND})
	endif()

It's a shame there's not some find_package+PkgConf combo thing for Cmake. This seems to be a common use-case..

[DarthGandalf]

Yeah, something like that. For now I'll just copy your code here. I didn't write that because I don't need it for my use case, and it's quite long. If user didn't specify they want zstd, they would probably be satisfied if it's not found even if it could be found.

In another project I handled the same problem differently: https://github.com/znc/znc/blob/df6a5073ff9a68bc34981c999ec9ad1e0c4bac09/CMakeLists.txt#L71-L79 and usage of it is visible below, where ${TRISTATE_ARGON_REQUIRED} and such are passed to find_package/pkg_check_modules in place of REQUIRED. The trick is that AUTO evaluates to true in if(WANT_FOO).

I you follow a similar pattern here, at least can dedup code which requires the dep and which doesn't require it.

[yhirose]

@DarthGandalf, @sum01 thanks a lot!

[eli-schwartz]

This PR appears to be "obviously broken", because it is obvious that attempting to do find_package(cpp-httplib) doesn't include the same changes, thus, it fails.

Aside: maybe about time for the cmake files to generate a pkgconfig file?

[sum01]

This is just an unfortunate side-effect of having to manually handle these things in Cmake. While it's not technically unfixable, it's a bit annoying.

You'd realistically need to check if found after find_dependency calls. If not found, run the pkgconf equivalent in the correct quiet/normal mode, create the aliases, etc.

I don't think it's "obviously broken". It'd just fail to find it in the specific case where you built with a pkgconf dependency then tried to find it with find_package. Has no bearing on actually building/using the library, just with post-build cmake integration into other projects.

But I guess I can look into it..

---

Also, like discussed in other issues before, there's no clean way to generate pkgconfig files as it's not a cmake feature at all. It'd just end up as another file you manually manage like a cmake.in file.

[eli-schwartz]

The zstd project doesn't distribute a find_package() module at all, so the default case involves building with a pkgconf dependency.

[eli-schwartz]

The logic for a .pc is much more straightforward because you already know what type of dependency to find so all you have to do is say yes or no do you embed the specific string in the requires field.

[DarthGandalf]

@eli-schwartz that may add support of usage via pkg_check_modules(cpp-httplib) or however it would be called, but wouldn't fix find_package(httplib) unless it's rewritten to use pkg-config, if I understand what you mean

[eli-schwartz]

It would also allow usage from autoconf or meson. ;)

Meson can execute find_package(httplib) as a dependency finder but it is quite slow and fragile as it involves generating a dummy project which does so, and then using the cmake debug traces to determine what compile arguments were resolved by find_package(httplib). Using a buildsystem-agnostic interchange format allows divorcing oneself from the unreliability of a cmake config file...

[sum01]

All build systems suck, it's not really worth talking about.
Even this project has like 3 I think? Cmake, Meson, and Makefile.
If you want a .pc file then write one, I doubt the PR would be denied.

Also, as I said, Cmake doesn't make generating them any less painless then the current cmake.in config system. It'd have the same problems (and probably more janky).

[eli-schwartz]

So erm maybe if all build systems suck that's a reason to support pkg-config (which is just a standard, not a set of competing standards)???

Because, you know. Then I can find cpp-httplib and use it in my code without having to deal with buildsystem proliferation, since I'm not required to run a build system in order to find the compile flags for cpp-httplib. I can even use:

gcc my-code.cpp -o my-program $(pkg-config --cflags --libs cpp-httplib)

"Look ma, no build system!"