On Fri, Jan 07, 2022 at 12:06:47PM +0000, Daniel P. Berrangé wrote: > On Fri, Jan 07, 2022 at 12:55:42PM +0100, Thomas Huth wrote: > > On 07/01/2022 12.43, Andrea Bolognani wrote: > > > On Thu, Aug 29, 2019 at 10:15:05AM +0100, Daniel P. Berrangé wrote: > > > > Where are you seeing pkg-config files for libgcrypt ? > > > > > > > > The upstream project has (frustratingly) been hostile to any proposal to > > > > add pkg-config support saying people should stick with their custom > > > > libgcrypt-config tool > > > > > > > > https://dev.gnupg.org/T2037 > > > > > > Resurrecting an old thread to point out that the upstream stance > > > seems to have changed since that discussion: > > > > > > > > > https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=97194b422bc89a6137f4e218d4cdee118c63e96e > > > > > > libgcrypt 1.9.0, released almost exactly a year ago, comes with a > > > pkg-config file out of the box. With that in mind, I think it would > > > make sense to re-evaluate this patch for inclusion. > > > > Maybe ... but we switched to Meson in between, so the patch needs to be > > rewritten to use meson.build instead, I think.
Right. I didn't mean that the patch should be merged as-is, and I wouldn't expect it to even apply two years later :) > > Also it seems like version > > 1.9 is not available in all distros yet, so someone needs to do an > > assessment whether the distros that use an older version of libgrypt provide > > a .pc file or not... The original approach used the .pc file where present and used libgcrypt-config as a fallback. Once QEMU stopped targeting all operating system that have libgcrypt < 1.9, the fallback path could have been dropped. > Comes back to my question of what is the benefit of using the .pc file > when what we have already works and is known to be portable. > > When using meson there is essentially zero burden to using the > libgcrypt-config approach, because that's all handled transparently > by meson. This is different from the situation with configure, > where libgcrypt-config required extra work on our side. I didn't realize that was the case! I see now that Meson implements special handling for libgcrypt, which is very nice indeed :) > Overall I don't see any need to change it. IIUC, the fact that the call currently looks like gcrypt = dependency('libgcrypt', version: '>=1.8', method: 'config-tool', ...) means that Meson will not use the .pc file even when it's present. I think changing method to "auto" would cause it to use the .pc file when it's available, which is likely a better behavior. -- Andrea Bolognani / Red Hat / Virtualization