As some may have gathered on IRC, I have some alpha code that contains a
rewrite of bitbake's dependency handling and also introduces the concept
of multithreading into bitbake.

http://www.rpsys.net/openzaurus/temp/madness1.log is some output from
bitbake running a multithreaded build. Builds sort of work with it but
it shows our current dependency relationships, at least at the task
level, are not very well defined.

By looking at what my code gets right/wrong, I've determined we have the
following relationships:

Traditional DEPEND:
  A tasks do_configure must run after all DEPENDS do_populate_staging
completes

debian.bbclass:
  A tasks do_package must run after all RDEPENDS do_packages complete 
(A side effect of this is two packages cannot REDEPEND/RRECOMMEND each
other)

shlibs:
  A tasks do_package must run after all DEPENDS do_package's complete

image.bbclass:
  A tasks do_rootfs must run after all RDEPENDS do_package (and all the
RDEPENDS do_package of the RDEPENDS recursively)

I'd like to try and add some flags to the task definitions to contain
this information rather than hardcode it into bitbake. Any thoughts on
what the data against the flags could look like is welcome. I also get
the feeling I've missed some relationships above... :)

With task level data in place, it should mean BUILD_ALL_DEPS can die as
that variable whilst well intended, doesn't convey these relationships
at all.

Cheers,

Richard

_______________________________________________
Oe mailing list
[email protected]
https://www.handhelds.org/mailman/listinfo/oe

Reply via email to