All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Andreas Müller" <schnitzeltony@googlemail.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: build dependency cycles in openembedded
Date: Mon, 18 Feb 2013 21:15:43 +0100	[thread overview]
Message-ID: <CALbNGRRMEer3+UQN4OsO5zm7tsv7U+BQRH8wHY8yYNVKVw_mHg@mail.gmail.com> (raw)
In-Reply-To: <20130218185446.19879.81595@hoothoot>

On Mon, Feb 18, 2013 at 7:54 PM, Johannes Schauer <j.schauer@email.de> wrote:
> Hi,
>
> Quoting Marko Lindqvist (2013-02-18 18:22:26)
>> OE has both native build and cross-compile part, and problems can arise in
>> native part too. One example is that pkg-config version used has not been
>> updated for a while since build of newer version would depend on glib, which
>> needs pkg-config to build...
>
> Great example! The same loop exists in binary distributions. Though there it is
> a bit more involved since the notion of binary and source packages exists.
> Therefor the loop you mention is not between the pkg-config and glib source
> packages but between the pkg-config source package and the glib development
> headers binary package libglib2.0-dev. So while the glib source package can be
> built without pkg-config if ./configure is called with manually supplied
> arguments like this:
>
>     ./configure \
>         PKG_CONFIG=false \
>         ZLIB_CFLAGS=-I/usr/include ZLIB_LIBS="-L/usr/lib -lz" \
>         LIBFFI_CFLAGS=-I/usr/include LIBFFI_LIBS="-L/usr/lib -lffi" \
>         --disable-libelf \
>         --with-pcre=internal
>
> The dependency loop does still exist because the binary package libglib2.0-dev
> can only be installed if the pkg-config binary package exists. But the
> pkg-config binary package can only be built from the pkg-config source package
> using the uninstallable libglib2.0-dev binary package....
>
> So while it is good to hear an example for a dependency cycle in OpenEmbedded,
> I now wonder why I didnt find more instances where those impact the development
> and deployment of the OpenEmbedded distribution for new platforms?
>
> cheers, josch
>
FWIW long time ago in meta-oe commit
5b8522e3b592c96ec9325aff4bbaa68972e52d5b gvfs-gdu-volume-monitor was
spitted out into an own recipe to break dependency loop for gvfs.

Andreas



  reply	other threads:[~2013-02-18 20:31 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-18  9:41 build dependency cycles in openembedded Johannes Schauer
2013-02-18 12:26 ` Takeshi Hamasaki
2013-02-18 14:20   ` Johannes Schauer
2013-02-18 15:07     ` Takeshi Hamasaki
2013-02-18 16:53       ` Johannes Schauer
2013-02-18 17:22         ` Marko Lindqvist
2013-02-18 18:54           ` Johannes Schauer
2013-02-18 20:15             ` Andreas Müller [this message]
2013-02-19 10:46               ` Johannes Schauer
2013-02-24  8:12                 ` Khem Raj

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=CALbNGRRMEer3+UQN4OsO5zm7tsv7U+BQRH8wHY8yYNVKVw_mHg@mail.gmail.com \
    --to=schnitzeltony@googlemail.com \
    --cc=openembedded-devel@lists.openembedded.org \
    /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.