mirror of
https://github.com/tuxbox-neutrino/buildenv.git
synced 2025-08-26 15:02:58 +02:00
update README
This commit is contained in:
215
README-en.md
215
README-en.md
@@ -1,215 +0,0 @@
|
|||||||
Note: This is an automatically translated file. Original content from [here](https://github.com/tuxbox-neutrino/buildenv/blob/3.2.4/README-de.md):
|
|
||||||
|
|
||||||
# Quick start image creation #
|
|
||||||
|
|
||||||
- [Preparation](#Preparation)
|
|
||||||
- [Build Image](#build-image)
|
|
||||||
- [Update](#Update)
|
|
||||||
- [Working on Target Sources](#Working-on-Target-Sources)
|
|
||||||
- [Overview of global configuration files](#overview-of-global-configuration-files)
|
|
||||||
|
|
||||||
## Preparation
|
|
||||||
|
|
||||||
### Install required host packages (Debian 11)
|
|
||||||
For use with other distributions see: [Yocto Project Quick Build](https://docs.yoctoproject.org/3.2.4/ref-manual/ref-system-requirements.html#supported-linux-distributions)
|
|
||||||
|
|
||||||
> :memo: **NOTE:** If using the Tuxbox Builder VM (which is not mandatory), please skip to [Step 1](#1-clone-init-script). The Tuxbox Builder VM already contains required packages. Details and download of Tuxbox-Builder VM see: [Tuxbox-Builder](https://sourceforge.net/projects/n4k/files/Tuxbox-Builder)
|
|
||||||
|
|
||||||
```bash
|
|
||||||
apt-get install -y gawk wget git-core diffstat unzip texinfo gcc-multilib build-essential \
|
|
||||||
chrpath socat cpio python python3 python3-pip python3-pexpect xz-utils debianutils \
|
|
||||||
iputils-ping python3-git python3-jinja2 libegl1-mesa pylint3 xterm subversion locales-all \
|
|
||||||
libxml2-utils ninja-build default-jre clisp libcapstone4 libsdl2-dev doxygen
|
|
||||||
```
|
|
||||||
> :memo: **NOTE:** On Debian 10 (buster) use libcapstone3.
|
|
||||||
|
|
||||||
#### Recommended additional packages for graphical support and analysis (e.g. with Kdevelop, Meld):
|
|
||||||
```bash
|
|
||||||
apt-get install -y gitk git-gui meld cppcheck clazy kdevelop
|
|
||||||
```
|
|
||||||
|
|
||||||
### Optional: If there is no configured Git, please enter your global Git user data:
|
|
||||||
```bash
|
|
||||||
git config --global user.email "you@example.com"
|
|
||||||
git config --global user.user "Your name"
|
|
||||||
```
|
|
||||||
|
|
||||||
## Build image
|
|
||||||
|
|
||||||
> :memo: **Note:** Some paths are based on defaults generated by the init script. Some entries are displayed as ```<placeholder>```, which need to be adjusted accordingly.
|
|
||||||
|
|
||||||
> ### 1. Clone init script.
|
|
||||||
```bash
|
|
||||||
git clone https://github.com/tuxbox-neutrino/buildenv.git
|
|
||||||
cd buildenv
|
|
||||||
```
|
|
||||||
|
|
||||||
> ### 2. Run init script
|
|
||||||
```bash
|
|
||||||
./init
|
|
||||||
cd poky-3.2.4
|
|
||||||
```
|
|
||||||
|
|
||||||
> ### 3. Show list of possible machine types
|
|
||||||
```bash
|
|
||||||
ls build
|
|
||||||
```
|
|
||||||
|
|
||||||
> ### 4. Run environment script
|
|
||||||
```bash
|
|
||||||
. ./oe-init-build-env build/<enter machine type from the list from step 3 here>
|
|
||||||
```
|
|
||||||
|
|
||||||
> ### 5. Build
|
|
||||||
```bash
|
|
||||||
bitbake neutrino image
|
|
||||||
```
|
|
||||||
|
|
||||||
This could take a while. Some warning messages can be ignored. Error messages affecting the setscene tasks are not a problem, but errors during the build and package tasks terminate the process in most cases. [In this case, please report the error or send your solution to us](https://forum.tuxbox-neutrino.org/forum/viewforum.php?f=77). Help is very welcome.
|
|
||||||
|
|
||||||
When everything is done, you should see a message similar to this:
|
|
||||||
```bash
|
|
||||||
...
|
|
||||||
NOTE: Tasks Summary: Attempted 4568 tasks of which 4198 didn't need to be rerun and all succeeded.
|
|
||||||
...
|
|
||||||
```
|
|
||||||
**That's it...**
|
|
||||||
|
|
||||||
Created images and packages can be found at:
|
|
||||||
```
|
|
||||||
~/build/poky-3.2.4/build/<machine>/tmp/deploy
|
|
||||||
```
|
|
||||||
or in the dist directory:
|
|
||||||
```
|
|
||||||
~/build/dist/<image version>/<machine>/
|
|
||||||
```
|
|
||||||
|
|
||||||
## Update
|
|
||||||
> :memo: Manual updates for arbitrary target sources are not required. This is done automatically for every target accessed using Bitbake. This means that required dependencies are always updated. If you want full control over specific target sources, see [Working on Target Sources](#Working-on-Target-Sources)!
|
|
||||||
|
|
||||||
If [Steps 1 to 4](View #3-list-of-possible-machine-types) have already been completed, only step 5 is required:
|
|
||||||
|
|
||||||
### Update image
|
|
||||||
```bash
|
|
||||||
bitbake neutrino image
|
|
||||||
```
|
|
||||||
|
|
||||||
### Update target
|
|
||||||
```bash
|
|
||||||
bitbake <target>
|
|
||||||
```
|
|
||||||
|
|
||||||
### Update meta layer repositories
|
|
||||||
Re-executing the init script updates the included meta layers to the status of the remote repositories.
|
|
||||||
```bash
|
|
||||||
cd $HOME/build
|
|
||||||
./init
|
|
||||||
```
|
|
||||||
The triggered update routines of the init script should temporarily stash uncommitted changes or rebase local commits to the remote changes. However, conflicts must be resolved manually. Of course, you can manually update and modify your local meta layers for meta neutrino and machine layer repositories.
|
|
||||||
|
|
||||||
> :memo: **Note:** Configuration files remain untouched. New or changed configuration options are not taken into account. Please check the configuration if necessary.
|
|
||||||
|
|
||||||
## Working on target sources
|
|
||||||
If you want to have full control over the target sources, the source codes should be moved to the workspace. Please refer
|
|
||||||
[devtool](https://docs.yoctoproject.org/current/ref-manual/devtool-reference.html) and especially [devtool modify](https://docs.yoctoproject.org/current/ref-manual/devtool-reference.html#modifying-an-existing-recipe).
|
|
||||||
|
|
||||||
## Reset configuration
|
|
||||||
If you want to reset your machine configurations, please rename the conf directory (deletion is not recommended) and run the init script again.
|
|
||||||
```bash
|
|
||||||
mv $HOME/build/poky-3.2.4/build/<machine>/conf $HOME/build/poky-3.2.4/build/<machine>/conf.01
|
|
||||||
cd $HOME/build
|
|
||||||
./init
|
|
||||||
```
|
|
||||||
|
|
||||||
## Force rebuild of a single target
|
|
||||||
In some cases it can happen that a target breaks off for whatever reason. You shouldn't panic and delete the tmp folder and the sstate cache. You can also do this for each target individually.
|
|
||||||
|
|
||||||
> :memo: In particular, broken archive URLs can lead to termination. However, these errors are always displayed and you can check the URL. Often it's just the servers and they even work again after a few minutes.
|
|
||||||
|
|
||||||
To make sure whether the recipe in question actually has a problem, it makes sense to completely clean up the target in question and rebuild it. To enforce this, all generated package, build and cache data must be cleaned up.
|
|
||||||
```bash
|
|
||||||
bitbake -c cleansstate <target>
|
|
||||||
```
|
|
||||||
then rebuild:
|
|
||||||
```bash
|
|
||||||
bitbake <target>
|
|
||||||
```
|
|
||||||
|
|
||||||
## Force full image build
|
|
||||||
If you want to force a complete image build, you can delete (or rename) the tmp directory:
|
|
||||||
```bash
|
|
||||||
mv tmp tmp.01
|
|
||||||
bitbake neutrino image
|
|
||||||
```
|
|
||||||
If you have **not** cleared the sstate cache, the image should be built in a relatively short time. Therefore, it is recommended to keep the sstate cache. The directory where the sstate cache is located is determined via the variable ```${SSTATE_DIR}``` and can be adjusted in the configuration.
|
|
||||||
|
|
||||||
This directory is quite valuable and only in rare cases is it necessary to delete this directory. Please note that the build will take much longer in this case.
|
|
||||||
> :bulb: You can tell Bitbake not to use sstate cache.
|
|
||||||
```bash
|
|
||||||
bitbake --no-setscene neutrino-image
|
|
||||||
```
|
|
||||||
or
|
|
||||||
```bash
|
|
||||||
bitbake --skip-setscene neutrino-image
|
|
||||||
```
|
|
||||||
|
|
||||||
## Adjust if necessary
|
|
||||||
It is recommended to build for the first time without making any changes to the configuration files to get an idea of how the build process works and to see the results.
|
|
||||||
The setting options are very extensive and not really manageable for beginners. However, the Yoctoproject is very
|
|
||||||
comprehensively documented and provides the best source of information.
|
|
||||||
|
|
||||||
**Important for developers**: "[Working on Target Sources](#Working-on-Target-Sources)"!
|
|
||||||
|
|
||||||
> :memo: **Please do not change the Yocto recipes! This is not recommended by the Yocto team, but you can use [.bbappend](https://docs.yoctoproject.org/3.2.4/dev-manual/dev-manual-common-tasks.html#using-bbappend-files-in-your-layer) files.**
|
|
||||||
|
|
||||||
### Overview of global configuration files
|
|
||||||
For local configuration, these configuration files are required within the build directories:
|
|
||||||
|
|
||||||
> $HOME/build/poky-3.2.4/build/```<machine>```/conf/local.conf
|
|
||||||
|
|
||||||
This generated local.conf only contains a few lines, but has a line that points to a common configuration file that is valid for all images and supported machine types and can be fed with your own options.
|
|
||||||
|
|
||||||
> $HOME/build/local.conf.common.inc
|
|
||||||
|
|
||||||
This **.inc** file was created from the cloned example file when running the init script for the first time.
|
|
||||||
|
|
||||||
> local.conf.common.inc.sample
|
|
||||||
|
|
||||||
This example file should be left untouched to avoid possible conflicts when updating the build repository and to see what might have changed.
|
|
||||||
|
|
||||||
After an update to the build repository, some new or changed options may have been added or removed that are not reflected in the included configuration file. You should take this case into account in your own configuration and adapt it if necessary.
|
|
||||||
Of course, you can modify ```$HOME/Build/poky-3.2.4/build/<machine>/conf/local.conf``` with your own requirements and use it as a separate configuration file for a machine type.
|
|
||||||
|
|
||||||
#### Sample configuration for bblayers.conf:
|
|
||||||
> $HOME/build/poky-3.2.4/build/```<machine>```/conf/bblayers.conf
|
|
||||||
|
|
||||||
```bitbake
|
|
||||||
# POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf
|
|
||||||
# changes incompatibly
|
|
||||||
POKY_BBLAYERS_CONF_VERSION = "2"
|
|
||||||
|
|
||||||
BBPATH = "${TOPDIR}"
|
|
||||||
BBFILES ?= ""
|
|
||||||
|
|
||||||
BBLAYERS ?= " \
|
|
||||||
/home/<username>build/poky-3.2.4/meta \
|
|
||||||
/home/<username>/build/poky-3.2.4/meta-poky \
|
|
||||||
/home/<username>/build/poky-3.2.4/meta-yocto-bsp \
|
|
||||||
"
|
|
||||||
BBLAYERS += "\
|
|
||||||
/home/<username>/build/poky-3.2.4/meta-neutrino \
|
|
||||||
/home/<username>/build/poky-3.2.4/meta-<machine-brand-or-bsp-name> \
|
|
||||||
/home/<username>/build/poky-3.2.4/meta-openembedded/meta-oe \
|
|
||||||
"
|
|
||||||
BBLAYERS += "\
|
|
||||||
/home/<username>/build/poky-3.2.4/meta-python2 \
|
|
||||||
"
|
|
||||||
BBLAYERS += "\
|
|
||||||
/home/<username>/build/poky-3.2.4/meta-qt5 \
|
|
||||||
"
|
|
||||||
```
|
|
||||||
|
|
||||||
## More information
|
|
||||||
Further information about the Yocto build system:
|
|
||||||
|
|
||||||
* https://docs.yoctoproject.org/3.2.4/index.html
|
|
||||||
14
README.md
14
README.md
@@ -1,7 +1,9 @@
|
|||||||
|
# Documentation
|
||||||
|
|
||||||
## Localized `README.md`'s
|
This document is available in the following languages:
|
||||||
|
|
||||||
| Language |
|
<!-- LANGUAGE_LINKS_START -->
|
||||||
| -------------------------- |
|
[🇩🇪 German](README_de.md) | [🇬🇧 English](README_en.md) | [🇪🇸 Spanish](README_es.md) | [🇫🇷 French](README_fr.md) | [🇮🇹 Italian](README_it.md)
|
||||||
| [English](README-en.md) |
|
<!-- LANGUAGE_LINKS_END -->
|
||||||
| [German](README-de.md) |
|
|
||||||
|
Please choose your preferred language by clicking on the links above.
|
||||||
@@ -1,364 +1,373 @@
|
|||||||
Dieses Skript dient als Werkzeug zur Vereinfachung der Erstellung einer Umgebung für Entwicklung und des Build-Prozesses für Images die mit Neutrino als Benutzeroberfläche auf unterschiedlichen Hardware-Plattformen laufen. Es automatisiert einige Schritte, die für die Einrichtung einer konsistenten und funktionalen Entwicklungs- und Build-Umgebung erforderlich sind, indem es die notwendigen Abhängigkeiten und grundlegende Konfigurationen sowie Meta-Layer voreinrichtet und benutzerdefinierte Einstellungen ermöglicht. Das Skript zielt darauf ab, eine Grundlage zu bieten, auf der man aufbauen und experimentieren kann, um eigene angepasste Versionen von Tuxbox-Neutrino Images zu erstellen, zu aktualisieren und zu pflegen.
|
<!-- LANGUAGE_LINKS_START -->
|
||||||
|
<span style="color: grey;">🇩🇪 German</span> | [🇬🇧 English](README_en.md) | [🇪🇸 Spanish](README_es.md) | [🇫🇷 French](README_fr.md) | [🇮🇹 Italian](README_it.md)
|
||||||
- [1. Vorbereitung](#1-vorbereitung)
|
<!-- LANGUAGE_LINKS_END -->
|
||||||
- [1.1 Erforderliche Host-Pakete installieren](#11-erforderliche-host-pakete-installieren)
|
|
||||||
- [1.1.1 Empfohlene Zusatzpakete zur grafischen Unterstützung und Analyse](#111-empfohlene-zusatzpakete-zur-grafischen-unterstützung-und-analyse)
|
Dieses Skript dient als Werkzeug zur Vereinfachung der Erstellung einer Umgebung für Entwicklung und des Build-Prozesses für Images die mit Neutrino als Benutzeroberfläche auf unterschiedlichen Hardware-Plattformen laufen. Es automatisiert einige Schritte, die für die Einrichtung einer konsistenten und funktionalen Entwicklungs- und Build-Umgebung erforderlich sind, indem es die notwendigen Abhängigkeiten und grundlegende Konfigurationen sowie Meta-Layer voreinrichtet und benutzerdefinierte Einstellungen ermöglicht. Das Skript zielt darauf ab, eine Grundlage zu bieten, auf der man aufbauen und experimentieren kann, um eigene angepasste Versionen von Tuxbox-Neutrino Images zu erstellen, zu aktualisieren und zu pflegen.
|
||||||
- [1.2 Git vorbereiten (falls erforderlich)](#12-git-vorbereiten-falls-erforderlich)
|
|
||||||
- [1.3 Init-Skript klonen](#13-init-skript-klonen)
|
[](https://github.com/dbt1/tuxbox-explorer)
|
||||||
- [1.4 Init-Skript ausführen](#14-init-skript-ausführen)
|
|
||||||
- [1.5 Struktur der Buildumgebung](#15-struktur-der-buildumgebung)
|
- [1. Vorbereitung](#1-vorbereitung)
|
||||||
- [2. Image bauen](#2-image-bauen)
|
- [1.1 Erforderliche Host-Pakete installieren](#11-erforderliche-host-pakete-installieren)
|
||||||
- [2.1 Box wählen](#21-box-wählen)
|
- [1.1.1 Empfohlene Zusatzpakete zur grafischen Unterstützung und Analyse](#111-empfohlene-zusatzpakete-zur-grafischen-unterstützung-und-analyse)
|
||||||
- [2.2 Starte Umgebungsskript](#22-starte-umgebungsskript)
|
- [1.2 Git vorbereiten (falls erforderlich)](#12-git-vorbereiten-falls-erforderlich)
|
||||||
- [2.3 Image erstellen](#23-image-erstellen)
|
- [1.3 Init-Skript klonen](#13-init-skript-klonen)
|
||||||
- [3. Aktualisierung](#3-aktualisierung)
|
- [1.4 Init-Skript ausführen](#14-init-skript-ausführen)
|
||||||
- [3.1 Image aktualisieren](#31-image-aktualisieren)
|
- [1.5 Struktur der Buildumgebung](#15-struktur-der-buildumgebung)
|
||||||
- [3.2 Paket aktualisieren](#32-paket-aktualisieren)
|
- [2. Image bauen](#2-image-bauen)
|
||||||
- [3.3 Meta-Layer-Repositorys aktualisieren](#33-meta-layer-repositorys-aktualisieren)
|
- [2.1 Box wählen](#21-box-wählen)
|
||||||
- [4. Eigene Anpassungen](#4-eigene-anpassungen)
|
- [2.2 Starte Umgebungsskript](#22-starte-umgebungsskript)
|
||||||
- [4.1 Konfiguration](#41-konfiguration)
|
- [2.3 Image erstellen](#23-image-erstellen)
|
||||||
- [4.1.1 Konfigurationsdateien](#411-konfigurationsdateien)
|
- [3. Aktualisierung](#3-aktualisierung)
|
||||||
- [4.1.2 bblayers.conf](#412-bblayersconf)
|
- [3.1 Image aktualisieren](#31-image-aktualisieren)
|
||||||
- [4.1.3 Konfiguration zurücksetzen](#413-konfiguration-zurücksetzen)
|
- [3.2 Paket aktualisieren](#32-paket-aktualisieren)
|
||||||
- [4.3 Recipes](#43-recipes)
|
- [3.3 Meta-Layer-Repositorys aktualisieren](#33-meta-layer-repositorys-aktualisieren)
|
||||||
- [4.4 Pakete](#44-pakete)
|
- [4. Eigene Anpassungen](#4-eigene-anpassungen)
|
||||||
- [4.4.1 Quellcode im Workspace bearbeiten (Beispiel)](#441-quellcode-im-workspace-bearbeiten-beispiel)
|
- [4.1 Konfiguration](#41-konfiguration)
|
||||||
- [5. Neubau eines einzelnen Pakets erzwingen](#5-neubau-eines-einzelnen-pakets-erzwingen)
|
- [4.1.1 Konfigurationsdateien](#411-konfigurationsdateien)
|
||||||
- [6. Vollständigen Imagebau erzwingen](#6-vollständigen-imagebau-erzwingen)
|
- [4.1.2 bblayers.conf](#412-bblayersconf)
|
||||||
- [7. Lizenz](#7-lizenz)
|
- [4.1.3 Konfiguration zurücksetzen](#413-konfiguration-zurücksetzen)
|
||||||
- [8. Weiterführende Informationen](#8-weiterführende-informationen)
|
- [4.3 Recipes](#43-recipes)
|
||||||
|
- [4.4 Pakete](#44-pakete)
|
||||||
## 1. Vorbereitung
|
- [4.4.1 Quellcode im Workspace bearbeiten (Beispiel)](#441-quellcode-im-workspace-bearbeiten-beispiel)
|
||||||
|
- [5. Neubau eines einzelnen Pakets erzwingen](#5-neubau-eines-einzelnen-pakets-erzwingen)
|
||||||
Empfohlen sei an dieser Stelle, den dafür vorgesehenen Docker-Container zu verwenden, da damit schon wesentliche Schritte erledigt sind, um mit möglichst wenig Anpassungen an seinem System, loslegen zu können. [siehe docker-buildenv](https://github.com/tuxbox-neutrino/docker-buildenv). In diesem Fall kann man gleich [mit der Initialisierung](#14-init-skript-ausführen) beginnen.
|
- [6. Vollständigen Imagebau erzwingen](#6-vollständigen-imagebau-erzwingen)
|
||||||
|
- [7. Lizenz](#7-lizenz)
|
||||||
**HINWEIS:** [docker-buildenv](https://github.com/tuxbox-neutrino/docker-buildenv) löst die [Tuxbox-Builder](https://sourceforge.net/projects/n4k/files/Tuxbox-Builder)-VM komplett ab. Deren Wartung wird nicht mehr weitergeführt.
|
- [8. Weiterführende Informationen](#8-weiterführende-informationen)
|
||||||
|
|
||||||
Hier angegebene Pfade basieren auf Vorgaben, die vom Init-Script erzeugt werden. Einige Einträge werden als ```<Platzhalter>``` dargestellt, die lokal angepasst werden müssen. [Siehe Schema](#14-init-skript-ausführen)
|
## 1. Vorbereitung
|
||||||
|
|
||||||
### 1.1 Erforderliche Host-Pakete installieren
|
Empfohlen sei an dieser Stelle, den dafür vorgesehenen Docker-Container zu verwenden, da damit schon wesentliche Schritte erledigt sind, um mit möglichst wenig Anpassungen an seinem System, loslegen zu können. [siehe docker-buildenv](https://github.com/tuxbox-neutrino/docker-buildenv). In diesem Fall kann man gleich [mit der Initialisierung](#14-init-skript-ausführen) beginnen.
|
||||||
|
|
||||||
**Hinweis:** Bei Verwendung anderer Distributionen siehe: [Yocto Project Quick Build](https://docs.yoctoproject.org/3.2.4/ref-manual/ref-system-requirements.html#supported-linux-distributions)
|
**HINWEIS:** [docker-buildenv](https://github.com/tuxbox-neutrino/docker-buildenv) löst die [Tuxbox-Builder](https://sourceforge.net/projects/n4k/files/Tuxbox-Builder)-VM komplett ab. Deren Wartung wird nicht mehr weitergeführt.
|
||||||
|
|
||||||
Debian 11
|
Hier angegebene Pfade basieren auf Vorgaben, die vom Init-Script erzeugt werden. Einige Einträge werden als ```<Platzhalter>``` dargestellt, die lokal angepasst werden müssen. [Siehe Schema](#14-init-skript-ausführen)
|
||||||
|
|
||||||
```bash
|
### 1.1 Erforderliche Host-Pakete installieren
|
||||||
sudo apt-get install -y gawk wget git-core diffstat unzip texinfo gcc-multilib build-essential \
|
|
||||||
chrpath socat cpio python python3 python3-pip python3-pexpect xz-utils debianutils \
|
**Hinweis:** Bei Verwendung anderer Distributionen siehe: [Yocto Project Quick Build](https://docs.yoctoproject.org/3.2.4/ref-manual/ref-system-requirements.html#supported-linux-distributions)
|
||||||
iputils-ping python3-git python3-jinja2 libegl1-mesa pylint3 xterm subversion locales-all \
|
|
||||||
libxml2-utils ninja-build default-jre clisp libcapstone4 libsdl2-dev doxygen
|
Debian 11
|
||||||
```
|
|
||||||
|
```bash
|
||||||
Debian 12
|
sudo apt-get install -y gawk wget git-core diffstat unzip texinfo gcc-multilib build-essential \
|
||||||
|
chrpath socat cpio python python3 python3-pip python3-pexpect xz-utils debianutils \
|
||||||
```bash
|
iputils-ping python3-git python3-jinja2 libegl1-mesa pylint3 xterm subversion locales-all \
|
||||||
sudo apt-get install -y gawk wget git diffstat unzip texinfo gcc-multilib build-essential \
|
libxml2-utils ninja-build default-jre clisp libcapstone4 libsdl2-dev doxygen
|
||||||
chrpath socat cpio python3 python3-pip python3-pexpect xz-utils debianutils iputils-ping \
|
```
|
||||||
python3-git python3-jinja2 libegl1-mesa pylint3 xterm subversion locales-all libxml2-utils \
|
|
||||||
ninja-build default-jre clisp libcapstone4 libsdl2-dev doxygen
|
Debian 12
|
||||||
```
|
|
||||||
|
```bash
|
||||||
**HINWEIS:** Bei Debian 10 (buster) libcapstone3 verwenden.
|
sudo apt-get install -y gawk wget git diffstat unzip texinfo gcc-multilib build-essential \
|
||||||
|
chrpath socat cpio python3 python3-pip python3-pexpect xz-utils debianutils iputils-ping \
|
||||||
#### 1.1.1 Empfohlene Zusatzpakete zur grafischen Unterstützung und Analyse
|
python3-git python3-jinja2 libegl1-mesa pylint3 xterm subversion locales-all libxml2-utils \
|
||||||
|
ninja-build default-jre clisp libcapstone4 libsdl2-dev doxygen
|
||||||
```bash
|
```
|
||||||
sudo apt-get install -y gitk git-gui meld cppcheck clazy kdevelop
|
|
||||||
```
|
**HINWEIS:** Bei Debian 10 (buster) libcapstone3 verwenden.
|
||||||
|
|
||||||
### 1.2 Git vorbereiten (falls erforderlich)
|
#### 1.1.1 Empfohlene Zusatzpakete zur grafischen Unterstützung und Analyse
|
||||||
|
|
||||||
Das init-Script verwendet Git zum Klonen der Meta-Layer Repositorys. Wenn noch kein konfiguriertes Git vorhanden ist, lege bitte Deine globalen Git-Benutzerdaten an, andernfalls wird während das Script durchläuft, unnötig darauf hingewiesen.
|
```bash
|
||||||
|
sudo apt-get install -y gitk git-gui meld cppcheck clazy kdevelop
|
||||||
```bash
|
```
|
||||||
git config --global user.email "you@example.com"
|
|
||||||
git config --global user.name "Dein Name"
|
### 1.2 Git vorbereiten (falls erforderlich)
|
||||||
```
|
|
||||||
|
Das init-Script verwendet Git zum Klonen der Meta-Layer Repositorys. Wenn noch kein konfiguriertes Git vorhanden ist, lege bitte Deine globalen Git-Benutzerdaten an, andernfalls wird während das Script durchläuft, unnötig darauf hingewiesen.
|
||||||
### 1.3 Init-Skript klonen
|
|
||||||
|
```bash
|
||||||
```bash
|
git config --global user.email "you@example.com"
|
||||||
git clone https://github.com/tuxbox-neutrino/buildenv.git && cd buildenv
|
git config --global user.name "Dein Name"
|
||||||
```
|
```
|
||||||
|
|
||||||
### 1.4 Init-Skript ausführen
|
### 1.3 Init-Skript klonen
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
./init && cd poky-3.2.4
|
git clone https://github.com/tuxbox-neutrino/buildenv.git && cd buildenv
|
||||||
```
|
```
|
||||||
|
|
||||||
### 1.5 Struktur der Buildumgebung
|
### 1.4 Init-Skript ausführen
|
||||||
|
|
||||||
Nach [Schritt 1.4](#14-init-skript-ausführen) sollte etwa diese Struktur angelegt worden sein:
|
```bash
|
||||||
|
./init && cd poky-3.2.4
|
||||||
```
|
```
|
||||||
.buildenv
|
|
||||||
├── dist <-- Freigabeordner für http-Server (falls eingerichtet) http://localhost, http://localhost:8080 , benötigt für IPK-Feeds und Images
|
### 1.5 Struktur der Buildumgebung
|
||||||
│ └── {DISTRO_VERSION} <-- hier liegen die erzeugten Images und Pakete (Symlinks zeigen auf die Deploy-Verzeichnisse innerhalb der Build-Unterverzeichnisse)
|
|
||||||
:
|
Nach [Schritt 1.4](#14-init-skript-ausführen) sollte etwa diese Struktur angelegt worden sein:
|
||||||
├── init.sh <-- init-Script
|
|
||||||
├── local.conf.common.inc <-- globale Benutzerkonfiguration, ist in die benutzerdefinierte Konfiguration inkluiert
|
```
|
||||||
:
|
.buildenv
|
||||||
├── log <-- Ordner für Logs, enthält Logs für jede Ausführung des Init-Scripts
|
├── dist <-- Freigabeordner für http-Server (falls eingerichtet) http://localhost, http://localhost:8080 , benötigt für IPK-Feeds und Images
|
||||||
:
|
│ └── {DISTRO_VERSION} <-- hier liegen die erzeugten Images und Pakete (Symlinks zeigen auf die Deploy-Verzeichnisse innerhalb der Build-Unterverzeichnisse)
|
||||||
└── poky-{DISTRO_VERSION} <-- Nach Schritt 1.4 befindest Du dich hier. Hier befindet sich der Buildsystem-Kern und die Meta-Layer
|
:
|
||||||
│
|
├── init.sh <-- init-Script
|
||||||
:
|
├── local.conf.common.inc <-- globale Benutzerkonfiguration, ist in die benutzerdefinierte Konfiguration inkluiert
|
||||||
└── build <-- Hier liegen die Build-Unterverzeichnisse, nach Schritt 2.2 befindest Du dich in einem dieser Build-Unterverzeichnisse
|
:
|
||||||
├── <machine x> <-- Build-Unterverzeichnis für Maschinentyp x
|
├── log <-- Ordner für Logs, enthält Logs für jede Ausführung des Init-Scripts
|
||||||
│ ├── conf <-- Ordner für Layer und benutzerdefinierte Konfiguration
|
:
|
||||||
│ │ └── bblayers.conf <-- Konfigurationsdatei für eingebundene Meta-Layer
|
└── poky-{DISTRO_VERSION} <-- Nach Schritt 1.4 befindest Du dich hier. Hier befindet sich der Buildsystem-Kern und die Meta-Layer
|
||||||
│ │ └── local.conf <-- benutzerdefinierte Konfiguration für einen Maschinentyp
|
│
|
||||||
│ :
|
:
|
||||||
│ ├── (tmp) <-- Arbeitsverzeichnis, wird beim Bauen automatisch angelegt
|
└── build <-- Hier liegen die Build-Unterverzeichnisse, nach Schritt 2.2 befindest Du dich in einem dieser Build-Unterverzeichnisse
|
||||||
│ └── (workspace) <-- Workspace, wird beim Ausführen von devtool angelegt
|
├── <machine x> <-- Build-Unterverzeichnis für Maschinentyp x
|
||||||
:
|
│ ├── conf <-- Ordner für Layer und benutzerdefinierte Konfiguration
|
||||||
└── <machine y> <-- weiteres Build-Unterverzeichnis für Maschinentyp y
|
│ │ └── bblayers.conf <-- Konfigurationsdatei für eingebundene Meta-Layer
|
||||||
```
|
│ │ └── local.conf <-- benutzerdefinierte Konfiguration für einen Maschinentyp
|
||||||
|
│ :
|
||||||
## 2. Image bauen
|
│ ├── (tmp) <-- Arbeitsverzeichnis, wird beim Bauen automatisch angelegt
|
||||||
|
│ └── (workspace) <-- Workspace, wird beim Ausführen von devtool angelegt
|
||||||
Stelle sicher, dass Du dich wie im [Schema](#15-struktur-der-buildumgebung) gezeigt hier befindest:
|
:
|
||||||
|
└── <machine y> <-- weiteres Build-Unterverzeichnis für Maschinentyp y
|
||||||
```
|
```
|
||||||
poky-{DISTRO_VERSION}
|
|
||||||
```
|
|
||||||
|
## 2. Image bauen
|
||||||
### 2.1 Box wählen
|
|
||||||
|
Stelle sicher, dass Du dich wie im [Schema](#15-struktur-der-buildumgebung) gezeigt hier befindest:
|
||||||
Liste verfügbarer Geräte anzeigen lassen:
|
|
||||||
|
```
|
||||||
```bash
|
poky-{DISTRO_VERSION}
|
||||||
ls build
|
```
|
||||||
```
|
|
||||||
|
### 2.1 Box wählen
|
||||||
### 2.2 Starte Umgebungsskript
|
|
||||||
|
Liste verfügbarer Geräte anzeigen lassen:
|
||||||
Führe das Umgebungsskript für die aus der Liste gewünschte Box einmalig aus! Du gelangst dann automatisch in das passende Build-Unterverzeichnis.
|
|
||||||
|
```bash
|
||||||
```bash
|
ls build
|
||||||
. ./oe-init-build-env build/<machine>
|
```
|
||||||
```
|
|
||||||
|
### 2.2 Starte Umgebungsskript
|
||||||
Solange man sich ab jetzt mit der erzeugten Umgebung innerhalb der geöffneten Shell im gewünschten Build-Unterverzeichnis befindet, muss man dieses Script nicht noch einmal ausführen und kannst [Schritt 2.3 ](#23-image-erstellen) Images oder beliebige Pakete bauen.
|
|
||||||
|
Führe das Umgebungsskript für die aus der Liste gewünschte Box einmalig aus! Du gelangst dann automatisch in das passende Build-Unterverzeichnis.
|
||||||
**Hinweis:** Du kannst auch weitere Shells und damit Buildumgebungen für weitere Boxtypen parallel dazu anlegen und je nach Bedarf auf das entsprechende Terminal wechseln und auch parallel bauen lassen, sofern es dein System hergibt.
|
|
||||||
|
```bash
|
||||||
### 2.3 Image erstellen
|
. ./oe-init-build-env build/<machine>
|
||||||
|
```
|
||||||
```bash
|
|
||||||
bitbake neutrino-image
|
Solange man sich ab jetzt mit der erzeugten Umgebung innerhalb der geöffneten Shell im gewünschten Build-Unterverzeichnis befindet, muss man dieses Script nicht noch einmal ausführen und kannst [Schritt 2.3 ](#23-image-erstellen) Images oder beliebige Pakete bauen.
|
||||||
```
|
|
||||||
|
**Hinweis:** Du kannst auch weitere Shells und damit Buildumgebungen für weitere Boxtypen parallel dazu anlegen und je nach Bedarf auf das entsprechende Terminal wechseln und auch parallel bauen lassen, sofern es dein System hergibt.
|
||||||
Das kann eine Weile dauern. Einige Warnmeldungen können ignoriert werden. Fehlermeldungen, welche die Setscene-Tasks betreffen, sind kein Problem, aber Fehler während der Build- und Package-Tasks brechen den Prozess in den meisten Fällen ab. [Bitte melde in diesem Fall den Fehler oder teile Deine Lösung](https://forum.tuxbox-neutrino.org/forum/viewforum.php?f=77). Hilfe ist sehr willkommen.
|
|
||||||
|
### 2.3 Image erstellen
|
||||||
Wenn alles erledigt ist, sollte eine ähnliche Meldung wie diese erscheinen:
|
|
||||||
|
```bash
|
||||||
```bash
|
bitbake neutrino-image
|
||||||
"NOTE: Tasks Summary: Attempted 4568 tasks of which 4198 didn't need to be rerun and all succeeded."
|
```
|
||||||
```
|
|
||||||
|
Das kann eine Weile dauern. Einige Warnmeldungen können ignoriert werden. Fehlermeldungen, welche die Setscene-Tasks betreffen, sind kein Problem, aber Fehler während der Build- und Package-Tasks brechen den Prozess in den meisten Fällen ab. [Bitte melde in diesem Fall den Fehler oder teile Deine Lösung](https://forum.tuxbox-neutrino.org/forum/viewforum.php?f=77). Hilfe ist sehr willkommen.
|
||||||
<span style="color: green;">Das war's ...</span>
|
|
||||||
|
Wenn alles erledigt ist, sollte eine ähnliche Meldung wie diese erscheinen:
|
||||||
|
|
||||||
Ergebnisse findest Du unter:
|
```bash
|
||||||
|
"NOTE: Tasks Summary: Attempted 4568 tasks of which 4198 didn't need to be rerun and all succeeded."
|
||||||
```bash
|
```
|
||||||
buildenv/poky-{DISTRO_VERSION}/build/<machine>/tmp/deploy
|
|
||||||
```
|
<span style="color: green;">Das war's ...</span>
|
||||||
|
|
||||||
oder im Freigabe-Verzeichnis:
|
Ergebnisse findest Du unter:
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
buildenv/dist/<Image-Version>/<machine>/
|
buildenv/poky-{DISTRO_VERSION}/build/<machine>/tmp/deploy
|
||||||
```
|
```
|
||||||
|
|
||||||
Falls ein Webserver eingerichtet ist, der auf das Freigabe-Verzeichnis zeigt:
|
oder im Freigabe-Verzeichnis:
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
http://localhost/{DISTRO_VERSION} oder mit Portnummer http://localhost:8080/{DISTRO_VERSION}
|
buildenv/dist/<Image-Version>/<machine>/
|
||||||
```
|
```
|
||||||
|
|
||||||
## 3. Aktualisierung
|
Falls ein Webserver eingerichtet ist, der auf das Freigabe-Verzeichnis zeigt:
|
||||||
|
|
||||||
Manuelle Aktualisierungen der Pakete sind nicht erforderlich. Dies wird automatisch bei jedem aufgerufenen Target mit Bitbake durchgeführt. Das gilt auch für mögliche Abhängigkeiten. Wenn man die volle Kontrolle über bestimmte Paket-Quellen haben möchte, kann man sich diese für jedes Paket im dafür vorgesehenen Workspace ablegen, siehe [4.4 Pakete](#44-pakete).
|
```bash
|
||||||
Sollten keine Aktualisierungen notwendig sein, werden die Builds automatisch übersprungen.
|
http://localhost/{DISTRO_VERSION} oder mit Portnummer http://localhost:8080/{DISTRO_VERSION}
|
||||||
|
```
|
||||||
### 3.1 Image aktualisieren
|
|
||||||
|
## 3. Aktualisierung
|
||||||
```bash
|
|
||||||
bitbake neutrino-image
|
Manuelle Aktualisierungen der Pakete sind nicht erforderlich. Dies wird automatisch bei jedem aufgerufenen Target mit Bitbake durchgeführt. Das gilt auch für mögliche Abhängigkeiten. Wenn man die volle Kontrolle über bestimmte Paket-Quellen haben möchte, kann man sich diese für jedes Paket im dafür vorgesehenen Workspace ablegen, siehe [4.4 Pakete](#44-pakete).
|
||||||
```
|
Sollten keine Aktualisierungen notwendig sein, werden die Builds automatisch übersprungen.
|
||||||
|
|
||||||
### 3.2 Paket aktualisieren
|
### 3.1 Image aktualisieren
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
bitbake <package>
|
bitbake neutrino-image
|
||||||
```
|
```
|
||||||
|
|
||||||
### 3.3 Meta-Layer-Repositorys aktualisieren
|
|
||||||
|
### 3.2 Paket aktualisieren
|
||||||
Die Ausführung des Init-Skripts mit dem ```--update``` Parameter aktualisiert die enthaltenen Meta-Layer auf den Stand der Remote-Repositorys.
|
|
||||||
|
```bash
|
||||||
```bash
|
bitbake <package>
|
||||||
./init --update
|
```
|
||||||
```
|
|
||||||
|
### 3.3 Meta-Layer-Repositorys aktualisieren
|
||||||
Falls Du an den Meta-Layern Änderungen vorgenommen hast, sollten angestoßene Update-Routinen des Init-scripts nicht festgeschriebene Änderungen vorübergehend stashen bzw. auf das lokale Repository rebasen. Natürlich kann man seine lokalen Meta-Layer für Meta-Neutrino- und Maschinen-Layer-Repositorys manuell aktualisieren. Konflikte muss man jedoch immer manuell auflösen.
|
|
||||||
|
Die Ausführung des Init-Skripts mit dem ```--update``` Parameter aktualisiert die enthaltenen Meta-Layer auf den Stand der Remote-Repositorys.
|
||||||
**Hinweis:** Konfigurationsdateien bleiben im Wesentlichen unberührt, aber mögliche Variablennamen werden migriert. Neue oder geänderte Einstellungen werden nicht geändert. Bitte überprüfe evtl. die Konfiguration.
|
|
||||||
|
```bash
|
||||||
## 4. Eigene Anpassungen
|
./init --update
|
||||||
|
```
|
||||||
### 4.1 Konfiguration
|
|
||||||
|
Falls Du an den Meta-Layern Änderungen vorgenommen hast, sollten angestoßene Update-Routinen des Init-scripts nicht festgeschriebene Änderungen vorübergehend stashen bzw. auf das lokale Repository rebasen. Natürlich kann man seine lokalen Meta-Layer für Meta-Neutrino- und Maschinen-Layer-Repositorys manuell aktualisieren. Konflikte muss man jedoch immer manuell auflösen.
|
||||||
Es wird empfohlen, zum ersten Mal ohne geänderte Konfigurationsdateien zu bauen, um einen Eindruck davon zu bekommen, wie der Build-Prozess funktioniert und um die Ergebnisse möglichst schnell zu sehen.
|
|
||||||
Die Einstellmöglichkeiten sind sehr umfangreich und für Einsteiger nicht wirklich überschaubar. OpenEmbedded insbesondere das Yocto-Project ist jedoch sehr
|
**Hinweis:** Konfigurationsdateien bleiben im Wesentlichen unberührt, aber mögliche Variablennamen werden migriert. Neue oder geänderte Einstellungen werden nicht geändert. Bitte überprüfe evtl. die Konfiguration.
|
||||||
umfassend dokumentiert und bietet die beste Informationsquelle.
|
|
||||||
|
## 4. Eigene Anpassungen
|
||||||
#### 4.1.1 Konfigurationsdateien
|
|
||||||
|
### 4.1 Konfiguration
|
||||||
> ~/buildenv/poky-3.2.4/build/```<machine>```/conf/local.conf
|
|
||||||
|
Es wird empfohlen, zum ersten Mal ohne geänderte Konfigurationsdateien zu bauen, um einen Eindruck davon zu bekommen, wie der Build-Prozess funktioniert und um die Ergebnisse möglichst schnell zu sehen.
|
||||||
Diese Datei befindet sich im Buildverzeichnis des jeweiligen Maschinentyps und ist die eigentliche benutzerdefinierte Konfigurationsdatei, welche ursprünglich vom Buildsystem dafür vorgesehen ist. Diese local.conf enthält in dieser Umgebung jedoch nur nur wenige Zeilen und inkludiert eine globale Konfiguration. Diese Datei ist **nur** für den von ihr unterstützten Maschinentyp gültig. Hier kann man deshalb ergänzende Einträge vornhemen, die entsprechend nur für den Maschinentyp vorgesehen sind. [Siehe auch Schema](#14-init-skript-ausführen)
|
Die Einstellmöglichkeiten sind sehr umfangreich und für Einsteiger nicht wirklich überschaubar. OpenEmbedded insbesondere das Yocto-Project ist jedoch sehr
|
||||||
|
umfassend dokumentiert und bietet die beste Informationsquelle.
|
||||||
> ~/buildenv/local.conf.common.inc
|
|
||||||
|
#### 4.1.1 Konfigurationsdateien
|
||||||
Diese Datei enthält Einstellungen, die für alle Maschinentypen zutreffen und wird bei erstmaligen ausführen des Init-Scripts aus der Vorlage ```~/buildenv/local.conf.common.inc.sample``` erzeugt.
|
|
||||||
|
> ~/buildenv/poky-3.2.4/build/```<machine>```/conf/local.conf
|
||||||
Die vom Buildsystem vorgesehene ```./build/<machine>/conf/local.conf``` könnte man zwar so wie es ursprügliche vom Buildsystem vorgesehen ist als primäre Konfigurationsdatei für jeden Maschinentyp separat verwenden, aber das würde den Wartungsaufwand unnötig erhöhen. Deshalb ist ```~/buildenv/local.conf.common.inc``` nur in ```./build/<machine>/conf/local.conf``` inkludiert,
|
|
||||||
|
Diese Datei befindet sich im Buildverzeichnis des jeweiligen Maschinentyps und ist die eigentliche benutzerdefinierte Konfigurationsdatei, welche ursprünglich vom Buildsystem dafür vorgesehen ist. Diese local.conf enthält in dieser Umgebung jedoch nur nur wenige Zeilen und inkludiert eine globale Konfiguration. Diese Datei ist **nur** für den von ihr unterstützten Maschinentyp gültig. Hier kann man deshalb ergänzende Einträge vornhemen, die entsprechend nur für den Maschinentyp vorgesehen sind. [Siehe auch Schema](#14-init-skript-ausführen)
|
||||||
**Hinweis zu** ```~/buildenv/local.conf.common.inc.sample```**:** Dies ist nur eine Vorlage und sollte unberührt bleiben, um mögliche Konflikte beim Aktualisieren des Build-Script-Repositorys zu vermeiden und um zu sehen, was sich geändert haben könnte.
|
|
||||||
|
> ~/buildenv/local.conf.common.inc
|
||||||
Nach einer Aktualisierung des Build-Script-Repositorys könnten neue oder geänderte Optionen hinzugefügt oder entfernt worden sein, die nicht in die inkludierte Konfigurationsdatei übernommen werden. Diesen Fall sollte man in der eigenen Konfiguration berücksichtigen und falls erforderlich prüfen und anpassen.
|
|
||||||
|
Diese Datei enthält Einstellungen, die für alle Maschinentypen zutreffen und wird bei erstmaligen ausführen des Init-Scripts aus der Vorlage ```~/buildenv/local.conf.common.inc.sample``` erzeugt.
|
||||||
#### 4.1.2 bblayers.conf
|
|
||||||
|
Die vom Buildsystem vorgesehene ```./build/<machine>/conf/local.conf``` könnte man zwar so wie es ursprügliche vom Buildsystem vorgesehen ist als primäre Konfigurationsdatei für jeden Maschinentyp separat verwenden, aber das würde den Wartungsaufwand unnötig erhöhen. Deshalb ist ```~/buildenv/local.conf.common.inc``` nur in ```./build/<machine>/conf/local.conf``` inkludiert,
|
||||||
> ~/buildenv/poky-3.2.4/build/```<machine>```/conf/bblayers.conf
|
|
||||||
|
**Hinweis zu** ```~/buildenv/local.conf.common.inc.sample```**:** Dies ist nur eine Vorlage und sollte unberührt bleiben, um mögliche Konflikte beim Aktualisieren des Build-Script-Repositorys zu vermeiden und um zu sehen, was sich geändert haben könnte.
|
||||||
Diese Datei wird normalerweise beim erstmaligen ausführen des Init-Skripts angepasst und braucht in der Regel nur angepasst zu werden, wenn man Layer hinzufügen, entfernen oder ersetzen möchte.
|
|
||||||
|
Nach einer Aktualisierung des Build-Script-Repositorys könnten neue oder geänderte Optionen hinzugefügt oder entfernt worden sein, die nicht in die inkludierte Konfigurationsdatei übernommen werden. Diesen Fall sollte man in der eigenen Konfiguration berücksichtigen und falls erforderlich prüfen und anpassen.
|
||||||
#### 4.1.3 Konfiguration zurücksetzen
|
|
||||||
Wenn Du deine Maschinen-Konfigurationen zurücksetzen möchtest, benenne bitte das conf-Verzeichnis um (Löschen wird nicht empfohlen) und führe das Init-Skript erneut aus.
|
#### 4.1.2 bblayers.conf
|
||||||
|
|
||||||
|
> ~/buildenv/poky-3.2.4/build/```<machine>```/conf/bblayers.conf
|
||||||
```bash
|
|
||||||
~/mv ~/buildenv/poky-3.2.4/build/<machine>/conf ~/buildenv/poky-3.2.4/build/<machine>/conf.01
|
Diese Datei wird normalerweise beim erstmaligen ausführen des Init-Skripts angepasst und braucht in der Regel nur angepasst zu werden, wenn man Layer hinzufügen, entfernen oder ersetzen möchte.
|
||||||
~/cd ~/buildenv
|
|
||||||
~/./init
|
#### 4.1.3 Konfiguration zurücksetzen
|
||||||
```
|
|
||||||
|
Wenn Du deine Maschinen-Konfigurationen zurücksetzen möchtest, benenne bitte das conf-Verzeichnis um (Löschen wird nicht empfohlen) und führe das Init-Skript erneut aus.
|
||||||
### 4.3 Recipes
|
|
||||||
|
```bash
|
||||||
**Sofern man nicht direkt an der Entwicklung der Poky-Ebenen beiteiligt ist, ändere nichts an den offiziellen Poky-Ebenen (Meta-Layer)! Dies wird vom Yocto-Projekt ausdrücklich nicht empfohlen, da man Gefahr läuft, bei Aktualisierungen, seine gesamte Arbeit zu verlieren und Inkompatibilitäten oder Konflikte schafft, die nur schwer zu warten sein können. Die übliche Vorgehensweise, um vorhandene offizielle Rezepte zu vervollständigen, zu erweitern oder zu überschreiben, ist die [Verwendung von .bbappend](https://docs.yoctoproject.org/3.2.4/dev-manual/dev-manual-common-tasks.html#using-bbappend-files-in-your-layer)-Dateien.**
|
~/mv ~/buildenv/poky-3.2.4/build/<machine>/conf ~/buildenv/poky-3.2.4/build/<machine>/conf.01
|
||||||
|
~/cd ~/buildenv
|
||||||
Alternativ, allerdings auch nicht wirklich empfehlenswert, könnte man Kopien von offiziellen Reciepes in seine eigenen Meta-Layer übernehmen und anpassen, da diese dann in der Regel vom Buildsystem bevorzugt werden. In solch einem Fall ist man allerdings selbst dafür verantwortlich, diese Recipes aktuell zu halten, was den Wartungsaufwand allerdings unnötig erhöhen kann.
|
~/./init
|
||||||
|
```
|
||||||
Für Rezepte aus den eigenen Meta-Layern wie z.B. meta-neutrino oder den Maschinen-Layern, gilt das prinzipiell genauso. Wer aber [aktiv an den Recipes mitarbeiten](https://docs.yoctoproject.org/current/ref-manual/devtool-reference.html#modifying-an-existing-recipe) möchte, kann dies gerne tun.
|
|
||||||
|
### 4.3 Recipes
|
||||||
### 4.4 Pakete
|
|
||||||
|
|
||||||
Wenn man die volle Kontrolle über einen Paket-Quellcode haben möchte, um z.B. etwas zu fixen oder aktiv zu entwickeln, sollte der Quellcode an dem man arbeiten möchte in den Workspace verschoben werden. Siehe: [Beispiel für Neutrino](#441-quellcode-im-workspace-bearbeiten-beispiel)
|
**Sofern man nicht direkt an der Entwicklung der Poky-Ebenen beiteiligt ist, ändere nichts an den offiziellen Poky-Ebenen (Meta-Layer)! Dies wird vom Yocto-Projekt ausdrücklich nicht empfohlen, da man Gefahr läuft, bei Aktualisierungen, seine gesamte Arbeit zu verlieren und Inkompatibilitäten oder Konflikte schafft, die nur schwer zu warten sein können. Die übliche Vorgehensweise, um vorhandene offizielle Rezepte zu vervollständigen, zu erweitern oder zu überschreiben, ist die [Verwendung von .bbappend](https://docs.yoctoproject.org/3.2.4/dev-manual/dev-manual-common-tasks.html#using-bbappend-files-in-your-layer)-Dateien.**
|
||||||
|
|
||||||
Siehe [devtool](https://docs.yoctoproject.org/current/ref-manual/devtool-reference.html) und insbesondere [devtool modify](https://docs.yoctoproject.org/current/ref-manual/devtool-reference.html#modifying-an-existing-recipe). Im Workspace hat man die Garantie, dass der Quellcode nicht vom Buildsystem angefasst wird. Beachtet man das nicht, kann es z.B. vorkommen, dass geänderter Quellcode immer wieder gelöscht oder modifiziert wird. Eigene Anpassungen können daher verloren gehen oder inkompatibel werden. In der lokalen Standardkonfiguration ist [rm_work](https://docs.yoctoproject.org/ref-manual/classes.html#ref-classes-rm-work) aktiviert, was dafür sorgt, dass nach jedem abgeschlossenem Bau eines Pakets, das jeweilige Arbeitsverzeichnis aufgeräumt wird, so dass ausser einigen Logs nichts übrig bleiben wird.
|
Alternativ, allerdings auch nicht wirklich empfehlenswert, könnte man Kopien von offiziellen Reciepes in seine eigenen Meta-Layer übernehmen und anpassen, da diese dann in der Regel vom Buildsystem bevorzugt werden. In solch einem Fall ist man allerdings selbst dafür verantwortlich, diese Recipes aktuell zu halten, was den Wartungsaufwand allerdings unnötig erhöhen kann.
|
||||||
|
|
||||||
#### 4.4.1 Quellcode im Workspace bearbeiten (Beispiel)
|
Für Rezepte aus den eigenen Meta-Layern wie z.B. meta-neutrino oder den Maschinen-Layern, gilt das prinzipiell genauso. Wer aber [aktiv an den Recipes mitarbeiten](https://docs.yoctoproject.org/current/ref-manual/devtool-reference.html#modifying-an-existing-recipe) möchte, kann dies gerne tun.
|
||||||
|
|
||||||
Hier wird beispielhaft Neutrino verwendet, aber diese Vorgehensweise trifft im Wesentlichen auf alle anderen Pakete zu.
|
### 4.4 Pakete
|
||||||
|
|
||||||
```bash
|
Wenn man die volle Kontrolle über einen Paket-Quellcode haben möchte, um z.B. etwas zu fixen oder aktiv zu entwickeln, sollte der Quellcode an dem man arbeiten möchte in den Workspace verschoben werden. Siehe: [Beispiel für Neutrino](#441-quellcode-im-workspace-bearbeiten-beispiel)
|
||||||
~/buildenv/poky-3.2.4/build/hd61$ devtool modify neutrino
|
|
||||||
NOTE: Starting bitbake server...54cf81d24c147d888c"
|
Siehe [devtool](https://docs.yoctoproject.org/current/ref-manual/devtool-reference.html) und insbesondere [devtool modify](https://docs.yoctoproject.org/current/ref-manual/devtool-reference.html#modifying-an-existing-recipe). Im Workspace hat man die Garantie, dass der Quellcode nicht vom Buildsystem angefasst wird. Beachtet man das nicht, kann es z.B. vorkommen, dass geänderter Quellcode immer wieder gelöscht oder modifiziert wird. Eigene Anpassungen können daher verloren gehen oder inkompatibel werden. In der lokalen Standardkonfiguration ist [rm_work](https://docs.yoctoproject.org/ref-manual/classes.html#ref-classes-rm-work) aktiviert, was dafür sorgt, dass nach jedem abgeschlossenem Bau eines Pakets, das jeweilige Arbeitsverzeichnis aufgeräumt wird, so dass ausser einigen Logs nichts übrig bleiben wird.
|
||||||
...
|
|
||||||
workspace = "3.2.4:13143ea85a1ab7703825c0673128c05845b96cb5"
|
#### 4.4.1 Quellcode im Workspace bearbeiten (Beispiel)
|
||||||
|
|
||||||
Initialising tasks: 100% |###################################################################################################################################################################################################| Time: 0:00:01
|
Hier wird beispielhaft Neutrino verwendet, aber diese Vorgehensweise trifft im Wesentlichen auf alle anderen Pakete zu.
|
||||||
Sstate summary: Wanted 0 Found 0 Missed 0 Current 10 (0% match, 100% complete)
|
|
||||||
NOTE: Executing Tasks
|
```bash
|
||||||
NOTE: Tasks Summary: Attempted 83 tasks of which 80 didn't need to be rerun and all succeeded.
|
~/buildenv/poky-3.2.4/build/hd61$ devtool modify neutrino
|
||||||
INFO: Adding local source files to srctree...
|
NOTE: Starting bitbake server...54cf81d24c147d888c"
|
||||||
INFO: Source tree extracted to /home/<user>/buildenv/poky-3.2.4/build/hd61/workspace/sources/neutrino
|
...
|
||||||
INFO: Recipe neutrino-mp now set up to build from /home/<user>/buildenv/poky-3.2.4/build/hd61/workspace/sources/neutrino
|
workspace = "3.2.4:13143ea85a1ab7703825c0673128c05845b96cb5"
|
||||||
```
|
|
||||||
|
Initialising tasks: 100% |###################################################################################################################################################################################################| Time: 0:00:01
|
||||||
Unter ```/buildenv/poky-3.2.4/build/hd61/workspace/sources/neutrino``` befindet sich jetzt der Quellcode für Neutrino. Dort kann man dann daran arbeiten. Das bedeutet, dass das Buildsystem nicht mehr von sich aus vom Remote Git-Repo die Neutrino-Quellen klont bzw. automatisch aktalisiert, sondern ab jetzt nur noch die lokalen Quellen innerhalb des Workspace nutzt, die man selbst verwalten muss. Dabei handelt es sich um ein von devtool angelegtes Git-Repo, in welches man an das Original-Remote-Repository einbinden kann, sofern dies nicht bereits der Fall ist.
|
Sstate summary: Wanted 0 Found 0 Missed 0 Current 10 (0% match, 100% complete)
|
||||||
|
NOTE: Executing Tasks
|
||||||
Führt man jetzt das aus...
|
NOTE: Tasks Summary: Attempted 83 tasks of which 80 didn't need to be rerun and all succeeded.
|
||||||
|
INFO: Adding local source files to srctree...
|
||||||
```bash
|
INFO: Source tree extracted to /home/<user>/buildenv/poky-3.2.4/build/hd61/workspace/sources/neutrino
|
||||||
bitbake neutrino
|
INFO: Recipe neutrino-mp now set up to build from /home/<user>/buildenv/poky-3.2.4/build/hd61/workspace/sources/neutrino
|
||||||
```
|
```
|
||||||
|
|
||||||
...wird Neutrino ab sofort nur noch vom lokalen Repo im Workspace gebaut werden:
|
Unter ```/buildenv/poky-3.2.4/build/hd61/workspace/sources/neutrino``` befindet sich jetzt der Quellcode für Neutrino. Dort kann man dann daran arbeiten. Das bedeutet, dass das Buildsystem nicht mehr von sich aus vom Remote Git-Repo die Neutrino-Quellen klont bzw. automatisch aktalisiert, sondern ab jetzt nur noch die lokalen Quellen innerhalb des Workspace nutzt, die man selbst verwalten muss. Dabei handelt es sich um ein von devtool angelegtes Git-Repo, in welches man an das Original-Remote-Repository einbinden kann, sofern dies nicht bereits der Fall ist.
|
||||||
|
|
||||||
|
Führt man jetzt das aus...
|
||||||
```bash
|
|
||||||
NOTE: Started PRServer with DBfile: /home/<user>/buildenv/poky-3.2.4/build/hd61/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 34211, PID: 56838
|
```bash
|
||||||
...
|
bitbake neutrino
|
||||||
workspace = "3.2.4:13143ea85a1ab7703825c0673128c05845b96cb5"
|
```
|
||||||
|
|
||||||
Initialising tasks: 100% |###################################################################################################################################################################################################| Time: 0:00:01
|
...wird Neutrino ab sofort nur noch vom lokalen Repo im Workspace gebaut werden:
|
||||||
Sstate summary: Wanted 122 Found 116 Missed 6 Current 818 (95% match, 99% complete)
|
|
||||||
NOTE: Executing Tasks
|
```bash
|
||||||
NOTE: neutrino-mp: compiling from external source tree /home/<user>/buildenv/poky-3.2.4/build/hd61/workspace/sources/neutrino
|
NOTE: Started PRServer with DBfile: /home/<user>/buildenv/poky-3.2.4/build/hd61/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 34211, PID: 56838
|
||||||
NOTE: Tasks Summary: Attempted 2756 tasks of which 2741 didn't need to be rerun and all succeeded.
|
...
|
||||||
```
|
workspace = "3.2.4:13143ea85a1ab7703825c0673128c05845b96cb5"
|
||||||
|
|
||||||
**Hinweis!** Im speziellen Fall von Neutrino, ist es ratsam nicht nur dessen Quellcode, sondern auch die zugehörige ```libstb-hal``` in den Workspace zu übertragen.
|
Initialising tasks: 100% |###################################################################################################################################################################################################| Time: 0:00:01
|
||||||
|
Sstate summary: Wanted 122 Found 116 Missed 6 Current 818 (95% match, 99% complete)
|
||||||
```bash
|
NOTE: Executing Tasks
|
||||||
devtool modify libstb-hal
|
NOTE: neutrino-mp: compiling from external source tree /home/<user>/buildenv/poky-3.2.4/build/hd61/workspace/sources/neutrino
|
||||||
```
|
NOTE: Tasks Summary: Attempted 2756 tasks of which 2741 didn't need to be rerun and all succeeded.
|
||||||
|
```
|
||||||
## 5. Neubau eines einzelnen Pakets erzwingen
|
|
||||||
|
**Hinweis!** Im speziellen Fall von Neutrino, ist es ratsam nicht nur dessen Quellcode, sondern auch die zugehörige ```libstb-hal``` in den Workspace zu übertragen.
|
||||||
In einigen Fällen kann es vorkommen, dass ein Target, warum auch immer, abbricht. Man sollte deshalb aber keinesfalls in Panik verfallen und deswegen den Arbeitsordner und den teueren sstate-cache löschen. Bereinigungen kann man für jedes Target einzeln vornehmen, ohne ein ansonsten funktionierendes System platt zu machen.
|
|
||||||
|
```bash
|
||||||
Insbesondere defekte Archiv-URLs können zum Abbruch führen. Diese Fehler werden aber immer angezeigt und man kann die URL überprüfen. Oft liegt es nur an den Servern und funktionieren nach wenigen Minuten sogar wieder.
|
devtool modify libstb-hal
|
||||||
|
```
|
||||||
Um sicherzustellen, ob das betreffende Recipe auch tatsächlich ein Problem hat, macht es Sinn das betreffende Target komplett zu bereinigen und neu zu bauen. Um dies zu erreichen, müssen alle zugehörigen Paket-, Build- und Cachedaten bereinigt werden.
|
|
||||||
|
## 5. Neubau eines einzelnen Pakets erzwingen
|
||||||
```bash
|
|
||||||
bitbake -c cleansstate <target>
|
In einigen Fällen kann es vorkommen, dass ein Target, warum auch immer, abbricht. Man sollte deshalb aber keinesfalls in Panik verfallen und deswegen den Arbeitsordner und den teueren sstate-cache löschen. Bereinigungen kann man für jedes Target einzeln vornehmen, ohne ein ansonsten funktionierendes System platt zu machen.
|
||||||
|
|
||||||
```
|
Insbesondere defekte Archiv-URLs können zum Abbruch führen. Diese Fehler werden aber immer angezeigt und man kann die URL überprüfen. Oft liegt es nur an den Servern und funktionieren nach wenigen Minuten sogar wieder.
|
||||||
anschließend neu bauen:
|
|
||||||
|
Um sicherzustellen, ob das betreffende Recipe auch tatsächlich ein Problem hat, macht es Sinn das betreffende Target komplett zu bereinigen und neu zu bauen. Um dies zu erreichen, müssen alle zugehörigen Paket-, Build- und Cachedaten bereinigt werden.
|
||||||
```bash
|
|
||||||
bitbake <target>
|
```bash
|
||||||
```
|
bitbake -c cleansstate <target>
|
||||||
|
|
||||||
## 6. Vollständigen Imagebau erzwingen
|
```
|
||||||
|
anschließend neu bauen:
|
||||||
Das Init-Skript stellt dafür die Option `--reset` zur Verfügung.
|
|
||||||
|
```bash
|
||||||
```bash
|
bitbake <target>
|
||||||
./init --reset
|
```
|
||||||
# Anweisungen befolgen
|
|
||||||
```
|
|
||||||
|
## 6. Vollständigen Imagebau erzwingen
|
||||||
Manuell erreichst Du das ebenfalls, indem man das tmp-Verzeichnis im jeweiligem Build-Unterverzeichnis manuell umbenennt. Löschen kann man es nachträglich, wenn man Speicherplatz freigeben will oder sich sicher ist, dass man das Verzeichnis nicht mehr braucht:
|
|
||||||
|
Das Init-Skript stellt dafür die Option `--reset` zur Verfügung.
|
||||||
```bash
|
|
||||||
mv tmp tmp.01
|
```bash
|
||||||
```
|
./init --reset
|
||||||
|
# Anweisungen befolgen
|
||||||
Anschließend das Image neu bauen lassen:
|
|
||||||
|
```
|
||||||
```bash
|
|
||||||
bitbake neutrino-image
|
Manuell erreichst Du das ebenfalls, indem man das tmp-Verzeichnis im jeweiligem Build-Unterverzeichnis manuell umbenennt. Löschen kann man es nachträglich, wenn man Speicherplatz freigeben will oder sich sicher ist, dass man das Verzeichnis nicht mehr braucht:
|
||||||
```
|
|
||||||
|
```bash
|
||||||
Wenn man den Cache **nicht** gelöscht hat, sollte das Image in relativ kurzer Zeit fertig gebaut sein. Gerade deshalb wird empfohlen, den Cache beizubehalten. Das Verzeichnis wo sich der Cache befindet, wird über die Variable ```${SSTATE_DIR}``` festgelegt und kann in der Konfiguration angepasst werden.
|
mv tmp tmp.01
|
||||||
|
```
|
||||||
Dieses Verzeichnis ist ziemlich wertvoll und nur in seltenen Fällen ist es notwendig, dieses Verzeichnis zu löschen. Bitte beachte, dass der Buildvorgang nach dem Löschen des Cache sehr viel mehr Zeit in Anspruch nimmt.
|
|
||||||
|
Anschließend das Image neu bauen lassen:
|
||||||
|
|
||||||
## 7. Lizenz
|
```bash
|
||||||
|
bitbake neutrino-image
|
||||||
MIT License
|
```
|
||||||
|
|
||||||
## 8. Weiterführende Informationen
|
Wenn man den Cache **nicht** gelöscht hat, sollte das Image in relativ kurzer Zeit fertig gebaut sein. Gerade deshalb wird empfohlen, den Cache beizubehalten. Das Verzeichnis wo sich der Cache befindet, wird über die Variable ```${SSTATE_DIR}``` festgelegt und kann in der Konfiguration angepasst werden.
|
||||||
Weitere Informationen zum Yocto Buildsystem:
|
|
||||||
|
Dieses Verzeichnis ist ziemlich wertvoll und nur in seltenen Fällen ist es notwendig, dieses Verzeichnis zu löschen. Bitte beachte, dass der Buildvorgang nach dem Löschen des Cache sehr viel mehr Zeit in Anspruch nimmt.
|
||||||
* https://docs.yoctoproject.org
|
|
||||||
|
## 7. Lizenz
|
||||||
|
|
||||||
|
MIT License
|
||||||
|
|
||||||
|
## 8. Weiterführende Informationen
|
||||||
|
|
||||||
|
Weitere Informationen zum Yocto Buildsystem:
|
||||||
|
|
||||||
|
* https://docs.yoctoproject.org
|
||||||
343
README_en.md
Normal file
343
README_en.md
Normal file
@@ -0,0 +1,343 @@
|
|||||||
|
<!-- LANGUAGE_LINKS_START -->
|
||||||
|
[🇩🇪 German](README_de.md) | <span style="color: grey;">🇬🇧 English</span> | [🇪🇸 Spanish](README_es.md) | [🇫🇷 French](README_fr.md) | [🇮🇹 Italian](README_it.md)
|
||||||
|
<!-- LANGUAGE_LINKS_END -->
|
||||||
|
|
||||||
|
This script serves as a tool to simplify the creation of a development environment and the build process for images running on different hardware platforms using Neutrino as the user interface. It automates some of the steps required to set up a consistent and functional development and build environment by pre-setting up the necessary dependencies and basic configurations, meta layers, and enabling custom settings. The script aims to provide a foundation upon which to build, experiment, and create, update, and maintain your own customized versions of Tuxbox-Neutrino images.
|
||||||
|
|
||||||
|
[](https://github.com/dbt1/tuxbox-explorer)
|
||||||
|
|
||||||
|
- [1. Preparation](#1-preparation)
|
||||||
|
- [1.1 Install required host packages](#11-install-required-host-packages)
|
||||||
|
- [1.1.1 Recommended additional packages for graphical support and analysis](#111-recommended-additional-packages-for-graphical-support-and-analysis)
|
||||||
|
- [1.2 Prepare Git (if necessary)](#12-prepare-git-if-necessary)
|
||||||
|
- [1.3 Clone init script](#13-clone-init-script)
|
||||||
|
- [1.4 Run init script](#14-run-init-script)
|
||||||
|
- [1.5 Structure of the build environment](#15-structure-of-the-build-environment)
|
||||||
|
- [2. Build image](#2-build-an-image)
|
||||||
|
- [2.1 Select Box](#21-select-box)
|
||||||
|
- [2.2 Start environment script](#22-start-environment-script)
|
||||||
|
- [2.3 Create Image](#23-create-image)
|
||||||
|
- [3. Update](#3-update)
|
||||||
|
- [3.1 Update Image](#31-update-image)
|
||||||
|
- [3.2 Update package](#32-update-package)
|
||||||
|
- [3.3 Update meta layer repositories](#33-update-meta-layer-repositories)
|
||||||
|
- [4. Custom adjustments](#4-customizations)
|
||||||
|
- [4.1 Configuration](#41-configuration)
|
||||||
|
- [4.1.1 Configuration files](#411-configuration-files)
|
||||||
|
- [4.1.2 bblayers.conf](#412-bblayersconf)
|
||||||
|
- [4.1.3 Reset configuration](#413-reset-configuration)
|
||||||
|
- [4.3 Recipes](#43-recipes)
|
||||||
|
- [4.4 Packages](#44-packages)
|
||||||
|
- [4.4.1 Edit source code in the workspace (example)](#441-edit-source-code-in-the-workspace-example)
|
||||||
|
- [5. Force rebuild a single package](#5-force-rebuild-a-single-package)
|
||||||
|
- [6. Force complete image construction](#6-force-complete-image-construction)
|
||||||
|
- [7. License](#7-license)
|
||||||
|
- [8. Further information](#8-further-information)
|
||||||
|
## 1. Preparation
|
||||||
|
|
||||||
|
It is recommended at this point to use the Docker container provided for this purpose, as this already completes the essential steps so that you can get started with as few adjustments to your system as possible. [see docker-buildenv](https://github.com/tuxbox-neutrino/docker-buildenv). In this case you can start immediately [with the initialization](#14-run-init-script).
|
||||||
|
|
||||||
|
**NOTE:** [docker-buildenv](https://github.com/tuxbox-neutrino/docker-buildenv) completely replaces the [Tuxbox-Builder](https://sourceforge.net/projects/n4k/files/Tuxbox-Builder) VM. Their maintenance will no longer be continued.
|
||||||
|
|
||||||
|
Paths specified here are based on specifications generated by the init script. Some entries are represented as ```<Platzhalter>```, which need to be adjusted locally. [See diagram](#14-run-init-script)
|
||||||
|
### 1.1 Install required host packages
|
||||||
|
|
||||||
|
**Note:** If using other distributions see: [Yocto Project Quick Build](https://docs.yoctoproject.org/3.2.4/ref-manual/ref-system-requirements.html#supported-linux-distributions)
|
||||||
|
|
||||||
|
Debian 11
|
||||||
|
|
||||||
|
```bash
|
||||||
|
sudo apt-get install -y gawk wget git-core diffstat unzip texinfo gcc-multilib build-essential \
|
||||||
|
chrpath socat cpio python python3 python3-pip python3-pexpect xz-utils debianutils \
|
||||||
|
iputils-ping python3-git python3-jinja2 libegl1-mesa pylint3 xterm subversion locales-all \
|
||||||
|
libxml2-utils ninja-build default-jre clisp libcapstone4 libsdl2-dev doxygen
|
||||||
|
```
|
||||||
|
|
||||||
|
Debian 12
|
||||||
|
|
||||||
|
```bash
|
||||||
|
sudo apt-get install -y gawk wget git diffstat unzip texinfo gcc-multilib build-essential \
|
||||||
|
chrpath socat cpio python3 python3-pip python3-pexpect xz-utils debianutils iputils-ping \
|
||||||
|
python3-git python3-jinja2 libegl1-mesa pylint3 xterm subversion locales-all libxml2-utils \
|
||||||
|
ninja-build default-jre clisp libcapstone4 libsdl2-dev doxygen
|
||||||
|
```
|
||||||
|
|
||||||
|
**NOTE:** On Debian 10 (buster) use libcapstone3.
|
||||||
|
#### 1.1.1 Recommended additional packages for graphical support and analysis
|
||||||
|
|
||||||
|
```bash
|
||||||
|
sudo apt-get install -y gitk git-gui meld cppcheck clazy kdevelop
|
||||||
|
```
|
||||||
|
### 1.2 Prepare Git (if necessary)
|
||||||
|
|
||||||
|
The init script uses Git to clone the meta-layer repositories. If there is no Git configured yet, please create your global Git user data, otherwise this will be pointed out unnecessarily while the script is running.
|
||||||
|
|
||||||
|
```bash
|
||||||
|
git config --global user.email "you@example.com"
|
||||||
|
git config --global user.name "Dein Name"
|
||||||
|
```
|
||||||
|
### 1.3 Clone init script
|
||||||
|
|
||||||
|
```bash
|
||||||
|
git clone https://github.com/tuxbox-neutrino/buildenv.git && cd buildenv
|
||||||
|
```
|
||||||
|
### 1.4 Run init script
|
||||||
|
|
||||||
|
```bash
|
||||||
|
./init && cd poky-3.2.4
|
||||||
|
```
|
||||||
|
### 1.5 Structure of the build environment
|
||||||
|
|
||||||
|
After [Step 1.4](#14-run-init-script) this structure should have been created:
|
||||||
|
|
||||||
|
```
|
||||||
|
.buildenv
|
||||||
|
├── dist <-- Freigabeordner für http-Server (falls eingerichtet) http://localhost, http://localhost:8080 , benötigt für IPK-Feeds und Images
|
||||||
|
│ └── {DISTRO_VERSION} <-- hier liegen die erzeugten Images und Pakete (Symlinks zeigen auf die Deploy-Verzeichnisse innerhalb der Build-Unterverzeichnisse)
|
||||||
|
:
|
||||||
|
├── init.sh <-- init-Script
|
||||||
|
├── local.conf.common.inc <-- globale Benutzerkonfiguration, ist in die benutzerdefinierte Konfiguration inkluiert
|
||||||
|
:
|
||||||
|
├── log <-- Ordner für Logs, enthält Logs für jede Ausführung des Init-Scripts
|
||||||
|
:
|
||||||
|
└── poky-{DISTRO_VERSION} <-- Nach Schritt 1.4 befindest Du dich hier. Hier befindet sich der Buildsystem-Kern und die Meta-Layer
|
||||||
|
│
|
||||||
|
:
|
||||||
|
└── build <-- Hier liegen die Build-Unterverzeichnisse, nach Schritt 2.2 befindest Du dich in einem dieser Build-Unterverzeichnisse
|
||||||
|
├── <machine x> <-- Build-Unterverzeichnis für Maschinentyp x
|
||||||
|
│ ├── conf <-- Ordner für Layer und benutzerdefinierte Konfiguration
|
||||||
|
│ │ └── bblayers.conf <-- Konfigurationsdatei für eingebundene Meta-Layer
|
||||||
|
│ │ └── local.conf <-- benutzerdefinierte Konfiguration für einen Maschinentyp
|
||||||
|
│ :
|
||||||
|
│ ├── (tmp) <-- Arbeitsverzeichnis, wird beim Bauen automatisch angelegt
|
||||||
|
│ └── (workspace) <-- Workspace, wird beim Ausführen von devtool angelegt
|
||||||
|
:
|
||||||
|
└── <machine y> <-- weiteres Build-Unterverzeichnis für Maschinentyp y
|
||||||
|
```
|
||||||
|
## 2. Build an image
|
||||||
|
|
||||||
|
Make sure you are here as shown in [schema](#15-structure-of-the-build-environment):
|
||||||
|
|
||||||
|
```
|
||||||
|
poky-{DISTRO_VERSION}
|
||||||
|
```
|
||||||
|
### 2.1 Select box
|
||||||
|
|
||||||
|
View a list of available devices:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
ls build
|
||||||
|
```
|
||||||
|
### 2.2 Start environment script
|
||||||
|
|
||||||
|
Run the environment script once for the box you want from the list! You will then automatically be taken to the appropriate build subdirectory.
|
||||||
|
|
||||||
|
```bash
|
||||||
|
. ./oe-init-build-env build/<machine>
|
||||||
|
```
|
||||||
|
|
||||||
|
As long as you are now in the desired build subdirectory with the created environment within the open shell, you do not have to run this script again and can build [Step 2.3 ](#23-create-image) images or any packages.
|
||||||
|
|
||||||
|
**Note:** You can also create additional shells and thus build environments for other box types in parallel and, if necessary, switch to the appropriate terminal and have them built in parallel, if your system allows it.
|
||||||
|
### 2.3 Create image
|
||||||
|
|
||||||
|
```bash
|
||||||
|
bitbake neutrino-image
|
||||||
|
```
|
||||||
|
|
||||||
|
This may take a while. Some warning messages can be ignored. Error messages affecting the setscene tasks are not a problem, but errors during the build and package tasks terminate the process in most cases. [In this case, please report the error or share your solution](https://forum.tuxbox-neutrino.org/forum/viewforum.php?f=77). Help is very welcome.
|
||||||
|
|
||||||
|
When everything is done, you should see a message similar to this:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
"NOTE: Tasks Summary: Attempted 4568 tasks of which 4198 didn't need to be rerun and all succeeded."
|
||||||
|
```
|
||||||
|
|
||||||
|
<span style="color: green;">That's it...</span>
|
||||||
|
|
||||||
|
You can find results at:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
buildenv/poky-{DISTRO_VERSION}/build/<machine>/tmp/deploy
|
||||||
|
```
|
||||||
|
|
||||||
|
or in the release directory:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
buildenv/dist/<Image-Version>/<machine>/
|
||||||
|
```
|
||||||
|
|
||||||
|
If a web server is set up that points to the share directory:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
http://localhost/{DISTRO_VERSION} oder mit Portnummer http://localhost:8080/{DISTRO_VERSION}
|
||||||
|
```
|
||||||
|
## 3. Update
|
||||||
|
|
||||||
|
Manual updates of the packages are not required. This is done automatically for every target called with Bitbake. This also applies to possible dependencies. If you want to have full control over certain package sources, you can store them in the designated workspace for each package, see [4.4 Packages](#44-packages).
|
||||||
|
If no updates are necessary, the builds are automatically skipped.
|
||||||
|
### 3.1 Update image
|
||||||
|
|
||||||
|
```bash
|
||||||
|
bitbake neutrino-image
|
||||||
|
```
|
||||||
|
### 3.2 Update package
|
||||||
|
|
||||||
|
```bash
|
||||||
|
bitbake <package>
|
||||||
|
```
|
||||||
|
### 3.3 Update meta layer repositories
|
||||||
|
|
||||||
|
Executing the init script with the ```--update``` parameter updates the included meta layers to the status of the remote repositories.
|
||||||
|
|
||||||
|
```bash
|
||||||
|
./init --update
|
||||||
|
```
|
||||||
|
|
||||||
|
If you have made changes to the meta layers, the init script update routines should temporarily stash uncommitted changes or rebase them on the local repository. Of course, you can manually update your local meta layers for meta neutrino and machine layer repositories. However, conflicts always have to be resolved manually.
|
||||||
|
|
||||||
|
**Note:** Configuration files remain essentially untouched, but possible variable names are migrated. New or changed settings will not be changed. Please check the configuration if necessary.
|
||||||
|
## 4. Customizations
|
||||||
|
|
||||||
|
### 4.1 Configuration
|
||||||
|
|
||||||
|
It is recommended to build for the first time without modified configuration files to get an idea of how the build process works and to see the results as quickly as possible.
|
||||||
|
The setting options are very extensive and not really manageable for beginners. However, the Yocto Project in particular is very OpenEmbedded
|
||||||
|
comprehensively documented and provides the best source of information.
|
||||||
|
#### 4.1.1 Configuration files
|
||||||
|
|
||||||
|
> ~/buildenv/poky-3.2.4/build/```<machine>```/conf/local.conf
|
||||||
|
|
||||||
|
This file is located in the build directory of the respective machine type and is the actual custom configuration file originally intended for this by the build system. However, in this environment, this local.conf only contains a few lines and includes a global configuration. This file is valid **only** for the machine type it supports. Here you can therefore make additional entries that are only intended for the machine type. [See also diagram](#14-run-init-script)
|
||||||
|
|
||||||
|
> ~/buildenv/local.conf.common.inc
|
||||||
|
|
||||||
|
This file contains settings that apply to all machine types and is created from the template ```~/buildenv/local.conf.common.inc.sample``` when the init script is executed for the first time.
|
||||||
|
|
||||||
|
The ```./build/<machine>/conf/local.conf``` provided by the build system could be used as the primary configuration file for each machine type separately, as originally intended by the build system, but that would unnecessarily increase the maintenance effort. That's why ```~/buildenv/local.conf.common.inc``` is only included in ```./build/<machine>/conf/local.conf```,
|
||||||
|
|
||||||
|
**Note on** ```~/buildenv/local.conf.common.inc.sample```**:** This is just a template and should be left untouched to avoid possible conflicts when updating the build script repository and to see what may have changed.
|
||||||
|
|
||||||
|
After an update to the build script repository, new or changed options may have been added or removed that are not reflected in the included configuration file. This case should be taken into account in your own configuration and checked and adjusted if necessary.
|
||||||
|
#### 4.1.2 bblayers.conf
|
||||||
|
|
||||||
|
> ~/buildenv/poky-3.2.4/build/```<machine>```/conf/bblayers.conf
|
||||||
|
|
||||||
|
This file is usually customized when the init script is run for the first time and usually only needs to be customized if you want to add, remove or replace layers.
|
||||||
|
#### 4.1.3 Reset configuration
|
||||||
|
|
||||||
|
If you want to reset your machine configurations, please rename the conf directory (deletion is not recommended) and run the init script again.
|
||||||
|
|
||||||
|
```bash
|
||||||
|
~/mv ~/buildenv/poky-3.2.4/build/<machine>/conf ~/buildenv/poky-3.2.4/build/<machine>/conf.01
|
||||||
|
~/cd ~/buildenv
|
||||||
|
~/./init
|
||||||
|
```
|
||||||
|
### 4.3 Recipes
|
||||||
|
|
||||||
|
**Unless you are directly involved in the development of the Poky levels, do not change anything in the official Poky levels (meta layers)! This is strongly not recommended by the Yocto project, as you risk losing all your work when updating and creating incompatibilities or conflicts that can be difficult to maintain. The usual procedure to complete, extend or overwrite existing official recipes is to [use .bbappend](https://docs.yoctoproject.org/3.2.4/dev-manual/dev-manual-common-tasks.html#using-bbappend-files-in-your-layer) files.**
|
||||||
|
|
||||||
|
Alternatively, although not really recommended, you could copy copies of official recipes into your own meta layers and adapt them, as these are then usually preferred by the build system. In such a case, however, you are responsible for keeping these recipes up to date, which can unnecessarily increase the maintenance effort.
|
||||||
|
|
||||||
|
In principle, this also applies to recipes from your own meta layers such as meta-neutrino or the machine layers. But if you would like to [actively collaborate on the recipes](https://docs.yoctoproject.org/current/ref-manual/devtool-reference.html#modifying-an-existing-recipe), you are welcome to do so.
|
||||||
|
### 4.4 Packages
|
||||||
|
|
||||||
|
If you want to have full control over a package source code, for example to fix something or actively develop something, the source code you want to work on should be moved to the workspace. See: [Example of Neutrino](#441-edit-source-code-in-the-workspace-example)
|
||||||
|
|
||||||
|
See [devtool](https://docs.yoctoproject.org/current/ref-manual/devtool-reference.html) and especially [devtool modify](https://docs.yoctoproject.org/current/ref-manual/devtool-reference.html#modifying-an-existing-recipe). In the workspace you have the guarantee that the source code will not be touched by the build system. If you don't take this into account, it can happen, for example, that changed source code is repeatedly deleted or modified. Your own customizations can therefore be lost or become incompatible. In the local default configuration, [rm_work](https://docs.yoctoproject.org/ref-manual/classes.html#ref-classes-rm-work) is activated, which ensures that after each package has been built, the respective working directory is cleaned up, so that nothing remains except a few logs.
|
||||||
|
#### 4.4.1 Edit source code in the workspace (example)
|
||||||
|
|
||||||
|
Neutrino is used here as an example, but this approach essentially applies to all other packages.
|
||||||
|
|
||||||
|
```bash
|
||||||
|
~/buildenv/poky-3.2.4/build/hd61$ devtool modify neutrino
|
||||||
|
NOTE: Starting bitbake server...54cf81d24c147d888c"
|
||||||
|
...
|
||||||
|
workspace = "3.2.4:13143ea85a1ab7703825c0673128c05845b96cb5"
|
||||||
|
|
||||||
|
Initialising tasks: 100% |###################################################################################################################################################################################################| Time: 0:00:01
|
||||||
|
Sstate summary: Wanted 0 Found 0 Missed 0 Current 10 (0% match, 100% complete)
|
||||||
|
NOTE: Executing Tasks
|
||||||
|
NOTE: Tasks Summary: Attempted 83 tasks of which 80 didn't need to be rerun and all succeeded.
|
||||||
|
INFO: Adding local source files to srctree...
|
||||||
|
INFO: Source tree extracted to /home/<user>/buildenv/poky-3.2.4/build/hd61/workspace/sources/neutrino
|
||||||
|
INFO: Recipe neutrino-mp now set up to build from /home/<user>/buildenv/poky-3.2.4/build/hd61/workspace/sources/neutrino
|
||||||
|
```
|
||||||
|
|
||||||
|
The source code for Neutrino is now located at ```/buildenv/poky-3.2.4/build/hd61/workspace/sources/neutrino```. You can then work on it there. This means that the build system no longer clones or automatically updates the Neutrino sources from the remote Git repo, but from now on only uses the local sources within the workspace, which you have to manage yourself. This is a Git repo created by devtool, into which you can integrate into the original remote repository, if this is not already the case.
|
||||||
|
|
||||||
|
If you do this now...
|
||||||
|
|
||||||
|
```bash
|
||||||
|
bitbake neutrino
|
||||||
|
```
|
||||||
|
|
||||||
|
...from now on Neutrino will only be built from the local repo in the workspace:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
NOTE: Started PRServer with DBfile: /home/<user>/buildenv/poky-3.2.4/build/hd61/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 34211, PID: 56838
|
||||||
|
...
|
||||||
|
workspace = "3.2.4:13143ea85a1ab7703825c0673128c05845b96cb5"
|
||||||
|
|
||||||
|
Initialising tasks: 100% |###################################################################################################################################################################################################| Time: 0:00:01
|
||||||
|
Sstate summary: Wanted 122 Found 116 Missed 6 Current 818 (95% match, 99% complete)
|
||||||
|
NOTE: Executing Tasks
|
||||||
|
NOTE: neutrino-mp: compiling from external source tree /home/<user>/buildenv/poky-3.2.4/build/hd61/workspace/sources/neutrino
|
||||||
|
NOTE: Tasks Summary: Attempted 2756 tasks of which 2741 didn't need to be rerun and all succeeded.
|
||||||
|
```
|
||||||
|
|
||||||
|
**Note!** In the special case of Neutrino, it is advisable to transfer not only its source code, but also the associated ```libstb-hal``` into the workspace.
|
||||||
|
|
||||||
|
```bash
|
||||||
|
devtool modify libstb-hal
|
||||||
|
```
|
||||||
|
## 5. Force rebuild a single package
|
||||||
|
|
||||||
|
In some cases it can happen that a target breaks off for whatever reason. But you shouldn't panic and delete the working folder and the expensive sstate cache. Cleanups can be carried out individually for each target without destroying an otherwise functioning system.
|
||||||
|
|
||||||
|
In particular, broken archive URLs can lead to termination. However, these errors are always displayed and you can check the URL. Often it's just the servers and they even work again after a few minutes.
|
||||||
|
|
||||||
|
To make sure whether the recipe in question actually has a problem, it makes sense to completely clean up the target in question and rebuild it. To achieve this, all associated package, build and cache data must be cleaned.
|
||||||
|
|
||||||
|
```bash
|
||||||
|
bitbake -c cleansstate <target>
|
||||||
|
|
||||||
|
```
|
||||||
|
then rebuild:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
bitbake <target>
|
||||||
|
```
|
||||||
|
## 6. Force complete image construction
|
||||||
|
|
||||||
|
The init script provides the `--reset` option for this.
|
||||||
|
|
||||||
|
```bash
|
||||||
|
./init --reset
|
||||||
|
# Anweisungen befolgen
|
||||||
|
|
||||||
|
```
|
||||||
|
|
||||||
|
You can also achieve this manually by manually renaming the tmp directory in the respective build subdirectory. You can delete it later if you want to free up storage space or are sure that you no longer need the directory:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
mv tmp tmp.01
|
||||||
|
```
|
||||||
|
|
||||||
|
Then have the image rebuilt:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
bitbake neutrino-image
|
||||||
|
```
|
||||||
|
|
||||||
|
If you have **not** cleared the cache, the image should be built in a relatively short time. This is precisely why it is recommended to keep the cache. The directory where the cache is located is determined via the variable ```${SSTATE_DIR}``` and can be adjusted in the configuration.
|
||||||
|
|
||||||
|
This directory is quite valuable and only in rare cases is it necessary to delete this directory. Please note that the build process will take much longer after clearing the cache.
|
||||||
|
## 7. License
|
||||||
|
|
||||||
|
WITH License
|
||||||
|
## 8. Further information
|
||||||
|
|
||||||
|
Further information about the Yocto build system:
|
||||||
|
|
||||||
|
* https://docs.yoctoproject.org
|
||||||
Reference in New Issue
Block a user