Hi,
In #1020403 there is a request to install the CMake build glue for
the zstd library in its -dev package. I think that this is a good
idea, and I have a pretty much ready-for-uploading set of changes
that do that. For the purposes of this discussion I have uploaded
the proposed "switch to CMake and install the CMake build glue"
commits to my own fork of the libzstd repository at
https://salsa.debian.org/roam/libzstd
The main thing that gave me a bit of a pause before running
`dgit push-source` (and *thanks* for making it that easy!) is that
right now libzstd is effectively an essential package (ObXThread:
not in the Policy sense) since dpkg pre-depends on it to support
e.g. recent Ubuntu debs that use zstd as the compression method for
the data part of the package. So... if I introduce a build-time
dependency on CMake, this will probably create a non-trivial dependency
loop for people who try to bootstrap Debian onto new architectures.
Does this mean that it would be best for me to include an e.g. stage1
build profile that does not build-depend on cmake and falls back to
the old/current way of building directly using `make`?
Hm, but if I do that, it seems that it might be best to put the CMake
build glue files into a separate package and make libzstd-dev depend on
that new package in the <!stage1> case, since IIUC the stage1 build
profile is not allowed to change the contents of a binary package, so
I cannot simply drop all the files in the /usr/lib/<arch>/cmake/ directory. >That's not a big hurdle; if people say that this is the way to go, then
this is what will be done.
Many thanks to all the people who keep working on all the tools and >toolchains that make this message make sense at all!
Hi,
In #1020403 there is a request to install the CMake build glue for
the zstd library in its -dev package. I think that this is a good
idea, and I have a pretty much ready-for-uploading set of changes
that do that. For the purposes of this discussion I have uploaded
the proposed "switch to CMake and install the CMake build glue"
commits to my own fork of the libzstd repository at
https://salsa.debian.org/roam/libzstd
The main thing that gave me a bit of a pause before running
`dgit push-source` (and *thanks* for making it that easy!) is that
right now libzstd is effectively an essential package (ObXThread:
not in the Policy sense) since dpkg pre-depends on it to support
e.g. recent Ubuntu debs that use zstd as the compression method for
the data part of the package. So... if I introduce a build-time
dependency on CMake, this will probably create a non-trivial dependency
loop for people who try to bootstrap Debian onto new architectures.
Does this mean that it would be best for me to include an e.g. stage1
build profile that does not build-depend on cmake and falls back to
the old/current way of building directly using `make`?
Hm, but if I do that, it seems that it might be best to put the CMake
build glue files into a separate package and make libzstd-dev depend on
that new package in the <!stage1> case, since IIUC the stage1 build
profile is not allowed to change the contents of a binary package, so
I cannot simply drop all the files in the /usr/lib/<arch>/cmake/ directory. That's not a big hurdle; if people say that this is the way to go, then
this is what will be done.
Many thanks to all the people who keep working on all the tools and toolchains that make this message make sense at all!
In #1020403 there is a request to install the CMake build glue for
the zstd library in its -dev package. I think that this is a good
idea, and I have a pretty much ready-for-uploading set of changes
that do that. For the purposes of this discussion I have uploaded
the proposed "switch to CMake and install the CMake build glue"
commits to my own fork of the libzstd repository
make is the officially maintained build system of this project. Allother build systems are "compatible" and 3rd-party maintained, they may
Il giorno lun 26 dic 2022 alle 08:37:51 +02:00:00, Peter Pentchev <roam@ringlet.net> ha scritto:
In #1020403 there is a request to install the CMake build glue for
the zstd library in its -dev package. I think that this is a good
idea, and I have a pretty much ready-for-uploading set of changes
that do that. For the purposes of this discussion I have uploaded
the proposed "switch to CMake and install the CMake build glue"
commits to my own fork of the libzstd repository
Hi Peter. Apart from your bootstrapping concerns, please keep in mind that upstream's CMake build script is not official; citing the README:
make is the officially maintained build system of this project. All otherbuild systems are "compatible" and 3rd-party maintained, they may feature small differences in advanced options. When your system allows it, prefer using make to build zstd and libzstd.
Using CMake instead of make has caused some interesting issues in the past. The first that comes to my mind happened in Arch Linux, and got featured on the Phoronix news site: <https://www.phoronix.com/news/Arch-Linux-Bizarre-Zstd>
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).
I appreciate your concern for the implications for the Debian
ecosystem as a whole; in this particular case, I believe I can put
your mind at ease: cmake has a bootstrap profile already, because
dependency loops have come up before (e.g. libjsoncpp).
I am Cc'ing debian-cross in case I overlooked something important,
but I am reasonably sure that you need not deal with this issue in
libzstd.
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).
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.
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.
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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 161:47:59 |
| Calls: | 10,385 |
| Calls today: | 2 |
| Files: | 14,057 |
| Messages: | 6,416,500 |