Re: bitbake and OE opperation

[Mark Gross <markgross@thegnar.org>]

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

On Fri, Mar 23, 2007 at 09:20:15AM +0000, Richard Purdie wrote:
> On Thu, 2007-03-22 at 21:31 -0700, Mark Gross wrote:
> > On Thu, Mar 22, 2007 at 02:34:45PM +0000, Richard Purdie wrote:
> > Yup, I read it.  I still have questions (I've figured out a number of
> > things since I posted this email.) Like, what triggers a given bbclass
> > file to be parsed, and what determines when if the functions withing the
> > class definition are executed.  I think I "get" the tasks and bb files
> > but the classes are still a bit mysterious.
> 
> To trigger the inclusion of autotools.bbclass, you'd see "inherit
> autotools". Each .bb file has an assumed "inherit base". Also, conf
> files can add a class file for inclusion with IHHERIT = "xyz".
> 

Ah, I'll take a closer look at base.


> > Mostly I was looking for the starting point in the dynamical program
> > space that the represent the dependency tree within the OE recipe
> > trees.  I think I get this.
> > 
> > BB parses all the bb files which build up a network of dependencies that
> > is then traversed based on a seed point defined by the command line.
> 
> Or seed points as it can have more than one, but yes.
> 
> > > > How does bitbake push in the ./configure command line options?
> > > 
> > > Bitbake knows nothing about this, it just knows about a list of tasks.
> > > autotools.bbclass defines a do_configure task which knows how to pass
> > > options set in an EXTRA_OECONF variable to a configure commandline. The
> > > classes are a powerful abstraction feature but are part of OE, not
> > > bitbake.
> > 
> > How is autotools.bbclass identified to be parsed?
> 
> See above.
> 
> > What triggers do_configure to be executed and when?
> 
> Read base.bbclass. It sets up a number of tasks and a default task,
> "build". You'd add configure after patch, before compile. compile would
> be before build. "bitbake somefile" would cause the default task (and
> its dependent tasks) to be executed. You could also do "bitbake somefile
> -c configure" to specifically execute the configure task.

Ok.

> 
> > What do I need to hack if I want to change the way or when they are
> > called?
> > There has to be some initial entry points for the classes.
> 
> An assumed inherit base, then inheriting other classes like autotools
> which can change things. The order of the inherits matters.
> 
> > Are there a set of pre-defined class functions that will be called or
> > does some bb file reference the class member functions?  (I haven't found
> > them referenced in the bb files I looked at, and it makes me think there
> > is some meta knowledge in the bitbake code that expects to call things
> > like do_configure, or do_patch, or do_build, but I'm having a hard time
> > finding them.
> > 
> > basically I'm trying to understand the glue that holds everything
> > together.  I'm staring to feel dangerous at hacking the OK bb tasks but
> > I'm still lost on the classes.
> 
> Hopefully I've covered this above.
> 
> > Dependency trees, configuration tweaking, the export of a minimal tree
> > of bbfiles for a specific build, a build browsing tool for exploring the
> > OE dependency cloud, for providers-bb files, classes and config files.
> 
> You might fine bitbake -g interesting, particularly in trunk. It will
> dump a number of dependency graph files.

I forgot that one.  I found that the class dependencies aren't
represented in the graph.  It seems to be just the providers(?) / bb files.

> 
> bitbake -DDD (enabling a ton of debugging) will also show you which
> files it touches and why.
>


I'll give this a spin!


> > Its taken me a long time figure out all the OE files that effect the
> > build of my image.  It be nice to make things easier for folks that come
> > after me to do the same type of thing....
> 
> Help with the documentation is more than welcome!

That is my intention, at least to start with.

Something of a draft will be coming in a few weekends, as this all sinks
in a bit more.

Thanks so much for your help!

--mgross


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]