这个名字的问题在于它来自罗马神话，而不是像我们的大多数产品一样来自希腊神话。菲尼克斯已经被充电器夺走了……
本自述文件记录了如何从源代码编译和构建 Venus OS。
首先，确保这确实是您想要或需要的。编译需要几个小时，需要大量磁盘空间，并生成映像和 sdk，它们都可以作为二进制文件 swu 和 sdk 下载。
即使您正在开发 Venus 操作系统的某一部分（例如其驱动程序之一或 GUI），仍然没有必要从源代码构建完整的 Venus 操作系统。
请务必先阅读 Venus OS wiki。
所以，如果你坚持认为：这个仓库是构建 Venus 的起点。它包含围绕 bitbake 和 git 的包装函数来获取和编译源代码。
对于完整的构建，您需要访问 Victron Energy 的私人复制品。也可以只构建开源包（但目前不会自动检查）。
Venus 使用 OpenEmbedded 作为构建系统。
构建 Venus 需要 Linux。在 Victron，我们使用 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
最后一个 fetch 命令已将一些内容克隆到./sources/目录中。首先是 bitbake，它是 OpenEmbedded 中类似 make 的构建工具的一部分。除此之外，您还会发现 openembedded-core 和各种其他层，其中包含定义 Venus 的配方和其他元数据。
现在是时候真正开始构建了（这可能需要几个小时）。选择以下示例命令之一：
# 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
上述入门说明将自动选择用于分发的 Venus OS 的配置。还可以使用替代设置，例如构建较新的 OE 版本：
make CONFIG=rocko fetch-all
要查看您的结账正在使用哪个配置，请查看 ./conf 符号链接。它将链接到 ./configs 目录中的配置之一。
每个配置都有几个文件：
repos.conf包含需要签出的存储库。可以使用make update-repos.conf重建它。metas.whitelist包含将添加到 bblayers.conf 的元目录，但前提是它们实际存在。machines包含可以在此配置中构建的机器列表要添加新存储库，请将其放入源中，然后签出所需的分支并设置上游分支。可以通过以下方式使结果永久化： make repos.conf 。
不要忘记将新存储库中要使用的目录添加到metas.whitelist。
repos命令Repos 就像 git submodule foreach -q git 一样，但更短，所以你可以这样做：
./repos 推送原点 ./repos 标签 xyz
它将推送所有、标记所有等。同样，您可以使用以下命令恢复到某个版本：
./repos 签出标记名
# 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
维护版本所基于的基础分支将以b为前缀。
此示例演示如何创建新的维护分支。上下文是 master 已经在开发 v2.30 了。最新的官方版本是 v2.20。因此我们创建了一个名为 b2.20 的分支，其中第一个版本将是 v2.21；稍后，如果需要另一个维护版本，v2.22 就会被推到顶部；等等。
# 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
现在一切都准备好了；并准备开始采摘。
请注意，有两种方法可以向后移植更改。一是从元存储库中获取完整的提交；另一种是从源存储库添加补丁。如果可以，请应用方法一。但是，如果存储库（例如 mk2-dbus 或 gui）有大量提交，而您只需要其中一个；那么你必须只服用补丁。
更改必须非常小、经过充分测试或非常重要
git cherry-pick -x在提交消息中附加一个漂亮的（从[ref]中挑选的）行backported from ，就像这个一样到提交消息中(**backported to v2.22**)或适用的地方(**backported to v2.22 as a patch**)添加到每个补丁和版本被向后移植。要构建，请在镜像/venus 存储库上创建一个管道，并为维护分支运行它。不需要变量。
如果你遇到这样的问题：
如果可以通过以下方式修复： make einstein-bb bitbake -c cleanall packagegroup-machine-base
然后再试一次
