Re: bitbake and OE opperation

[Tim Bird <tim.bird@am.sony.com>]

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:

build: do_populate_staging

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
> "populate_staging".
> 
In this case, since build has no actual
commands associated with it, it is like a PHONY target in
a makefile?

> 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 showdata
addtask listtasks
addtask clean
addtask rebuild
addtask mrproper
addtask fetch
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
> ambiguous.

Is "do_" ignored in task declarations, references, or both?

> Does that make it clearer?
Yes, thanks.

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?

=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Electronics
=============================