gpgme-config
Hi all,
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).
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)?
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.
Thanks,
Signature · 4 lines
Paul Barker Email: [email protected] http://www.paulbarker.me.uk
Quoted 8 lines · Paul Barker
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).
Quoted 6 lines
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.
Quoted 7 lines
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.
Quoted 2 lines
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
Quoted 10 lines · Paul Barker
Hi all,
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).
Quoted 6 lines
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).
This comment in original issue:
The gpgme-config scripts goes along with the gpgme.m4 code. A .pc file won't be able to do what we can do with this combination.
Makes me think that if we implement .pc.in which generates correct .pc from gpgme.m4 he won't be against accepting such patch upstream.
I think that biggest reason against -config scripts was that they aren't cross-compile friendly (not sysroot-aware) so you either have whole path to sysroot hardcoded in -config file and then have to mangle it for target -dev package or vice versa and you need to prefix returned values (like -I -L flags with sysroot).
Quoted 9 lines
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)?
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.
I'm no expert in this as well, but there are some examples we can copy.
Quoted 15 lines
Thanks,
Signature · 12 lines
Paul Barker Email: [email protected] http://www.paulbarker.me.uk -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
Signature · 1 line
Martin 'JaMa' Jansa jabber: [email protected]
Quoted 38 lines · Martin Jansa
Quoted 10 lines · Paul Barker
Hi all,
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).
Quoted 6 lines
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).
This comment in original issue:
The gpgme-config scripts goes along with the gpgme.m4 code. A .pc file won't be able to do what we can do with this combination.Makes me think that if we implement .pc.in which generates correct .pc from gpgme.m4 he won't be against accepting such patch upstream.
I think that biggest reason against -config scripts was that they aren't cross-compile friendly (not sysroot-aware) so you either have whole path to sysroot hardcoded in -config file and then have to mangle it for target -dev package or vice versa and you need to prefix returned values (like -I -L flags with sysroot).
Quoted 7 lines
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)?
Quoted 5 lines
Quoted 2 lines
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.
I'm no expert in this as well, but there are some examples we can copy.
I think I've got this now. I've created a 'gpgme.pc' file by adapting 'lua.pc' from meta-openembedded. The Libs and Cflags were found by running 'gpgme-config' on my development machine and they seem fairly sensible. I've then used PKG_CHECK_MODULES() in 'configure.ac' within opkg to find gpgme using that pkg-config file.
I'll send in a couple of patches but I'll delay the changes to 'configure.ac' in opkg. I should be releasing opkg-0.2.3 in the next few weeks and that will include the necessary changes.
Thanks,
Signature · 4 lines
Paul Barker Email: [email protected] http://www.paulbarker.me.uk