[OE-core] specific version dependenciews - was: Linking two recipes

[Richard Purdie]

On Mon, 2012-03-19 at 20:43 -0400, Denys Dmytriyenko wrote:
> On Mon, Mar 19, 2012 at 10:59:34PM +0100, Wolfgang Denk wrote:
> > Dear Richard,
> > 
> > In message <1332192150.9740.72.camel at ted> you wrote:
> > > On Mon, 2012-03-19 at 13:59 -0700, simran singh wrote:
> > > > Hello,
> > > > I have recipes for two applications Recipe A and Recipe B. Recipe B
> > > > requires a lib.so file and init.h file which are installed by Recipe
> > > > A.
> > ...
> > > recipe B needs to do:
> > > 
> > > DEPENDS += "recipeA"
> > 
> > I have a similar, but more complicated requirement which I don;t know
> > how to implement (if this is possible at all):
> > 
> > Some MACHINEs require a package A (some library), but in specific
> > versions: say machine X needs version A-1.2, while machine Y needs
> > version A-1.5.
> > 
> > Package A itself depends on another package B (another library).
> > 
> > The problem is, that different versions of A require specific versions
> > of B.  For example, to build A-1.2 we must use B-4.5, but to build
> > A-1.5 we must use B-8.2.
> > 
> > I am aware that I can describe the dependencies at the top leven,
> > stating for example that machine X needs A-1.2 and B-4.5, while
> > machine Y needs A-1.5 and B-8.2.
> > 
> > However, this seems clumsy, as the version depency A->B is something
> > that is only defined by the implementation of A, and I would like to
> > keep it encapsulated at this level.
> > 
> > 
> > Is there a clever way to describe such a multi-level dependency chain?
> 
> Will this help? See line #4 in the first example and lines #30-31 in second:
> 
> http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-support/gnutls/gnutls.inc#n4
> http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-graphics/xserver-nodm-init/xserver-nodm-init_2.0.bb#n30
> 
> There are some caveats with that notation, IIRC...

The RDEPENDS version will work. The parser will tolerate the entry in
DEPENDS but as the code stands today, ignore it since the code has never
been implemented.

Cheers,

Richard