All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <rpurdie@rpsys.net>
To: openembedded-devel@openembedded.org
Cc: Ross Burton <ross@openedhand.com>
Subject: Re: RFC: Staging layout and pkgconfig sysroot support
Date: Tue, 18 Sep 2007 09:17:38 +0100	[thread overview]
Message-ID: <1190103458.6159.13.camel@localhost.localdomain> (raw)
In-Reply-To: <20070918014128.GA760@thegnar.org>

On Mon, 2007-09-17 at 18:41 -0700, mark gross wrote:
> On Mon, Sep 17, 2007 at 12:25:56AM +0100, Richard Purdie wrote:
> > The sed code in pkgconfig.bbclass has always struck me as ugly. In an
> > ideal world we shouldn't have to rewrite the contents of the pkgconfig
> > files to make them work with OE.
> > 
> > Packages like dbus and eds are starting to add paths to runtime module
> > and state directories into the pkgconfig files and OE's current approach
> > totally breaks these.
> 
> Then shouldn't we beet on the dbus guys to not break things?

I don't think the dbus guys are doing anything wrong and this is an
entirely an artifact of our own design choices. The problem is that
dbus-1.pc contains:

session_bus_services_dir=/media/data1/builds/poky/eabi/tmp/staging/arm-poky-linux-gnueabi/share/dbus-1/services

and evolution-data-server.pc has things like:

libdir=/media/data1/builds/poky/eabi/tmp/staging/arm-poky-linux-gnueabi/lib
extensiondir=${libdir}/evolution-data-server-1.2/extensions

The above was created by our sed "magic" in pkgconfig.bbclass. EDS
modules then use this to decide where to install its plugins which
results in broken packages. The dbus entry is just asking for trouble
too.

You could argue our sed magic is wrong and just needs improving. What do
you make it do in the eds case though? First replace all ${libdir} with
an expanded version, then change libdir?

The best alternative idea I've seen is to hack pkgconfig to make the sed
expansions at runtime for the -L and -I options pkgconfig returns. You
have to admit its a pretty ugly solution though. 

The sysroot patch is simpler and has a good chance of being accepted
upstream and solves the problem once and for all.

I have really mixed feelings and can see the arguments both ways
really...

Cheers,

Richard





      reply	other threads:[~2007-09-18  8:21 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-16 23:25 RFC: Staging layout and pkgconfig sysroot support Richard Purdie
2007-09-17  6:27 ` Koen Kooi
2007-09-17 20:30 ` Stanislav Brabec
2007-09-18  8:39   ` Richard Purdie
2007-09-18 10:38     ` Stanislav Brabec
2007-09-18  1:41 ` mark gross
2007-09-18  8:17   ` Richard Purdie [this message]

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=1190103458.6159.13.camel@localhost.localdomain \
    --to=rpurdie@rpsys.net \
    --cc=openembedded-devel@lists.openembedded.org \
    --cc=openembedded-devel@openembedded.org \
    --cc=ross@openedhand.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.