Re: [Qemu-devel] [PATCH] configure: Add pkg-config handling for libgcrypt

[Andrea Bolognani <abologna@redhat.com>]

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