Das Problem an diesem Namen ist, dass er aus der römischen Mythologie stammt und nicht, wie die meisten unserer Produkte, aus dem Griechischen. Phoenix ist jedoch bereits von einem Ladegerät erfasst ...
In dieser Readme-Datei wird beschrieben, wie Sie Venus OS aus dem Quellcode kompilieren und erstellen.
Stellen Sie zunächst sicher, dass das wirklich das ist, was Sie wollen oder brauchen. Das Kompilieren dauert mehrere Stunden, erfordert viel Speicherplatz und führt zu einem Image und einem SDK, die beide bereits als Binärdateien Swu und SDK zum Download verfügbar sind.
Selbst wenn Sie einen Teil von Venus OS entwickeln, zum Beispiel einen seiner Treiber oder die GUI, ist es immer noch nicht notwendig, das vollständige Venus OS aus dem Quellcode zu erstellen.
Lesen Sie unbedingt zuerst das Venus OS-Wiki.
Wenn Sie also darauf bestehen: Dieses Repo ist der Ausgangspunkt für den Bau der Venus. Es enthält Wrapper-Funktionen rund um Bitbake und Git zum Abrufen und Kompilieren von Quellen.
Für einen vollständigen Build benötigen Sie Zugriff auf private Repros von Victron Energy. Es ist auch möglich, nur OpenSource-Pakete zu erstellen (wird jedoch derzeit nicht automatisch überprüft).
Venus verwendet OpenEmbedded als Build-System.
Für den Bau von Venus ist ein Linux erforderlich. Bei Victron verwenden wir hierfür Ubuntu.
# clone this repository
git clone https://github.com/victronenergy/venus.git
cd venus
# install host packages (Debian based)
sudo make prereq
# fetch needed subtrees
# use make fetch-all instead, if you have access to all the private repos.
make fetch
Dieser letzte Abrufbefehl hat mehrere Dinge in das Verzeichnis ./sources/ geklont. Da ist zunächst einmal Bitbake, ein Make-ähnliches Build-Tool, das Teil von OpenEmbedded ist. Darüber hinaus finden Sie Openembedded-Core und verschiedene andere Ebenen mit Rezepten und anderen Metadaten, die Venus definieren.
Jetzt ist es an der Zeit, tatsächlich mit dem Bau zu beginnen (was viele Stunden dauern kann). Wählen Sie einen der folgenden Beispielbefehle aus:
# build all, this will take a while though... it builds for all MACHINES as found
# in conf/machines.
make venus-images
# build for a specific machine
make ccgx-venus-image
make beaglebone-venus-image
# build the swu file only
make ccgx-swu
# build from within the bitbake shell.
# this will have the same end result as make ccgx-swu
make ccgx-bb
bitbake venus-swu
Die obigen „Erste Schritte“-Anweisungen wählen automatisch die Konfiguration aus, die für das verteilte Venus OS verwendet wird. Es können auch alternative Setups verwendet werden, um z. B. für eine neuere OE-Version zu bauen:
make CONFIG=rocko fetch-all
Um zu sehen, welche Konfiguration Ihr Checkout verwendet, sehen Sie sich den symbolischen Link ./conf an. Es wird eine Verknüpfung zu einer der Konfigurationen in den ./configs-Verzeichnissen hergestellt.
Für jede Konfiguration gibt es einige Dateien:
repos.conf enthält die Repositories, die ausgecheckt werden müssen. Es kann mit make update-repos.conf neu erstellt werden.metas.whitelist enthält das Metaverzeichnis, das zur bblayers.conf hinzugefügt wird, jedoch nur, wenn sie tatsächlich vorhanden sind.machines enthält eine Liste von Maschinen, die in dieser Konfiguration erstellt werden können Um ein neues Repository hinzuzufügen, fügen Sie es in Quellen ein, checken Sie dann den gewünschten Zweig aus und legen Sie einen Upstream-Zweig fest. Das Ergebnis kann dauerhaft gemacht werden mit: make repos.conf .
Vergessen Sie nicht, die Verzeichnisse, die Sie aus dem neuen Repository verwenden möchten, zu metas.whitelist hinzuzufügen.
repos -BefehlsRepos ist genau wie git submodule foreach -q git, aber kürzer, sodass Sie Folgendes tun können:
./repos Push-Ursprung ./repos Tag xyz
Es wird alles pushen, alle markieren usw. Ebenso können Sie zu einer bestimmten Revision zurückkehren mit:
./repos Checkout-Tagname
# patches not in upstream yet
./repos cherry -v
# local changes with respect to upstream
./repos diff @{u}
# local changes with respect to the push branch
./repos diff 'origin/`git rev-parse --abbrev-ref HEAD`'
or if you have git 2.5+ ./repos diff @{push}
./repos log @{u}..upstream/`git rev-parse --abbrev-ref @{u} | grep -o "[a-Z0-9]*$"` --oneline
# rebase your local checkout branches on upstream master
./repos fetch origin
./repos rebase 'origin/$checkout_branch'
# checkout the branches as per used config
./repos checkout '$checkout_branch'
# tag & push venus repo as well as all repos.
git tag v2.21
git push origin v2.21
./repos tag v2.21
./repos push origin v2.21
Dem Basiszweig, auf dem die Wartungsversionen basieren, muss ein b vorangestellt werden.
Dieses Beispiel zeigt, wie ein neuer Wartungszweig erstellt wird. Der Kontext ist, dass Master bereits an Version 2.30 arbeitet. Die letzte offizielle Version war v2.20. Also erstellen wir einen Zweig mit dem Namen b2.20, in dem die erste Version v2.21 sein wird; Wenn später eine weitere Wartungsversion erforderlich ist, wird Version 2.22 nach oben verschoben. und so weiter.
# clone & make a branch in the venus repo
git clone [email protected]:victronenergy/venus.git venus-b2.20
cd venus-b2.20
git checkout v2.20
git checkout -b b2.20
# fetch all the meta repos
make fetch-all
# clone, prep and push them
./repos checkout v2.20
./repos checkout -b b2.20
./repos push --set-upstream origin b2.20
# update the used config to the new branch
make update-repos.conf
git commit -a -m "pin dunfell branches to b2.20"
# update the raspbian config to the new branch
[
Now manually update the raspbian config file, and commit that as well.
See some earlier branch for example.
]
git commit -a -m "pin raspbian branches to b2.20"
# Update gitlab-ci.yml
[
Now, modify .gitlab-ci.yml. See a previous maintenance branch for
how that is done.
]
git commit -a -m "Don't touch SSTATE cache & build from b2.20"
# Push the new branch and changes to the venus repo
# Note that this causes a (useless) CI build to start on the builder once
# it syncs. Easily cancelled in the gitlab ui.
git push --set-upstream origin b2.20
Jetzt sind Sie fertig; und bereit, mit dem Rosinenpflücken zu beginnen.
Beachten Sie, dass es zwei Möglichkeiten gibt, eine Änderung zurückzuportieren. Eine besteht darin, ein vollständiges Commit aus den Meta-Repositories zu übernehmen; und die andere besteht darin, Patches aus dem Quell-Repository hinzuzufügen. Wenden Sie, wo möglich, Methode eins an. Aber falls das Repository, zum Beispiel mk2-dbus oder die GUI, viele Commits hatte, von denen Sie nur einen benötigen; Dann musst du nur den Patch nehmen.
Änderungen müssen entweder sehr klein, gut getestet oder sehr wichtig sein
git cherry-pick -x fügt der Commit-Nachricht eine nette (aus [ref] ausgewählte) Zeile hinzubackported from Notiz wie diese hinzu(**backported to v2.22**) oder gegebenenfalls (**backported to v2.22 as a patch**) zu jedem einzelnen Patch und jeder einzelnen Version hinzu wurde zurückportiert.Erstellen Sie zum Erstellen eine Pipeline auf dem Mirrors/Venus-Repository und führen Sie sie für den Wartungszweig aus. Keine Variablen erforderlich.
Wenn Sie auf Probleme wie diese stoßen:
Wenn es behoben werden kann mit: make einstein-bb bitbake -c cleanall packagegroup-machine-base
und versuchen Sie es anschließend erneut
