Tasks: Playing with tasks

Bitbake steps through a series of tasks when building a recipe. Sometimes you need to explicitly define what a class does, such as providing a do_install function to implement the install task in a recipe and sometimes they are provided for you by common classes, such as the autotools class providing the default implementations of configure, compile and install tasks.

There are several methods available to modify the tasks that are being run:

Overriding the default task implementation

By defining your own implementation of task you'll override any default or class provided implementations.

For example, you can define you own implementation of the compile task to override any default implementation:

do_compile() {
      oe_runmake DESTDIR=${D}

If you with to totally prevent the task from running you need to define your own empty implementation. This is typically done via the definition of the task using a single colon:

do_configure() {
Appending or prepending to the task

Sometime you want the default implementation, but you require addition functionality. This can done by appending or pre-pending additional functionality onto the task.

The following example from units shows an example of installing an addition file which for some reason was not installed via the autotools normal install task:

do_install_append() {
       install -d ${D}${datadir}
       install -m 0655 units.dat ${D}${datadir}

The following example from the cherokee recipe show an example of adding functionality prior to the default install task. In this case it compiles a program that is used during installation natively so that it will work on the host. Without this the autotools default install task would fail since it'd try to run the program on the host which was compiled for the target:

do_install_prepend () {
        # It only needs this app during the install, so compile it natively
        $BUILD_CC -DHAVE_SYS_STAT_H -o cherokee_replace cherokee_replace.c
Defining a new task

Another option is define a totally new task, and then register that with bitbake so that it runs in between two of the existing tasks.

The following example shows a situation in which a cvs tree needs to be copied over the top of an extracted tar.gz archive, and this needs to be done before any local patches are applied. So a new task is defined to perform this action, and then that task is registered to run between the existing unpack and patch tasks:

    cp -pPR ${WORKDIR}/linux/* ${S}
addtask unpack_extra after do_unpack before do_patch


The task to add does not have the do_ prepended to it, however the tasks to insert it after and before do have the _do prepended. No errors will be generated if this is wrong, the additional task simple won't be executed.

Using overrides

Overrides (described fully elsewhere) allow for various functionality to be performed conditionally based on the target machine, distribution, architecture etc.

While not commonly used it is possible to use overrides when defining tasks. The following example from udev shows an additional file being installed for the specified machine only by performing an append to the install task for the h2200 machine only:

do_install_append_h2200() {
    install -m 0644 ${WORKDIR}/50-hostap_cs.rules         ${D}${sysconfdir}/udev/rules.d/50-hostap_cs.rules