[OE-core] DEPENDS_virtclass-native = "libpng jpeg" not extended to libpng-native jpeg-native

Martin Jansa martin.jansa at gmail.com
Tue Sep 11 08:03:34 UTC 2012


Hi,

in meta-openembedded/meta-oe/recipes-extended/libwmf/libwmf_0.2.8.4.bb:

DEPENDS_virtclass-native = "libpng jpeg"
DEPENDS = "libpng jpeg expat gtk+"

BBCLASSEXTEND = "native"

Did it work (at least at some point of time) that DEPENDS for
libwmf-native were expanded to libpng-native and jpeg-native?

Because now it does not:
OE tuna at shr ~/shr-core $ bitbake-diffsigs
stamps.1347348593/nokia900/x86_64-linux/libwmf-native-0.2.8.4-r1.do_configure.sigdata.315a83efebb27040d6bf0aaead16671e
stamps.1347348593/om-gta02/x86_64-linux/libwmf-native-0.2.8.4-r1.do_configure.sigdata.0f8349ada0c8a18a6d6ed7b7841ec955
Hash for dependent task libpng_1.2.49.bb.do_populate_sysroot changed
from 640001ee0530e51ef0aefb300c34f7dd to 7ba7d74a27e1e0af253ddac00a2be1c2
Hash for dependent task libjpeg-turbo_svn.bb.do_populate_sysroot changed
from 3fe6eae3a6fd1af40233d548680c5bab to ff852ac3d5e826ff74e68b5ddc4ac3e1

So native recipe depending on target checksum -> rebuilding with each
MACHINE switch.

I can fix it by:
DEPENDS_virtclass-native = "libpng-native jpeg-native"
but maybe there is more cases like this and this could be checked by
native.bbclass or something like that.

Cheers,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20120911/376a771b/attachment-0002.sig>


More information about the Openembedded-core mailing list