ugly OE issue with RDEPENDS

ugly OE issue with RDEPENDS

[Robert Schuster]

[-- 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 --]

Re: ugly OE issue with RDEPENDS

[Holger Schurig]

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

As a local hack, you might be able to shortcut bitbake by putting 
this in your default.conf:

ASSUME_PROVIDED += "openjdk-6"

Maybe should instead say ASSUME_PROVIDED += "java2-runtime", but 
then "bitbake world" wouldn't make jamvm. But you can 
specify "bitbake jamvm world" instead.



This hack doesn't solve the underlying problem, but should cure 
your sympton in the meantime.

Re: ugly OE issue with RDEPENDS

[Koen Kooi]

On 31-03-09 14:48, Robert Schuster wrote:
> 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.

The real issue is that you RDEPEND on a virtual package, but you're not 
giving OE enough info to resolve the virtual to a real provider. I 
suppose you want bitbake to (reverse) check the build target for any 
virtuals it might provide, right?

regards,

Koen

Re: ugly OE issue with RDEPENDS

[Holger Schurig]

> RDEPENDS_classpath-tools = "java2-runtime".

One more comment after reading Koen's reply: maybe you name 
this "virtual/java2-runtime" ?

This has nothing to do with your problem, but just brings in some 
consistency. And maybe, if bitbake ever considers virtual 
packages different when it comes to runtime-dependencies, your 
problem might go away :-)