OpenEmbedded-Core: Difference between revisions

Latest revision as of 21:20, 2 September 2018

OpenEmbedded-Core

Introduction

Current versions of OpenEmbedded are based on OpenEmbedded-Core (OE-Core). OE-Core has evolved from collaboration efforts with the Yocto Project as well as a recognition that the model previously being used in OpenEmbedded was unsustainable.

The original OpenEmbedded repository (also known as "OE-Classic" or "oe-dev") grew organically over the years to more than 7500 recipes, covering approximately 300 machines and 20 distros. Trying to maintain this amount of metadata with machine and distro overrides scattered throughout was very difficult, and near to impossible to support commercially. Like many other OE forks that were created to solve the same kinds of issues, Poky was forked as a cleaner and more supportable version of OE in 2006. Fast forwarding to the present, Poky is now maintained as a reference distribution under the Yocto Project with the support of the Linux Foundation. OE-Core was split out from Poky in 2011 to allow collaboration around a relatively small and easily supportable base, with real machines, distros and other items removed - more on this below.

OE-Classic is no longer maintained. New efforts should be built on top of OE-Core. The new OE layer ecosystem provides full support for building typical embedded Linux systems, support for many target machines and additional software packages. There are still some recipes and machine support that have yet to be ported over from OE classic, however recipes and configuration can be easily brought over, tidied up and placed into the appropriate layer over time.

Differences to OE-classic

The most significant change is that metadata is now split into multiple layers rather than being in one repository. OE-Core sits at the bottom, and machine / application / distro layers are added on top. Users are free to select support for whatever applications or platforms they wish in their configuration simply by including the appropriate layer in their bblayers.conf file.

Machine and distro-specific overrides should no longer be spread over the entire set of recipes - instead they should be concentrated in appropriate machine support layers (often referred to as BSP (Board Support Package) layers) and distro layers respectively. BitBake's .bbappend feature allows overriding almost any element of a recipe without too much duplication across multiple layers.

Additionally, OE-Core moves changes to a pull model rather than the push model of OE-classic - instead of all developers having direct commit access, patches are sent to the mailing list for review and if/when satisfactory they are merged by the maintainer. Other layers may choose to use either the push or pull model for contributions.

OpenEmbedded-Core scope

The scope of OE-Core itself is as follows:

Support for the major architectures: ARM, x86, PowerPC, MIPS (and 64-bit variants of all of these)
Only QEMU emulated machines
Distro-less (DISTRO = "nodistro" and default values are used)
Only one X-based GUI environment (Sato) intended for testing purposes. (This may be substituted out in future if a suitable replacement testing framework can be created.)
Only the recipes that are needed by almost everyone, needed for LSB support (optional) or are needed for testing other parts of OE-Core
Attempt to keep only one version of each recipe

Anything not in OE-Core can easily be provided by additional layers on top; other layers can also be used to e.g. support older recipe versions that have been removed from OE-Core.

meta-openembedded

For items shared amongst multiple layers that do not fit into OE-Core or any other existing layer, there is the meta-oe layer. This exists in a repository, also called meta-openembedded, which contains a number of other more focused layers (meta-efl, meta-gnome, etc.). This layer will need to be managed carefully over time to avoid it turning into just a newer version of OE-classic.

Getting Started

See Getting started.

Available Layers

OpenEmbedded maintains an list of layers that can be used with OE-Core - see the layer index.

Creating Layers

See Creating a new Layer.

Required changes for existing metadata

See Migrating metadata to OE-Core

@@ Line 1: / Line 1: @@
 == OpenEmbedded-Core ==
+<!-- keywords: oe core OE-Core meta-oe meta-openembedded classic oe-classic dev oe-dev -->
 === Introduction ===
-New versions of OpenEmbedded will be based on OpenEmbedded-Core (OE-core). OE-core has evolved from collaboration efforts with the Yocto project as well as a recognition that the model previously being used in OpenEmbedded was unsustainable.
+Current versions of OpenEmbedded are based on OpenEmbedded-Core (OE-Core). OE-Core has evolved from collaboration efforts with the Yocto Project as well as a recognition that the model previously being used in OpenEmbedded was unsustainable.
-The original OpenEmbedded repository (also known as "OE-classic" or "oe-dev") has grown organically over the years to more than 7500 recipes, covering approximately 300 machines and 20 distros. Trying to maintain this amount of metadata with machine and distro overrides scattered throughout is very difficult, and near to impossible to support commercially. Like many other OE forks that have been created to solve the same kinds of issues, Poky was forked as a cleaner and more supportable version of OE in 2006. Fast forward to 2011, Poky is now maintained by the Yocto Project with the support of the Linux Foundation. OE-core was split out from Poky in 2011 to allow collaboration around a relatively small and easily supportable base, with real machines, distros and other items removed - more on this below.
+The original OpenEmbedded repository (also known as "OE-Classic" or "oe-dev") grew organically over the years to more than 7500 recipes, covering approximately 300 machines and 20 distros. Trying to maintain this amount of metadata with machine and distro overrides scattered throughout was very difficult, and near to impossible to support commercially. Like many other OE forks that were created to solve the same kinds of issues, Poky was forked as a cleaner and more supportable version of OE in 2006. Fast forwarding to the present, Poky is now maintained as a reference distribution under the Yocto Project with the support of the Linux Foundation. OE-Core was split out from Poky in 2011 to allow collaboration around a relatively small and easily supportable base, with real machines, distros and other items removed - more on this below.
-OE-classic will stop being maintained in the near future - there are no further stable releases planned and new efforts should be built on top of OE-core. The new OE layer ecosystem doesn't yet contain the full wealth of machine and application support that OE classic currently has, however recipes can be easily brought over, tidied up and placed into the appropriate layer over time.
+OE-Classic is no longer maintained. New efforts should be built on top of OE-Core. The new OE layer ecosystem provides full support for building typical embedded Linux systems, support for many target machines and additional software packages. There are still some recipes and machine support that have yet to be ported over from OE classic, however recipes and configuration can be easily brought over, tidied up and placed into the appropriate layer over time.
 === Differences to OE-classic ===
-The most significant change is that metadata is now split into multiple layers rather than being in one repository. OE-core sits at the bottom, and machine / application / distro layers are added on top. Users are free to select support for whatever applications or platforms they wish in their configuration simply by including the appropriate layer in their bblayers.conf file.
+The most significant change is that metadata is now split into multiple layers rather than being in one repository. OE-Core sits at the bottom, and machine / application / distro layers are added on top. Users are free to select support for whatever applications or platforms they wish in their configuration simply by including the appropriate layer in their bblayers.conf file.
 Machine and distro-specific overrides should no longer be spread over the entire set of recipes - instead they should be concentrated in appropriate machine support layers (often referred to as BSP (Board Support Package) layers) and distro layers respectively. BitBake's .bbappend feature allows overriding almost any element of a recipe without too much duplication across multiple layers.
-Additionally, OE-core moves changes to a pull model rather than the push model of OE-classic - instead of all developers having direct commit access, patches are sent to the mailing list for review and if/when satisfactory they are merged by the maintainer. Other layers may choose to use either the push or pull model for contributions.
+Additionally, OE-Core moves changes to a pull model rather than the push model of OE-classic - instead of all developers having direct commit access, patches are sent to the mailing list for review and if/when satisfactory they are merged by the maintainer. Other layers may choose to use either the push or pull model for contributions.
 === OpenEmbedded-Core scope ===
-The scope of OE-core is currently not as well defined as it could be, however the following initial rules have been established:
+The scope of OE-Core itself is as follows:
-* Support for five architectures: ARM, x86, x86-64, PowerPC and MIPS
+* Support for the major architectures: ARM, x86, PowerPC, MIPS (and 64-bit variants of all of these)
 * Only QEMU emulated machines
-* Distro-less (DISTRO = "" and default values are used)
+* Distro-less (DISTRO = "nodistro" and default values are used)
 * Only one X-based GUI environment (Sato) intended for testing purposes. (This may be substituted out in future if a suitable replacement testing framework can be created.)
