On Mon, Dec 26, 2022 at 04:35:09PM +0000, Simon McVittie wrote:
> On Mon, 26 Dec 2022 at 14:00:31 +0100, Andrea Pappacoda wrote:
> > or patch zstd's makefiles to install a small Find
> > module itself (this is not really a good practice, as ideally upstreams
> > should install CMake Config files, but should work nonetheless).
Thanks to everyone for the great discussion and several pieces of very
helpful advice! In the end I decided to go with the "small lie" approach that
I mentioned in a previous message: run dh_auto_configure --buildsystem=cmake
so that CMake can create the zstdConfig*.cmake and zstdTargets*.cmake files
that it would install, then run the normal Makefile build, and in the end
install the CMake build glue files generated at configure time. Yes, this is
not perfect, inasmuch as the *.cmake files do not *really* correspond to
the built libraries, but I think it will serve for now (and see below).
> If you're considering patching zstd's makefiles, I believe the preferred
> route is to install CMake "config modules" containing an imported target,
> like dbus and libsdl2 do. The one in dbus is a reasonably simple example
> of wrapping a pkg-config module with a CMake config module, while the one
> in libsdl2 bypasses pkg-config and provides the equivalent information
> more directly. Either way, this is something that would make sense to
> contribute upstream.
>
> Both dbus and libsdl2 have optional-but-not-recommended CMake build
> systems, similar to zstd, which we don't use in Debian; we follow upstream
> recommendations to build dbus with Autotools (in older branches) or Meson
> (in the 1.15.x development branch), and libsdl2 with Autotools. The
> Autotools and Meson build systems for those projects also install a
> simplified CMake config module, which can be consumed by CMake projects
> in the same way as if dbus/libsdl2 had themselves been built with CMake.
> The CMake config module is generated from a template using @variable@
> substitutions.
This - building a trivial zstdConfig.cmake file during the standard build -
is a great idea that I will try to implement and pitch to the libzstd upstream
developers. Thanks!
> In older versions of libsdl2 the config module is not completely compatible
> with what its CMake build system would have installed, but the one in
> bookworm should be reasonably feature-complete.
>
> If dependent projects are expected to call find_package(Foo), then the
> CMake config module should be installed as either
> ${libdir}/cmake/Foo/FooConfig{,Version}.cmake in mixed-case (like dbus
> does) or ${libdir}/cmake/Foo/foo-config{,-version}.cmake in lower-case
> (like libsdl2 does). I don't know whether one of those is preferred over
> the other.
Yeah, I imagine that the fake zstdConfig.cmake file would be installed in
the same place and under the same name as the one that the (not completely
suppored) CMake build system for libzstd already installs.
> It is a good idea to have a test for each supported use-case in the
> package's autopkgtests. dbus and libsdl2 have some tests for this which
> might make useful inspiration.
Right, I have autopkgtests that compile trivial programs for other
library packages, I don't know why I didn't add one (and now, it seems,
at least two) for libzstd when I adopted it. Thanks again for the idea!
Once again, thanks to everyone for the relevant critique and helpful
suggestions!
G'luck,
Peter
--
Peter Pentchev roam@ringlet.net roam@debian.org pp@storpool.com
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
Attachment:
signature.asc
Description: PGP signature