All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robert Schuster <thebohemian@gmx.net>
To: openembedded-devel@lists.openembedded.org
Subject: ugly OE issue with RDEPENDS
Date: Tue, 31 Mar 2009 14:48:40 +0200	[thread overview]
Message-ID: <49D21128.30201@gmx.net> (raw)

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

Hi,
I have this specific issue with with RDEPENDS and no idea how to solve
it. It affects my Java recipes but in theory it can happen to any other
recipes too. It is nothing Java specific. The unwanted effect is that OE
builds to much and as such slows down the time to build a specific
package considerably.

Ok here is how it goes:

I want to build recipe jamvm (application). This in turn needs recipe
classpath. classpath puts a lot of useful things into staging which is
needed by the jamvm build. So far so good.

The problem is. classpath's tar.gz also contains some Java applications
(the well known jar, javah and so). Via PACKAGE variable I place those
into the binary package classpath-tools. To make everything as smooth as
possible for the user I furthermore declare:

RDEPENDS_classpath-tools = "java2-runtime". This means: For this package
to work correctly a Java runtime needs to be installed. OE in turn
demands that this java2-runtime dependency is also satisfied during the
build.

The odd thing that happens here is: jamvm (which I want to build) is a
provider for java2-runtime but this does not interest OE and it builds
another provider for java2-runtime instead. In my case this is
openjdk-6, a recipe takes a very long time to built.

So I hope you understand my problem and can see that this is by no means
Java specific.

As I see it there are two ways out:

1) If I do 'bitbake jamvm', OE should take that as a valid java2-runtime
provider that the built wants to have (Yeah, the classpath recipe wants
it actually before) and should not select another recipe that provides it.

2) I could split classpath into different recipes. E.g. a dedicated
classpath-tools recipe.


What should I do?

Regards
Robert


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 268 bytes --]

             reply	other threads:[~2009-03-31 12:52 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-31 12:48 Robert Schuster [this message]
2009-03-31 13:06 ` ugly OE issue with RDEPENDS Holger Schurig
2009-03-31 13:19 ` Koen Kooi
2009-03-31 13:36 ` Holger Schurig

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=49D21128.30201@gmx.net \
    --to=thebohemian@gmx.net \
    --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.