[oe] Unwanted dependency on X from ppp

[Mats Kärrman]

Thanks again, Mike & Bob,

I added something in the line of Mike's suggestion to my machine conf and
got the number of tasks down to just over 2200 and the build runs reasonably
fast. There are still a bunch of X native related dependencies generated from
dbus but I found no easy way to get rid of them.

Still - a huge improvement!

// Mats
________________________________________
From: Mike Westerhof [mike at mwester.net]
Sent: Wednesday, July 13, 2011 6:11 PM
To: openembedded-devel at lists.openembedded.org
Cc: Mats Kärrman
Subject: Re: [oe] Unwanted dependency on X from ppp

On 7/13/2011 10:37 AM, Mats Kärrman wrote:
> Thank you Bob!
>
> You're my hero, honestly!
>
> The "clean build" time concerns me though. I will need bluez components,
> but not gstreamer so I guess I'll set out to find a neat way to override
> the default bluez recipe and get rid of that dependency.

This topic comes up for discussion now and again, and nothing really
ever gets resolved.  There are two camps, it seems -- I fall into the
group that cares about build time as much as I care about what ends up
in the image.

In any case, perhaps the following incantations might be helpful; they
are somewhat dated (double-check these against the current recipes!),
but I used these in my local.conf to get rid of useless X11 builds on my
build machines:

DEPENDS_pn-bluez-libs = "dbus"
EXTRA_OECONF_pn-bluez-libs = "--disable-tools --disable-network
--disable-serial --disable-service --disable-usb --enable-alsa"

DEPENDS_pn-bluez4 = "alsa-lib virtual/libusb0 dbus-glib libsndfile1"
EXTRA_OECONF_pn-bluez4 = "--disable-gstreamer --enable-alsa --enable-usb
--enable-netlink --enable-tools --enable-bccmd --enable-hid2hci
--enable-dfutool --enable-hidd --enable-pand --enable-dund
--disable-cups --enable-test --enable-manpages --enable-configfiles
--enable-initscripts --disable-pcmciarules"

DEPENDS_pn-dbus = "expat glib-2.0 virtual/libintl libsm libice"
EXTRA_OECONF_X_pn-dbus = "--without-x"

-Mike (mwester)

>
> // Mats
>
> ________________________________________
> From: openembedded-devel-bounces at lists.openembedded.org [openembedded-devel-bounces at lists.openembedded.org] on behalf of Bob Foerster [robert at erafx.com]
> Sent: Wednesday, July 13, 2011 4:18 PM
> To: openembedded-devel at lists.openembedded.org
> Subject: Re: [oe] Unwanted dependency on X from ppp
>
> Hi Mats,
>
> On Wed, Jul 13, 2011 at 8:16 AM, Mats Kärrman <Mats.Karrman at tritech.se>wrote:
>
>> Hi Everyone!
>>
>> I'm building a small "headless" embedded system with OE and the Angstrom
>> distro. A normal rootfs build consists of about 1500 tasks. Everything fine
>> so far.
>>
>> Now I wanted to include the ppp daemon in my build and thus just added
>> "ppp" to IMAGE_INSTALL. Suddenly the rootfs build is about 4000 tasks and a
>> lot of X/display related stuff is downloaded and built. I fail to see the
>> connection.
>>
>
> Are the X/display items you're concerned about actually making it into the
> final image, or just being built?  If they are ending up in the image, then
> it will take some investigation as to why that's happening. If they're just
> being built there is probably not much you can do, but the following may
> help shed some light as to why they are built.
>
> To understand why adding ppp pulls in various X/display packages, keep in
> mind that what is downloaded and built does not directly correlate to what
> ends up in the image.  Often, recipes may provide several packages which
> have a broad set of build time dependencies, but these don't all necessarily
> end up in the image.
>
> For tracking down dependencies, you can fire up the dependency explorer gui
> for bitbake:
> bitbake -g -u depexp ppp
>
> Doing this and following the trail, one sees:
> ppp -> libpcap -> bluez-libs (here, bluez4 is selected as provider for
> bluez-libs) -> gst-plugins-base -> gtk+ -> libx*
>
> Given this dependency chain, we start to see why building ppp causes various
> gtk+ and X packages to be built. The bluez4 recipe provides a package
> gst-plugin-bluez, causing a build time dependency on gst-plugins-base.
>  gst-plugins-base depends on many things, including gtk+.  As a result of
> these dependencies, many packages end up being built.  The shlibs code in OE
> automatically detects the run time libs required for a given package and
> appropriately associates run time dependencies on them.  As such, unless one
> adds gst-plugin-bluez to IMAGE_INSTALL, I wouldn't expect the various gtk+,
> libx*, etc packages to make it into the final image.  If they are, then
> there is another dependency that is pulling them into the image and needs
> explored.  For a little bit more background on build vs run time
> dependencies, see [1].
>
> Hope that helps clarify a bit.
> Bob
>
> [1]
> http://dominion.thruhere.net/koen/cms/reducing-the-size-of-your-angstrom-rootfs-without-changing-the-buildsystem
>
>
>
>> I'm afraid I'm not using the latest trunk or release of OE but any
>> suggestions or directions on how to find/eliminate the cause of the problem
>> would be greatly appreciated!
>>
>> Best Regards,
>> Mats
>>
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel at lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
>