Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Martin Jansa <martin.jansa@gmail.com>
To: Paul Barker <paul@paulbarker.me.uk>
Cc: OE Core <openembedded-core@lists.openembedded.org>
Subject: Re: gpgme-config
Date: Wed, 23 Jul 2014 16:49:52 +0200	[thread overview]
Message-ID: <20140723144952.GG22875@jama> (raw)
In-Reply-To: <20140723135123.GA32767@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2440 bytes --]

On Wed, Jul 23, 2014 at 01:51:23PM +0000, Paul Barker wrote:
> 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).

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).
 
> 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.

> Thanks,
> 
> -- 
> Paul Barker
> 
> Email: paul@paulbarker.me.uk
> http://www.paulbarker.me.uk



> -- 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core


-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]

  parent reply	other threads:[~2014-07-23 14:49 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-23 13:51 gpgme-config Paul Barker
2014-07-23 14:31 ` gpgme-config Richard Purdie
2014-07-23 14:49 ` Martin Jansa [this message]
2014-08-08 11:26   ` gpgme-config Paul Barker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140723144952.GG22875@jama \
    --to=martin.jansa@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=paul@paulbarker.me.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox