mirror of
https://github.com/lvgl/lvgl.git
synced 2026-05-22 07:02:05 +08:00
docs(yocto): add guide to integrate lvgl recipe in Yocto (#7024)
This commit is contained in:
Gabriel
GitHub
@@ -11,3 +11,4 @@
|
||||
px5
|
||||
mqx
|
||||
qnx
|
||||
yocto/index
|
||||
|
||||
@@ -0,0 +1,146 @@
|
||||
Yocto Project Core Components
|
||||
#############################
|
||||
|
||||
The BitBake task executor together with various types of configuration files
|
||||
form the OpenEmbedded-Core (OE-Core). This section overviews these components
|
||||
by describing their use and how they interact.
|
||||
|
||||
BitBake handles the parsing and execution of the data files. The data
|
||||
itself is of various types:
|
||||
|
||||
- *Recipes:* Provides details about particular pieces of software.
|
||||
|
||||
- *Class Data:* Abstracts common build information (e.g. how to build a
|
||||
Linux kernel).
|
||||
|
||||
- *Configuration Data:* Defines machine-specific settings, policy
|
||||
decisions, and so forth. Configuration data acts as the glue to bind
|
||||
everything together.
|
||||
|
||||
BitBake knows how to combine multiple data sources together and refers
|
||||
to each data source as a layer.
|
||||
|
||||
Here are some brief details on these core components.
|
||||
|
||||
.. _bitbake_section:
|
||||
|
||||
BitBake
|
||||
*******
|
||||
|
||||
BitBake is the tool at the heart of the OpenEmbedded Build System and is
|
||||
responsible for parsing the Metadata, generating a list of tasks from it, and
|
||||
then executing those tasks.
|
||||
|
||||
This section briefly introduces BitBake. If you want more information on
|
||||
BitBake, see the `BitBake User Manual <https://docs.yoctoproject.org/bitbake/2.
|
||||
8/index.html>`_.
|
||||
|
||||
To see a list of the options BitBake supports, use either of the
|
||||
following commands::
|
||||
|
||||
$ bitbake -h
|
||||
$ bitbake --help
|
||||
|
||||
The most common usage for BitBake is ``bitbake recipename``, where
|
||||
``recipename`` is the name of the recipe you want to build (referred
|
||||
to as the "target"). The target often equates to the first part of a
|
||||
recipe's filename (e.g. "foo" for a recipe named ``foo_1.3.0-r0.bb``).
|
||||
So, to process the ``matchbox-desktop_1.2.3.bb`` recipe file, you might
|
||||
type the following::
|
||||
|
||||
$ bitbake matchbox-desktop
|
||||
|
||||
Several different versions of ``matchbox-desktop`` might exist. BitBake chooses
|
||||
the one selected by the distribution configuration. You can get more details
|
||||
about how BitBake chooses between different target versions and providers in the
|
||||
"`Preferences <https://docs.yoctoproject.org/bitbake/2.8/bitbake-user-manual/
|
||||
bitbake-user-manual-execution.html#preferences>`_" section of the BitBake User
|
||||
Manual.
|
||||
|
||||
BitBake also tries to execute any dependent tasks first. So for example,
|
||||
before building ``matchbox-desktop``, BitBake would build a cross
|
||||
compiler and ``glibc`` if they had not already been built.
|
||||
|
||||
A useful BitBake option to consider is the ``-k`` or ``--continue``
|
||||
option. This option instructs BitBake to try and continue processing the
|
||||
job as long as possible even after encountering an error. When an error
|
||||
occurs, the target that failed and those that depend on it cannot be
|
||||
remade. However, when you use this option other dependencies can still
|
||||
be processed.
|
||||
|
||||
.. _recipes_section:
|
||||
|
||||
Recipes
|
||||
*******
|
||||
|
||||
Files that have the ``.bb`` suffix are "recipes" files. In general, a
|
||||
recipe contains information about a single piece of software. This
|
||||
information includes the location from which to download the unaltered
|
||||
source, any source patches to be applied to that source (if needed),
|
||||
which special configuration options to apply, how to compile the source
|
||||
files, and how to package the compiled output.
|
||||
|
||||
The term "package" is sometimes used to refer to recipes. However, since
|
||||
the word "package" is used for the packaged output from the OpenEmbedded
|
||||
build system (i.e. ``.ipk`` or ``.deb`` files), this document avoids
|
||||
using the term "package" when referring to recipes.
|
||||
|
||||
|
||||
.. _classes_section:
|
||||
|
||||
Classes
|
||||
*******
|
||||
|
||||
Class files (``.bbclass``) contain information that is useful to share
|
||||
between recipes files. An example is the autotools* class,
|
||||
which contains common settings for any application that is built with
|
||||
the `GNU Autotools <https://en.wikipedia.org/wiki/GNU_Autotools>`.
|
||||
The "`Classes <https://docs.yoctoproject.org/ref-manual/classes.
|
||||
html#classes>`_" chapter in the Yocto Project
|
||||
Reference Manual provides details about classes and how to use them.
|
||||
|
||||
|
||||
.. _configurations_section:
|
||||
|
||||
Configurations
|
||||
**************
|
||||
|
||||
The configuration files (``.conf``) define various configuration
|
||||
variables that govern the OpenEmbedded build process. These files fall
|
||||
into several areas that define machine configuration options,
|
||||
distribution configuration options, compiler tuning options, general
|
||||
common configuration options, and user configuration options in
|
||||
``conf/local.conf``, which is found in the `Build Directory <https://docs.
|
||||
yoctoproject.org/ref-manual/terms.html#term-Build-Directory>`_.
|
||||
|
||||
.. _layers_section:
|
||||
|
||||
Layers
|
||||
******
|
||||
|
||||
Layers are repositories that contain related metadata (i.e. sets of
|
||||
instructions) that tell the OpenEmbedded build system how to build a
|
||||
target. `The yocto project layer model <https://docs.yoctoproject.org/
|
||||
overview-manual/yp-intro.html#the-yocto-project-layer-model>`_
|
||||
facilitates collaboration, sharing, customization, and reuse within the
|
||||
Yocto Project development environment. Layers logically separate
|
||||
information for your project. For example, you can use a layer to hold
|
||||
all the configurations for a particular piece of hardware. Isolating
|
||||
hardware-specific configurations allows you to share other metadata by
|
||||
using a different layer where that metadata might be common across
|
||||
several pieces of hardware.
|
||||
|
||||
There are many layers working in the Yocto Project development environment. The
|
||||
`Yocto Project Compatible Layer Index <https://www.yoctoproject.org/development/
|
||||
yocto-project-compatible-layers/>`_ and `OpenEmbedded Layer Index <https://
|
||||
layers.openembedded.org/layerindex/branch/master/layers/>`_ both contain layers
|
||||
from
|
||||
which you can use or leverage.
|
||||
|
||||
By convention, layers in the Yocto Project follow a specific form. Conforming
|
||||
to a known structure allows BitBake to make assumptions during builds on where
|
||||
to find types of metadata. You can find procedures and learn about tools (i.e.
|
||||
``bitbake-layers``) for creating layers suitable for the Yocto Project in the
|
||||
"`understanding and creating layers <https://docs.yoctoproject.org/dev-manual/
|
||||
layers.html#understanding-and-creating-layers>`_" section of the
|
||||
Yocto Project Development Tasks Manual.
|
||||
@@ -0,0 +1,25 @@
|
||||
Yocto
|
||||
#####
|
||||
|
||||
The Yocto Project (YP) is an open source collaboration project that helps
|
||||
developers create custom Linux-based systems regardless of the hardware
|
||||
architecture.
|
||||
|
||||
The project provides a flexible set of tools and a space where embedded
|
||||
developers worldwide can share technologies, software stacks, configurations,
|
||||
and best practices that can be used to create tailored Linux images for
|
||||
embedded and IOT devices, or anywhere a customized Linux OS is needed.
|
||||
|
||||
This section objective is to ease to process of understanding the basic
|
||||
concepts of Yocto and to help beginners to start with Yocto.
|
||||
|
||||
|
||||
.. toctree::
|
||||
:titlesonly:
|
||||
:maxdepth: 1
|
||||
|
||||
core_components
|
||||
lvgl_recipe
|
||||
terms_and_variables
|
||||
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,193 @@
|
||||
Yocto Project Terms
|
||||
###################
|
||||
|
||||
Getting started in Yocto can be overwheming. There are many terms used that are
|
||||
specific to Yocto and Bitbake environment.
|
||||
|
||||
A list of terms and definitions users new to the Yocto Project
|
||||
development environment might find helpful can be found `here <https://docs.
|
||||
yoctoproject.org/ref-manual/terms.html>`_.
|
||||
|
||||
|
||||
Yocto Variables Glossary
|
||||
########################
|
||||
|
||||
This chapter lists basic variables used in the LVGL Yocto guide and gives an
|
||||
overview of their function and contents.
|
||||
|
||||
A More complete variable glossary can be found in `Yocto Variable Glossary
|
||||
<https://docs.yoctoproject.org/ref-manual/variables.html>`_. This section
|
||||
covers a lot of variables used in the OpenEmbedded build system.
|
||||
|
||||
.. _S:
|
||||
|
||||
S
|
||||
=
|
||||
|
||||
The location in the Build Directory where unpacked recipe source code resides.
|
||||
By default, this directory is ${WORKDIR}/${BPN}-${PV}, where ${BPN} is the
|
||||
base recipe name and ${PV} is the recipe version. If the source tarball
|
||||
extracts the code to a directory named anything other than ${BPN}-${PV}, or if
|
||||
the source code is fetched from an SCM such as Git or Subversion, then you
|
||||
must set S in the recipe so that the OpenEmbedded build system knows where to
|
||||
find the unpacked source.
|
||||
|
||||
As an example, assume a Source Directory top-level folder named poky and a
|
||||
default Build Directory at poky/build. In this case, the work directory the
|
||||
build system uses to keep the unpacked recipe for db is the following:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
poky/build/tmp/work/qemux86-poky-linux/db/5.1.19-r3/db-5.1.19
|
||||
|
||||
The unpacked source code resides in the db-5.1.19 folder.
|
||||
|
||||
This next example assumes a Git repository. By default, Git repositories are
|
||||
cloned to ${WORKDIR}/git during do_fetch. Since this path is different from the
|
||||
default value of S, you must set it specifically so the source can be located:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
SRC_URI = "git://path/to/repo.git;branch=main"
|
||||
S = "${WORKDIR}/git"
|
||||
|
||||
|
||||
.. _D:
|
||||
|
||||
D
|
||||
=
|
||||
|
||||
The destination directory. The location in the Build Directory where components
|
||||
are installed by the do_install task. This location defaults to:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
${WORKDIR}/image
|
||||
|
||||
.. note::
|
||||
|
||||
Tasks that read from or write to this directory should run under fakeroot.
|
||||
|
||||
.. _B:
|
||||
|
||||
B
|
||||
=
|
||||
|
||||
The directory within the Build Directory in which the OpenEmbedded build system
|
||||
places generated objects during a recipe's build process. By default, this
|
||||
directory is the same as the S directory, which is defined as:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
S = "${WORKDIR}/${BP}"
|
||||
|
||||
You can separate the (S) directory and the directory pointed to by the B
|
||||
variable. Most Autotools-based recipes support separating these directories.
|
||||
The build system defaults to using separate directories for gcc and some kernel
|
||||
recipes.
|
||||
|
||||
.. _WORKDIR:
|
||||
|
||||
WORKDIR
|
||||
=======
|
||||
|
||||
The pathname of the work directory in which the OpenEmbedded build system
|
||||
builds a recipe. This directory is located within the TMPDIR directory
|
||||
structure and is specific to the recipe being built and the system for which it
|
||||
is being built.
|
||||
|
||||
The WORKDIR directory is defined as follows:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
${TMPDIR}/work/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}
|
||||
|
||||
The actual directory depends on several things:
|
||||
|
||||
- **TMPDIR**: The top-level build output directory
|
||||
- **MULTIMACH_TARGET_SYS**: The target system identifier
|
||||
- **PN**: The recipe name
|
||||
- **EXTENDPE**: The epoch — if PE is not specified, which is usually the
|
||||
case for most recipes, then EXTENDPE is blank.
|
||||
- **PV**: The recipe version
|
||||
- **PR**: The recipe revision
|
||||
|
||||
As an example, assume a Source Directory top-level folder name poky, a default
|
||||
Build Directory at poky/build, and a qemux86-poky-linux machine target system.
|
||||
Furthermore, suppose your recipe is named foo_1.3.0-r0.bb. In this case, the
|
||||
work directory the build system uses to build the package would be as follows:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
poky/build/tmp/work/qemux86-poky-linux/foo/1.3.0-r0
|
||||
|
||||
.. _PN:
|
||||
|
||||
PN
|
||||
==
|
||||
|
||||
This variable can have two separate functions depending on the context: a
|
||||
recipe name or a resulting package name.
|
||||
|
||||
PN refers to a recipe name in the context of a file used by the OpenEmbedded
|
||||
build system as input to create a package. The name is normally extracted from
|
||||
the recipe file name. For example, if the recipe is named expat_2.0.1.bb, then
|
||||
the default value of PN will be “expat”.
|
||||
|
||||
The variable refers to a package name in the context of a file created or
|
||||
produced by the OpenEmbedded build system.
|
||||
|
||||
If applicable, the PN variable also contains any special suffix or prefix. For
|
||||
example, using bash to build packages for the native machine, PN is
|
||||
bash-native. Using bash to build packages for the target and for Multilib, PN
|
||||
would be bash and lib64-bash, respectively.
|
||||
|
||||
.. _PR:
|
||||
|
||||
PR
|
||||
==
|
||||
|
||||
The revision of the recipe. The default value for this variable is
|
||||
"r0". Subsequent revisions of the recipe conventionally have the
|
||||
values "r1", "r2", and so forth. When PV increases,
|
||||
PR is conventionally reset to "r0".
|
||||
|
||||
.. note::
|
||||
|
||||
The OpenEmbedded build system does not need the aid of PR to know when to
|
||||
rebuild a recipe. The build system uses the task input checksums along with
|
||||
the stamp and shared state cache mechanisms.
|
||||
|
||||
The PR variable primarily becomes significant when a package
|
||||
manager dynamically installs packages on an already built image. In
|
||||
this case, PR, which is the default value of
|
||||
PKGR, helps the package manager distinguish which
|
||||
package is the most recent one in cases where many packages have the
|
||||
same PV (i.e. PKGV). A component having many packages with
|
||||
the same PV usually means that the packages all install the same
|
||||
upstream version, but with later (PR) version packages including
|
||||
packaging fixes.
|
||||
|
||||
.. note::
|
||||
|
||||
PR does not need to be increased for changes that do not change the
|
||||
package contents or metadata.
|
||||
|
||||
Because manually managing PR can be cumbersome and error-prone,
|
||||
an automated solution exists. See the
|
||||
"`working with a pr service <https://docs.yoctoproject.org/dev-manual/packages.
|
||||
html#working-with-a-pr-service>`_" section in the Yocto Project Development
|
||||
Tasks Manual for more information.
|
||||
|
||||
.. _PV:
|
||||
|
||||
PV
|
||||
==
|
||||
|
||||
The version of the recipe. The version is normally extracted from the recipe
|
||||
filename. For example, if the recipe is named expat_2.0.1.bb, then the default
|
||||
value of PV will be “2.0.1”. PV is generally not overridden within a recipe
|
||||
unless it is building an unstable (i.e. development) version from a source code
|
||||
repository (e.g. Git or Subversion).
|
||||
|
||||
PV is the default value of the PKGV variable.
|
||||
Reference in New Issue
Block a user