-* Attempt to keep only one version of each recipe except for GPLv2 / v3 versions
+* Only the recipes that are needed by almost everyone, needed for LSB support (optional) or are needed for testing other parts of OE-Core
+* Attempt to keep only one version of each recipe
-Anything not in OE-core can easily be provided by another layer; other layers can also be used to support older versions that have been removed from OE-core.
+Anything not in OE-Core can easily be provided by additional layers on top; other layers can also be used to e.g. support older recipe versions that have been removed from OE-Core.
 === meta-openembedded ===
-For items shared amongst multiple layers that cannot be included (or immediately included) in OE-core, there is the meta-openembedded layer. This exists in a repository, also called [http://cgit.openembedded.org/cgit.cgi/meta-openembedded meta-openembedded], which contains a number of other more focused layers (meta-efl, meta-gnome, etc.). This layer will need to be managed carefully over time to avoid it turning into just a newer version of OE-classic.
+For items shared amongst multiple layers that do not fit into OE-Core or any other existing layer, there is the meta-oe layer. This exists in a repository, also called [http://git.openembedded.org/meta-openembedded/ meta-openembedded], which contains a number of other more focused layers (meta-efl, meta-gnome, etc.). This layer will need to be managed carefully over time to avoid it turning into just a newer version of OE-classic.
 == Getting Started ==
-As OE-core can be used to build working images entirely on its own, you can get started with it immediately. See [http://wiki.yoctoproject.org/wiki/OpenEmbedded-Core this page] for instructions.
+See [[Getting started]].
 == Available Layers ==
-OpenEmbedded maintains an list of layers that can be used with OE-core - see [[LayerIndex]].
+OpenEmbedded maintains an list of layers that can be used with OE-Core - see the [http://layers.openembedded.org layer index].
 == Creating Layers ==
-=== Required changes ===
+See [[Creating a new Layer]].
-The classes and BitBake configuration used in OE-core requires a few changes for recipes brought over from OE-classic (and for new recipes written by developers used to working with OE-classic):
-* LIC_FILES_CHKSUM is mandatory, and will be checked at the end of do_configure. It is used in order to specify one or more files or sections of files from the source that can be used to detect if the license of the software has been changed in a newer version.
-* Legacy staging (do_stage) is no longer supported and BitBake will error out on parse of recipes that use it. Items previously in do_stage should be moved to do_install as appropriate.
-* The LICENSE field, whilst usually included in most recipes in the past anyway, is now mandatory. It should be as specific and as correct as possible (e.g. "GPLv2", not just "GPL") and try to be consistent with other recipes.
-* Any calls to oenote, oewarn, oefatal etc. need to be replaced with the "bb" equivalent, i.e. bbnote, bbwarn, bbfatal etc.
-* Recent versions of BitBake no longer allow comments in multi-line strings, so the tradition of being able to comment out lines within a multi-line SRC_URI or when setting configure flags etc. can no longer continue. Remove the commented out lines or move them to beyond where the string terminates.
-* Modifications to FILESPATHPKG and/or FILESPATH should be replaced by prepending to FILESEXTRAPATHS; in addition, you no longer need to define THISDIR (and should not do so). For example, to add a directory to be searched for patches and other files which is named with PN, do the following (note the immediate evaluation operator := and trailing colon, these are important):
- FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
-=== Best practices ===
-To aid maintainability, the following recommendations are made for creating new layers:
+== Required changes for existing metadata ==
-* Avoid "overlaying" entire recipes (i.e. copying the entire recipe into your layer and modifying it). Use .bbappend files to override the parts of the recipe you need to modify.
+See [[Migrating metadata to OE-Core]]
-* Avoid duplicating include files - use .bbappends for each recipe that uses the inc file, or if you're introducing a new recipe that requires it, use the full path to refer to the original (e.g. require recipes-core/somepackage/somefile.inc instead of require somefile.inc). If you're finding you have to overlay the inc file it may indicate a deficiency in the inc file in the layer it originally belongs to, which should be addressed instead. An example here would be the way Qt 4 database support plugins are configured - OE-core doesn't have MySQL or PostgreSQL, however meta-oe does, so meta-oe uses .bbappends to modify a variable QT_SQL_DRIVER_FLAGS to enable the appropriate plugins. This variable was added to qt4.inc in OE-core specifically to allow meta-oe to be able to control which plugins are built.

OpenEmbedded-Core: Difference between revisions

Latest revision as of 21:20, 2 September 2018

Contents