| version | build status |
|---|---|
| master |  |
| zeus |  |
| warrior |  |
| thud |  |
A collection of build utils to used in with YOCTO
- auto-inherit
- python-speedups
- kconfig-sanity
- layer-sanity
- buildutils-helper
- python-package-ident
- rm_orphans
- rootfs-chart
- hashdog
With the help of this class you can dynamically inherit other classes into any recipe based on conditions
You can either insert
INHERIT += "auto-inherit.bbclass"into your distro configuration or into conf/local.conf of your build directory
Configuration is done by bitbake variable AUTO_INHERIT_CONF. It is a space separated list of items (see below). Best is to place this variable along the inherit. E.g.
INHERIT += "auto-inherit.bbclass"
AUTO_INHERIT_CONF = "BBClass=foo;props[a,b,c]"each value is formatted in the following way
BBClass=<class>;props=[func_foo(d),func_foo2(d,param)]The identifier BBClass specifies what other bbclass to be included. The props identifier specifies a list of python-function, which all must return true for the class at BBClass to become included into the recipe currently parsed.
Checks if the current recipe DEPENDS on another package. Parameters are
- d [object] for the current data-storage of bitbake
- pn [string] for the package-name to be checked for
- skipNative [bool:True] for ignoring -native packages on lookup
Checks if the current recipe is located at a certain path (or below) relative to project root Parameters are
- d [object] for the current data-storage of bitbake
- path [string] path to check for
- skip_bbappend [bool:True] for ignoring bbappend-files on lookup
Checks if a recipe is published under a particular license Parameters are
- d [object] for the current data-storage of bitbake
- license_regex [regex] regular expression describing the license to check for
Checks if the recipe contains specific resources in it's SRC_URI entry
- d [object] for the current data-storage of bitbake
- source_regex [regex] regular expression describing the entries to check for
AUTO_INHERIT_CONF = "BBClass=foo;props=[auto_inherit_is_at_path(d,'meta-foo/recipes-foo/',False)]"will inherit foo.bbclass into each recipe (and bbappend) placed under meta-foo/recipes-foo/
AUTO_INHERIT_CONF = "BBClass=bar;props=[auto_inherit_license(d,'GPL.*')]"will inherit bar.bbclass into each recipe licensed under "GPL" (including all variants like GPLv2, GPLv3, a.s.o.)
AUTO_INHERIT_CONF = "BBClass=bar;props=[auto_inherit_contains_package(d,'python3')]"will inherit bar.bbclass into each recipe which DEPENDS of python3
This class does try to improve the startup speed of the deployed python-interpreter by doing some tweaks. There is a blog-post which explains the background a little more in detail. You can expect between 10-25% speedup of startup time, without the need to change any code.
Just inherit the class into the image-recipe you want to tune
The tuneup amount can be controlled by variable PYTHON_SPEEDUP_TARGETS. This variable is a space separated list which can contain the following items
- compile_all - This forces a python-compiler run on the rootfs. Very useful when you have a readonly filesystem on your target
- binary_tweak - This patches the python-CLI options. See blog-post for details
- no_sitepackage - This disables the usage of side-packages by integrating them into the standard lib
This class does check if *.cfg fragments of KConfig-based systems are applied to resulting configuration. It also tries to provide information why a particular CONFIG-option can't be applied. This is very helpful when upgrading a system. Also this class offers methods for comparing the actual used configuration against a known configuration in repository.
Just inherit the class into any recipe using KConfig. Stock recipes are busybox, linux-yocto, u-boot.
Following configuration variables can be used. All variables have reasonable default values, so you actually only have to alter things when needed
- KCONFIG_SANITY_BLACKLIST [string] - List of CONFIG-options to ignore on checkup
- KCONFIG_SANITY_COMPAREFILES [string] - List of files which will be compared to resulting configuration. Leave empty to disable complete-mode
- KCONFIG_SANITY_COMPLETE_NEW_SET [note,warn,error] - Logger function to trigger if a new and set value has been detected in complete-mode
- KCONFIG_SANITY_COMPLETE_NEW_UNSET [note,warn,error] - Logger function to trigger if a new but unset value has been detected in complete-mode
- KCONFIG_SANITY_COMPLETE_NO_MATCH [note,warn,error] - Logger function to trigger if a value has changed in complete-mode
- KCONFIG_SANITY_COMPLETE_OLD_NA [note,warn,error] - Logger function to trigger if a value has been set previously but is now absent due to missing KConfig in complete-mode
- KCONFIG_SANITY_COMPLETE_OLD_UNSET_EXISTS [note,warn,error] - Logger function to trigger if a value has been set previously but is currently unset but existing in KConfig in complete-mode
- KCONFIG_SANITY_CONFIG_PRE [string] - prefix of CONFIG-options
- KCONFIG_SANITY_DEFCONFIG [path] - Path where the defconfig-file is placed in recipe workspace
- KCONFIG_SANITY_FINALCONF [path] - Path where the actually applied configuration is stored in recipe workspace
- KCONFIG_SANITY_FRAGMENT_EVAL [string 0:1] - Enables the check on *.cfg-fragments, the so called fragment-mode
- KCONFIG_SANITY_FRAGMENT_KCONFIG_EXPLAIN [string 0:1] - Enables detailed explanation why a CONFIG-option can't be applied
- KCONFIG_SANITY_FRAGMENT_NEW_SET [note,warn,error] - Logger function to trigger if a new and set value has been detected in fragment-mode
- KCONFIG_SANITY_FRAGMENT_NEW_UNSET [note,warn,error] - Logger function to trigger if a new but unset value has been detected in fragment-mode
- KCONFIG_SANITY_FRAGMENT_NO_MATCH [note,warn,error] - Logger function to trigger if a value has changed in fragment-mode
- KCONFIG_SANITY_FRAGMENT_OLD_NA [note,warn,error] - Logger function to trigger if a value has been set previously but is now absent due to missing KConfig in fragment-mode
- KCONFIG_SANITY_FRAGMENT_OLD_UNSET_EXISTS [note,warn,error] - Logger function to trigger if a value has been set previously but is currently unset but existing in KConfig in fragment-mode
- KCONFIG_SANITY_FRAGMENT_PATH [path] - path where to search for *.cfg fragments
- KCONFIG_SANITY_KCONFIGS [paths] - paths where to look for KConfig input file
if you want to use the complete-mode when checking you have to prepare a compare-configuration file. This file has to be named either
- compare-config.${MACHINE} [e.g. compare-config.qemux86-64]
- compare-config
at least one of these files has to be included into SRC_URI-variable of the recipe to become effective
When you are working with different layer, you may find it often confusing that, due to the bbappend-functionality, any layer can alter the recipe code without further notice. This comes in very unhandy when you might be relying of a certain functionality or configuration.
This class does offer a possibility to 'protect' certain variables of a recipe from being altered by any bbappend. Also it can 'protect' files from being overloaded by bbappends.
Just inherit this class into any recipe
To protect a variable from being changed you have to add the variable name to LAYER_SANITY_PROT_VARS. LAYER_SANITY_PROT_VARS is a list of regular expression separated by spaces.
To protect a files from being changed you have to add the file name (with relative path if needed) to LAYER_SANITY_PROT_FILES.
Let's say you want the variable EXTRA_OEMAKE not being altered by any bbappend - then all you have insert into your recipe is
LAYER_SANITY_PROT_VARS += "EXTRA_OEMAKE.*"if now any of the bbappends tries to modify the content of the variable an message will be shown with the change done.
If you also want to 'protect' the file defconfig add the following into your recipe
LAYER_SANITY_PROT_FILES += "defconfig"A collection of helper functions. Currently it does offer
- buildutils_find_in_layer - Finds a file somewhere among all configured layers
- buildutils_get_files_by_shebang - Find files by shebang
- buildutils_get_files_by_extension - Find files by file-extension
- buildutils_get_files_by_extension_or_shebang - Combined result of buildutils_get_files_by_shebang + buildutils_get_files_by_extension
This should only be used indirectly
This class does try to identify the needed bitbake-packages for the python code found in the recipe-packages. On any findings it will give advice via console
For python3 installation please inherit python3-package-ident.
For python2 installation please inherit python-package-ident
This class can be included globally (meaning in the distro or local.conf) to remove the leftover log-files, which bitbake leaves for whatever reason in each recipe's TEMP-dir. After this process only files (run + log) from the last run will remain. This should help mitigating the excessive disk spamming of bitbake
Add e.g. to local.conf
INHERIT += "rm_orphans"This class generates additonal dot-graphs for an image recipe, where this class is inherited to.
- $DEPLOY_DIR_IMAGE/$PN-packages.dot - will show a graph with all packages installed to the image and there dependencies, which are (obviously) also installed
- $DEPLOY_DIR_IMAGE/$PN-recipes.dot - will show all recipes involved in generating the image. This includes native and cross recipes as well. Only the pure recipe-basename is shown
- $DEPLOY_DIR_IMAGE/$PN-package-map.json - will dump a key-value json mapping the packages to recipes
Add e.g. to any image recipe
inherit rootfs-chartThe class identifies variables used in a task, which cause sstate corruptions, as they either point to a local path or are known to be build host specific
Add
INHERIT += "hashdog"to your local.conf
- HASHDOG_CULP - sets variables, which are known to be build host specific
- HASHDOG_EXCL - sets the variables which are not taken into account for calculating the task hash
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent