Re: gpgme-config

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Wed, 2014-07-23 at 13:51 +0000, Paul Barker wrote:
> I'm trying to build opkg with 'gpg' added to PACKAGECONFIG on the master branch
> of OE. The gpg support for opkg is provided by gpgme, which uses 'gpgme-config'
> to determine CFLAGS and LIBS when building. After recent changes, the
> gpgme-config script is now just a dummy and doesn't do anything.
> 
> Upstream gpgme do not provide a pkg-config file and an upstream issue about this
> raised in 2012 was resolved WONTFIX (https://bugs.g10code.com/gnupg/issue1414).
> 
> Our options are:
> 
> 1) Add a .pc file to gpgme and maintain it within OE as it is very unlikely to
>    be accepted upstream. Then I need to modify configure.ac in opkg to support
>    both this pkg-config file (for OE) and the gpgme-config utility (for all
>    other users of opkg).

There are a set of applications, all gpg related which we've done this
for. Its rather sad upstream have this as WONTFIX and I'd love them to
reconsider this.

How does opkg's configure.ac use gpgme? Does it use the macros from
gpgme.m4 (or can it)? If it does, we can just patch that m4 file and
opkg will "just work", this is what happened with the majority of the
other gpg recipes. The patches tend just to delete a lot of code and are
relatively simple, hence the overhead isn't so bad.

> 
> 2) Make an exception to the policy on -config scripts for gpgme.
> 
> I haven't really followed the discussion on why -config scripts needed to be
> removed so I'll put this question to other OE developers. Would option (2) cause
> more problems in the long run? If so, is it worth the extra effort to follow
> option (1)?

If you look at what binconfig.bbclass does, its pretty horrific.
pkg-config is a much saner way of doing things in a cross compile
environment that doesn't mean we need to hack the -config scripts each
time we want to use a different sysroot.

There are only a small minority of recipes that don't support pkg-config
and the plan is just to patch those so they do, regardless of the
upstream.

> I'll probably need someone to bounce a few autoconf and pkg-config questions off
> if I implement option (1) as I'm not very familiar with either system.

Happy to help. Looking at the other pkgconfig.patch to the other gpg
pieces would be a good starting point.

Cheers,

Richard