Skip to content
A collection of build utils to used in with yocto
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
classes
conf
recipes-python/kconfiglib
.gitignore
LICENSE
README.md

README.md

meta-buildutils

A collection of build utils to used in with yocto

auto-inherit

Purpose

With the help of this class you can dynamically inherit other classes into any recipe based on conditions

Usage

You can either insert

INHERIT += "auto-inherit.bbclass"

into your distro configuration or into conf/local.conf of your build directory

Configuration

Configuration is done by bitbake variable AUTO_INHERIT_CONF. It is a space separated list of item (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.

Available builtin function

auto_inherit_contains_package

Checks if the current recipe DEPENDS of 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
auto_inherit_is_at_path

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
auto_inherit_license

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
auto_inherit_has_source

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

Examples

AUTO_INHERIT_CONF = "BBClass=foo;props=[auto_inherit_is_at_path(d,'meta-foo/recipes-foo/',False)]"

This 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.*')]"

This 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')]"

This will inherit bar.bbclass into each recipe which DEPENDS of python3

python-speedups

Purpose

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.

Usage

Just inherit the class into the image-recipe you want to tune

Configuration

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 integration them into the standard lib

kconfig-sanity

Purpose

This class does check if *.cfg fragments of KConfig-based systems are apply 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.

Usage

Just inherit the class into any recipe using KConfig. Stock recipes are busybox, linux-yocto, u-boot.

Configuration

Following configuration variables can be used. All variables have reasonable default values, so you actually only have to alter the things needed

  • KCONFIG_SANITY_FRAGMENT_EVAL [string 0:1] - Enables the check on *.cfg-fragments, the so called fragment-mode

  • KCONFIG_SANITY_FRAGEMENT_KCONFIG_EXPLAIN [string 0:1] - Enables detailed explanation why an CONFIG_-option can't be applied

  • 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_CONFIG_PRE [string] - prefix of CONFIG_-options

  • KCONFIG_SANITY_FRAGMENT_PATH [path] - path where to search for *.cfg fragments

  • KCONFIG_SANITY_KCONFIGS [paths] - paths where to look for KConfig input file

  • 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_NO_MATCH [note,warn,error] - Logger function to trigger if a value has changed in 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_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_COMPLETE_OLD_NA [note,warn,error] - Logger function to trigger if a value has been set previously but is no absent due to missing KConfig in complete-mode

  • KCONFIG_SANITY_FRAGMENT_NO_MATCH [note,warn,error] - Logger function to trigger if a value has changed in fragment-mode

  • 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_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_OLD_NA [note,warn,error] - Logger function to trigger if a value has been set previously but is no absent due to missing KConfig in fragment-mode

Remarks

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

layer-sanity

Purpose

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.

Usage

Just inherit this class into any recipe

Configuration

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.

Examples

Let's say you want the varibale 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 try 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 ass the following into your recipe

LAYER_SANITY_PROT_FILES += "defconfig"

buildutils-helper

Purpose

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_extention - Find files by file-extension
  • buildutils_get_files_by_extention_or_shebang - Combined result of buildutils_get_files_by_shebang + buildutils_get_files_by_extention

Usage

This should only be used indirectly

python-package-ident

Purpose

This class does tyr to identify the needed bitbake-packages for the python code found in the recipe-packages. On any findings it will give advice via console

Usage

For python3 installation please inherit python3-package-ident.

For python2 installation please inherit python-package-ident

You can’t perform that action at this time.