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
prev parent 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.