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! 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