[oe] bitbake and OE opperation
tim.bird at am.sony.com
Wed Mar 28 22:10:32 CEST 2007
Not to belabor this, but I'm going to try to repeat
this stuff back, to make sure I understand.
Richard Purdie wrote:
>> There are the following lines - I don't know if they're related or not:
>> addtask build after do_populate_staging
>> do_build = ""
>> do_build[func] = "1"
> These are very much related, it defines that there is a build task (with
> an associated function which defaults to empty). It says this build task
> depends on a "populate_staging" task.
So this is similar to:
in a makefile.
>> Maybe I'm thinking procedurally, and this is all declarative, but where
>> the heck are the actual statements executed during a "build"?
> Nothing is executed by "build" itself, the key is in the dependency on
In this case, since build has no actual
commands associated with it, it is like a PHONY target in
> They're not hardcoded, the sequence is made through the definition of
> tasks, each of which depend on each other. Very roughly:
> build depends on populate_staging
> populate_staging depends on package_write
> package_write depends on package
> package depends on install
> install depends on compile
> compile depends on configure
> configure depends on patch
> patch depends on unpack
> unpack depends on fetch
>From base.bbclass, if I grep addtask, I see:
addtask fetchall after do_fetch
addtask unpack after do_fetch
addtask configure after do_unpack do_patch
addtask compile after do_configure
addtask populate_staging after do_package_write
addtask install after do_compile
addtask build after do_populate_staging
So there appear to be "island" tasks (e.g.showdata, clean),
that are not part of the main sequence for a build. I presume these
are accessible via the command line in bitbake?
I don't see an addtask for "patch" in there. Is this added
to the dependency tree somewhere else? Is this something
that is package-specific?
Also, there appear to be multiple parallel
dependencies (fetchall and unpack are both after fetch).
How are these ordered? (What is "fetchall" anyway?)
Tasks package and package_write are also referenced but not "addtask"ed
to the graph.
> Incidentally, don't be put off by the "do_" prefix, this is just to
> highlight things as tasks when their usage might otherwise be
Is "do_" ignored in task declarations, references, or both?
> Does that make it clearer?
I assume that .bb files can arbitrarily define some new
task and graft it into the dependency tree.
In your experience, are there many other custom (package-specific)
tasks like this?
Here is my idea of what each task does:
Can you please check this?
build - meta-task to cover the whole build process
populate_staging - (same as do_stage?) - put package contents in staging area?
package_write - ??
package - collect files files from install locations into some kind of collection (dependent on package format)
install - place files (e.g. built binaries) at install locations
compile - make
configure - run configure
patch - apply patches to source
unpack - unpack tarballs
fetch - grab sources from Internet - turn into tarballs
Are there any other major tasks?
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Electronics
More information about the Openembedded-devel