"libxslt.do_configure" -> "libxml2.do_populate_sysroot"
The above example line reveals that the do_configure task in libxslt depends on the
do_populate_sysroot task in libxml2, which is a normal DEPENDS dependency between the two
recipes.
For an example of how .dot files can be processed, see the scripts/contrib/graph-tool
Python script, which finds and displays paths between graph nodes.
You can use a different method to view dependency information by using the following command:
$ bitbake -g -u taskexp
recipename
This command displays a GUI window from which you can view build-time and runtime dependencies for the recipes involved in building
recipename
.
2.3.5. Viewing Task Variable Dependencies¶
As mentioned in the "Checksums (Signatures)" section of the BitBake User Manual, BitBake tries to automatically determine what
variables a task depends on so that it can rerun the task if any values of the variables change. This determination is usually reliable.
However, if you do things like construct variable names at runtime, then you might have to manually declare dependencies on those
variables using vardeps as described in the "Variable Flags" section of the BitBake User Manual.
If you are unsure whether a variable dependency is being picked up automatically for a given task, you can list the variable dependencies
BitBake has determined by doing the following:
1. Build the recipe containing the task:
$ bitbake
recipename
2. Inside the STAMPS_DIR directory, find the signature data (sigdata) file that corresponds to the task. The sigdata files
contain a pickled Python database of all the metadata that went into creating the input checksum for the task. As an example, for
the do_fetch task of the db recipe, the sigdata file might be found in the following location:
${BUILDDIR}/tmp/stamps/i586-poky-linux/db/6.0.30-r1.do_fetch.sigdata.7c048c18222b16ff0bcee2000ef648b1
For tasks that are accelerated through the shared state (sstate) cache, an additional siginfo file is written into SSTATE_DIR
along with the cached task output. The siginfo files contain exactly the same information as sigdata files.
3. Run bitbake-dumpsig on the sigdata or siginfo file. Here is an example:
$ bitbake-dumpsig ${BUILDDIR}/tmp/stamps/i586-poky-linux/db/6.0.30-r1.do_fetch.sigdata.7c048c18222b16ff0bcee2000ef648b1
In the output of the above command, you will find a line like the following, which lists all the (inferred) variable dependencies for
the task. This list also includes indirect dependencies from variables depending on other variables, recursively.
Task dependencies: ['PV', 'SRCREV', 'SRC_URI', 'SRC_URI[md5sum]', 'SRC_URI[sha256sum]', 'base_do_fetch']
Note
Functions (e.g. base_do_fetch) also count as variable dependencies. These functions in turn depend
on the variables they reference.
The output of bitbake-dumpsig also includes the value each variable had, a list of dependencies for each variable, and
BB_HASHBASE_WHITELIST information.
There is also a bitbake-diffsigs command for comparing two siginfo or sigdata files. This command can be helpful when
trying to figure out what changed between two versions of a task. If you call bitbake-diffsigs with just one file, the command
behaves like bitbake-dumpsig.
You can also use BitBake to dump out the signature construction information without executing tasks by using either of the following
BitBake command-line options:
‐‐dump-signatures=
SIGNATURE_HANDLER
-S
SIGNATURE_HANDLER
Note
Two common values for
SIGNATURE_HANDLER
are "none" and "printdiff", which dump only the signature or compare
the dumped signature with the cached one, respectively.
Using BitBake with either of these options causes BitBake to dump out sigdata files in the stamps directory for every task it would
have executed instead of building the specified target package.
2.3.6. Running Specific Tasks¶
Any given recipe consists of a set of tasks. The standard BitBake behavior in most cases is: do_fetch, do_unpack, do_patch,
do_configure, do_compile, do_install, do_package, do_package_write_*, and do_build. The default task
is do_build and any tasks on which it depends build first. Some tasks, such as do_devshell, are not part of the default build
chain. If you wish to run a task that is not part of the default build chain, you can use the -c option in BitBake. Here is an example: