| Description | |
|---|---|
| bitbake | Bake an image (add -k to continue building even errors are found in the tasks execution) |
| bitbake | Execute a particular package's task. Default Tasks names: fetch, unpack, patch, configure, compile, install, package, package_write, and build.Example: To (force) compiling a kernel and then build, type: $ bitbake linux-imx -f -c compile $ bitbake linux-imx |
| bitbake | Show the package dependency for image. Example: To show all packages included on fsl-image-gui $ bitbake fsl-image-gui -g -u depexp |
| bitbake | Open a new shell where with neccesary system values already defined for package |
| hob | bitbake frontend/GUI. |
| bitbake | List all tasks for package |
| bitbake virtual/kernel -c menuconfig | Interactive kernel configuration |
| bitbake | Fetch sources for a particular image |
| bitbake-layers show-layers | Show layers |
| bitbake-layers show-recipes "*-image-*" | Show possible images to bake. Without "*-images-*", it shows ALL recipes |
| bitbake -g <image> && cat pn-depends.dot | grep -v -e '-native' | grep -v digraph | grep -v -e '-image' | awk '{print $1}' | sort | uniq | Show image's packages |
| bitbake -g <pkg> && cat pn-depends.dot | grep -v -e '-native' | grep -v digraph | grep -v -e '-image' | awk '{print $1}' | sort | uniq bitbake -g <packagename> -u taskexp | Show package's dependencies |
| bitbake –v | Print (on console) and store verbose baking |
| bitbake -s | grep | Check if certain package is present on current Yocto Setup |
| Option | Meaning |
|---|---|
| -c |
execute |
| -f | force execution of the operation, even if not required |
| -v | show verbose output |
| -DDD | show lots of debug information |
| -s | show recipe version information |
| --help | get usage help |
| -c listtasks |
show the tasks associated with an image or individual recipe |
| -g |
output dependency tree in graphviz format |
| User interface | Type | NOTES |
|---|---|---|
| bitbake "bitbake -u knotty |
scrolling text interface | This is the default user interface |
| bitbake -u ncurses |
text-window based interface | I couldn't figure out how to control or exit this interface |
| bitbake -u hob | graphical interface | This is a full graphical interface which includes selecting machine, distro, etc. and performing a build |
| bitbake -u goggle |
simple graphical interface | This is a simple graphical wrapper over the streaming text output of bitbake. It's nice in that it shows collapsible trees for the logs for sub-tasks for each recipe. |
| Syntax | Meaning | NOTES |
|---|---|---|
| VAR = "foo" | simple assignment | |
| VAR ?= "foo" | assign if no other value is already assigned (default assignment) | |
| VAR ??=foo | weak default assignment | takes lower precedence than ?= |
| VAR = "stuff ${OTHER_VAR} more" | variable expansion | OTHER_VAR expanded at time of reference to VAR |
| VAR := "stuff ${OTHER_VAR} more" | immediate variable expansion | OTHER_VAR expanded at time of parsing this line |
| VAR += "foo" | append with space | |
| VAR =+ "foo" | prepend with space | |
| VAR .= "foo" | append without space | |
| VAR =. "foo" | prepend without space | |
| VAR_append = "foo" | append without space | |
| OVERRIDES="string1:string2" VAR = "foo" VAR_string1 = "bar" |
alternate/override value | if string1 is listed in OVERRIDES, use "bar" for value of VAR, otherwise use "foo" |
| OVERRIDES="string1:string2" VAR = "foo" VAR_append_string1 = " bar" |
conditional append | if string1 is in OVERRIDES, then append " bar" to the value of VAR |
| BBVERSIONS="1.0 1.8 string" VAR="foo" VAR_string="bar" |
range-specific conditional | If the version of the package is in the specified range (1.0-1.8 in this example), then perform an override on the indicated variable |
| VAR = "foo ${@ |
python code expansion | ex: VAR = "the date is: ${@time.strftime(’%Y%m%d’,time.gmtime())}" |
| include foo | include file | include file named "foo", search BBPATH |
| require [ |
require file | include file named "foo", failing if not found exactly where specified |
| inherit foo | inherit classes | include definitions from foo.bbclass |
do_sometask() {} |
define a task using shell code | |
python do_sometask {} |
define a task using python code | |
| addtask sometask (before|after) other_task | add a task | adds a defined task to the list of tasks, with the ordering specified. Zero or more 'before' or 'after' clauses can be used. |
| VAR[some_flag]="foo" | associate a subsidiary flag value to a variable | a few subsidiary flag value names are well-defined: "dirs", "cleandirs", "noexec", "nostamp", "fakeroot", "umask", "deptask", "rdeptask", "recdeptask", "recrdeptask" Flag values appear to be used exclusively with task definitions (i.e. do_sometask) |
inherit externalsrc EXTERNALSRC = "/some/path" # EXTERNALSRC_BUILD = "/some/path" |
Fetch source from /some/path | You can place this at the bottom of a .bb or .bbappend file to override where the source will be fetched from. This is very convenient if you are currently working on the source code. Depending on the type of build (eg, 'inherit module' for out of tree Linux kernel modules) you may or may not need to set EXTERNALSRC_BUILD. |
| Command | Description | NOTES |
|---|---|---|
| bitbake-layers | Show information about layers and recipes | Included in the bitbake/bin directory in yocto. |
| bitbake-env | Show invidividual bitbake variable values | see: http://www.crashcourse.ca/wiki/index.php/OE_bitbake-env_utility |
| bitbake -g -u depexp |
Show dependency information in a graphical interface |
:
The stack trace of python calls that resulted in this exception/failure was:
File: '', lineno: 9, function:
0005:__anon_419__work_yulin_mdm9640le_apps_proc_oe_core_meta_classes_package_ipk_bbclass(d)
0006:__anon_27__work_yulin_mdm9640le_apps_proc_oe_core_meta_classes_devshell_bbclass(d)
0007:__anon_77__work_yulin_mdm9640le_apps_proc_oe_core_meta_classes_sstate_bbclass(d)
0008:__anon_124__work_yulin_mdm9640le_apps_proc_oe_core_meta_classes_siteinfo_bbclass(d)
*** 0009:__anon_26__work_yulin_mdm9640le_apps_proc_oe_core_meta_qcom_classes_qcommon_bbclass(d)
File: '__anon_26__work_yulin_mdm9640le_apps_proc_oe_core_meta_qcom_classes_qcommon_bbclass', lineno: 2, function: __anon_26__work_yulin_mdm9640le_apps_proc_oe_core_meta_qcom_classes_qcommon_bbclass
0001:def __anon_26__work_yulin_mdm9640le_apps_proc_oe_core_meta_qcom_classes_qcommon_bbclass(d):
*** 0002: src_dir_after_parse(d)
0003:
File: 'qcommon.bbclass', lineno: 5, function: src_dir_after_parse
0001:def src_dir_after_parse(d):
0002: if d.getVar('SRC_DIR') == None:
0003: raise bb.build.FuncFailed("%s inherits qcommon but doesn't set SRC_DIR" % d.getVar('FILE'))
0004: if d.getVar('PREBUILT') == "1":
*** 0005: bb.build.addtask('do_prebuilt', 'do_build', 'do_populate_sysroot', d)
0006:
Exception: AttributeError: 'module' object has no attribute 'addtask'
ERROR: Failed to parse recipe: /work/yulin/mdm9640le/apps_proc/oe-core/meta-qcom/recipes/mcm-gps/loc-mcm-type-conv_git.bb | ETA: 00:00:08
ERROR: Error executing a python function in :
INSANE_SKIP_AAAA += "dev-deps" could be a workaround.
From : Paul Eggleton <paul.eggleton at linux.intel.com> To : Kilou Zelabia <kilou_zellabia at yahoo.fr> Cc : yocto at yoctoproject.org Envoyé le : Mercredi 13 juin 2012 12h36 Objet : Re: [yocto] ERROR : QA issue : package AAAA rdepends on BBBB-dev On Wednesday 13 June 2012 09:38:32 Kilou Zelabia wrote: > What does this mean ? Why it is forbidden to have a run-time dependency on a > "-dev" package ? Because that's usually not correct. The -dev package includes headers and other development files for the target. Is that really what package AAAA needs at runtime? > I'v seen some recipes setting INSANE_SKIP to "1" can this helps ? You would need to use INSANE_SKIP_AAAA += "dev-deps". But I would encourage you to verify that this is what you really need before doing it. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre