RFC: thinking about DEPENDS properties

RFC: thinking about DEPENDS properties

[Robert Schuster]

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

Hi,
today I was thinking about some missing semantics in OE's DEPENDS
variable and had the idea of reusing the way we write SRC_URI entries
for them.

The issues:

1) Strong dependencies

Some recipes have a strong dependency on another recipe. Take llvm as an
example. llvm puts a bunch of static libraries (.a) and object code
files into staging which another program links to. So, if llvm is
recompiled (e.g. changed CFLAGS or applied a patch) those having a
dependency on llvm should be recompiled as well.

In order to express this, I would write:

DEPENDS += "llvm;strong=true"

2) Minimum & Maximum supported versions
Some recipes cannot be built with certain versions of other recipes.

DEPENDS += "automake-native;minver=1.10"

If the distro uses a lower automake version OE should error out when
someone tries to build that recipe:

ERROR: Recipe 'foo' needs at least 'automake-native 1.10' but
'PREFERRED_VERSION_automake-native' is set to '1.9.6'.

--

I know this brings in a lot of complicated things to think about, e.g.
what is the result of:

foo.inc: DEPENDS = "bar;minver=0.8;maxver=0.9"

foo_1.0: require foo.inc
         DEPENDS += "bar;minver=1.0"

Perhaps to many components in OE already expect DEPENDS to be a
whitespace separated list of words and we should be add another variable
whose only purpose is to set properties for existing DEPENDS entries:


foo_1.0:
 require foo.inc
 # Replaces value from foo.inc
 DEPENDSPROPS = "bar;minver=1.0"

--

My main concern is that the knowledge about which recipe can live in
harmony with another is currently implicit. There is no way to express
this except by writing a comment (which is almost never done).

Regards
Robert


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

Re: RFC: thinking about DEPENDS properties

[Phil Blundell]

On Tue, 2009-01-27 at 12:07 +0100, Robert Schuster wrote:
> 1) Strong dependencies
> 
> Some recipes have a strong dependency on another recipe. Take llvm as an
> example. llvm puts a bunch of static libraries (.a) and object code
> files into staging which another program links to. So, if llvm is
> recompiled (e.g. changed CFLAGS or applied a patch) those having a
> dependency on llvm should be recompiled as well.

I'm not exactly sure what the concrete difference is between a "strong"
and a "weak" dependency in this view of the world.  Even for packages
with just shared libraries, a change in the depended-on header files
or .so files could easily cause a difference in the dependent binaries.

> 2) Minimum & Maximum supported versions
> Some recipes cannot be built with certain versions of other recipes.
> 
> DEPENDS += "automake-native;minver=1.10"

Bitbake already has a notation for this: you can write:

DEPENDS += "automake-native (>= 1.10)"

and the current parser will accept it although the version information
is ignored.  It would just be a small matter of programming to teach
bitbake to do something useful with that data.

> If the distro uses a lower automake version OE should error out when
> someone tries to build that recipe:
> 
> ERROR: Recipe 'foo' needs at least 'automake-native 1.10' but
> 'PREFERRED_VERSION_automake-native' is set to '1.9.6'.

Not that this was really your point, but the version check shouldn't be
looking at PREFERRED_VERSION_anything.  What matters is the specific
version that you end up trying to build, which might be quite different
to the preferred one for a variety of reasons.

p.

Re: RFC: thinking about DEPENDS properties

[Koen Kooi]

On 27-01-09 12:07, Robert Schuster wrote:
> Hi,
> today I was thinking about some missing semantics in OE's DEPENDS
> variable and had the idea of reusing the way we write SRC_URI entries
> for them.
>
> The issues:
>
> 1) Strong dependencies
>
> Some recipes have a strong dependency on another recipe. Take llvm as an
> example. llvm puts a bunch of static libraries (.a) and object code
> files into staging which another program links to. So, if llvm is
> recompiled (e.g. changed CFLAGS or applied a patch) those having a
> dependency on llvm should be recompiled as well.

Isn't that what BB_STAMP_POLICY=whitelist and BB_STAMP_POLICY=full 
accomplish?

regards,

Koen


>
> In order to express this, I would write:
>
> DEPENDS += "llvm;strong=true"
>
> 2) Minimum&  Maximum supported versions
> Some recipes cannot be built with certain versions of other recipes.
>
> DEPENDS += "automake-native;minver=1.10"
>
> If the distro uses a lower automake version OE should error out when
> someone tries to build that recipe:
>
> ERROR: Recipe 'foo' needs at least 'automake-native 1.10' but
> 'PREFERRED_VERSION_automake-native' is set to '1.9.6'.
>
> --
>
> I know this brings in a lot of complicated things to think about, e.g.
> what is the result of:
>
> foo.inc: DEPENDS = "bar;minver=0.8;maxver=0.9"
>
> foo_1.0: require foo.inc
>           DEPENDS += "bar;minver=1.0"
>
> Perhaps to many components in OE already expect DEPENDS to be a
> whitespace separated list of words and we should be add another variable
> whose only purpose is to set properties for existing DEPENDS entries:
>
>
> foo_1.0:
>   require foo.inc
>   # Replaces value from foo.inc
>   DEPENDSPROPS = "bar;minver=1.0"
>
> --
>
> My main concern is that the knowledge about which recipe can live in
> harmony with another is currently implicit. There is no way to express
> this except by writing a comment (which is almost never done).
>
> Regards
> Robert
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel