[oe] ugly OE issue with RDEPENDS

[Robert Schuster]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20090331/b0d5c1ce/attachment-0002.sig>