从源码编译Batocera
2小时前发布22013

📖 本文由 Batocera 官方 Wiki 翻译整理，内容可能随版本更新而变化。

Compile Batocera.Linux

The official and recommended way to compile Batocera.Linux is by using a development container made on purpose with Docker. Although you can do it directly on your Linux machine, if it’s a supported Ubuntu Linux.

Note that it’s also possible to compile Batocera.Linux within an LXC container but it’s not recommended or officially supported.

If you are not familiar with git, you should first take a look at this page explaining the basics for contributing to Batocera Linux with git.

Install prerequisites

Make sure you have a reasonably fast CPU, and at least 8GB of RAM (even 12GB+ if you need to compile MAME). If you have a CPU with 8 cores/16 threads or more (lucky you!), you might need more than 16 GB RAM to compile Batocera.Linux with all threads in parallel. You also need between 80GB and 250GB of free disk space for each platform you intend to compile for in order to download and compile the final Batocera image.

For reference, here are some estimates of the space required for building certain platforms:
* sources download: up to 120GB for Batocera 41 (x86_64)
* x86_64: 165 GB for Batocera 41 (+35GB for x86_wow64)
* bcm2712 (rpi5): 105GB for Batocera 41
* bcm2711 (rpi4): 103GB for Batocera 41
* bcm2837 (rpi3): 80 GB
* bcm2836 (rpi2): 130 GB for Batocera 40
* rk3326: 74GB for Batocera 40
* rk3399: 45GB for Batocera 40
* s905gen2 (radxa zero): 65 GB
* rpizero: 45 GB

If compiling inside of a VM, you may need to set its CPU type to host to avoid “missing CPU instruction” errors like #error PCSX2 requires compiling for at least SSE 4.1.

Install dev tools

If never having compiled on the machine before you may need to install the various miscellaneous dev tools needed like git and make. These can be installed individually, or it may be more convenient to download the entire development group package for your distro (especially if planning on compiling anything else other than Batocera).

  • Ubuntu:
  • To install the basic dev tools: sudo apt-get install build-essential
  • Fedora:
  • To check the packages that will be installed with the group, run: sudo dnf group info "Development Tools" "Development Libraries"
  • To install them: sudo dnf groupinstall "Development Tools" "Development Libraries"
  • Arch:
  • To install the dev tools: sudo pacman -S base-devel

If you wish to be frugal, the only essential packages on the host OS for compiling Batocera in Docker are git and make, the rest are already included in the Docker image itself.

Docker

If you already have a working Docker installation on your Linux system, skip to the compile_batocera.Linux#preparations section.

Each OS and Linux distribution has a particular way to install Docker.

//Please note that most developers use Docket on Ubuntu Linux to compile Batocera.Linux. In January 2022, Docker on Windows was not stable enough to compile Batocera.//

In March 2020, with the Docker container running as non-root (regular user), you can compile Batocera on MacOS Mojave 10.14 (Darwin 18.0.0).

  • Linux Ubuntu/Debian:
  • Installing Docker from the Distribution packages is not recommended. Refer to the official documentation instead: https://docs.docker.com/engine/install/ubuntu/
  • To be able to run docker without root privileges don’t forget to add your user to the //docker// group: sudo usermod -aG docker your-user, then log out and log back in.

  • Fedora:

  • Installing Docker from the snap/appimages/flatpak packages is not recommended. Refer to the official documentation instead: https://docs.docker.com/engine/install/fedora/

  • To be able to run Docker without root privileges and at boot, don’t forget to add your user to the //docker// group. Fedora’s own instructions on how to do so: https://developer.fedoraproject.org/tools/docker/docker-installation.html. In case those instructions fail, run the following sequentially in the terminal: sudo groupadd docker
    sudo gpasswd -a ${USER} docker
    sudo systemctl restart docker
    newgrp docker
  • To start the docker daemon at boot: sudo systemctl enable docker, then logout and log back in.
  • Linux Solus: sudo eopkg install –y git docker make
  • Arch Linux: sudo pacman -S docker
  • (for reference) MacOS: see https://docs.docker.com/docker-for-mac/
  • (for reference) Windows: see https://store.docker.com/editions/community/docker-ce-desktop-windows
Preparations

Download the Batocera.Linux sources

If you are already set up to make a Pull Request to Batocera, run:


cd Batocera.Linux
git checkout master

and skip the rest of this step.

Choose a work directory (your $HOME?) and clone the Batocera.Linux source code:


git clone https://github.com/Batocera-Linux/Batocera.Linux.git

Enter the newly created directory.


cd Batocera.Linux

By default, the buildroot submodule will not be cloned. This is required for Batocera, run the following:


git submodule init
git submodule update

You only need to do this once.

Compilation

Easy compilation

To make things easier, there is makefile described here that makes the compilation process smoother.

1. Add your user to the docker group

If you haven’t already, add your user to the “docker” group so that you can run docker commands:

and make sure that your user is in the docker group). For most Linux systems, this can be accomplished by running the following:


sudo usermod -a -G docker $USER

Enter your password when prompted to, then reboot your computer (or if connected via SSH, restart the session).

2. Start up Docker

If you haven’t already configured the Docker daemon to run at boot, you have to get it up and running. On most distros, this can be accomplished with:


sudo systemctl start docker.service

then reboot in order to make sure both the service is running.

3. Install build environment


make build-docker-image

You will have to update this image every once in a while with make update-docker-image.

4. Customize directories

By default, Batocera will download dependencies to $(PROJECT_DIR)/dl and build to the $(PROJECT_DIR)/output folder. You can check the current default directories with the following command:


make vars

To change the directories that Batocera will build to, rename the Batocera.mk.template file to Batocera.mk and change the DL_DIR ?= and OUTPUT_DIR ?= lines to point to wherever you want to.

This is also how you decide which platform you are building for. If making the ordinary “PC” build, this would be x86_64.

This should be aliased in the build process.

If intending to build Raspberry Pi:

Image: broadcom/bcm2835
Hardware: rpizero rpizerow rpi1A rpi1B rpi1A+ rpi1B+ (32-bit)

Image: broadcom/bcm2836
Hardware: rpi2B rpizero2W rpi3B rpi3A+ rpi3B+ (32-bit)

Image: broadcom/bcm2837

Hardware: rpizero2W rpi3B rpi3A+ rpi3B+ (64-bit)

Image: broadcom/bcm2711
Hardware: rpi4B pi400 cm4 (64-bit)

The RPi 3 build currently uses the 64-bit build.

5. Build an image

The build command is different for each target architecture, but they all share the same syntax: make -build. For example:


make x86_64-build

If you have a lot of cores/threads on your compilation CPU, and enough RAM to support it, you can accelerate the compilation time by parallelizing package builds with:


PARALLEL_BUILD=1 make x86_64-build

You can check valid targets architectures by running make vars again.

Every time a new image is built, the output//images folder is completely replaced. Images will not stack up over time, so if you need to keep a particular version copy it out of this folder first.

6. Shell

It’s also possible to get a shell to the desired build environment. Similar to -build, with make rockpro64-shell or:


make x86_64-shell

Once in the shell, it is possible to bring up menuconfig from here to configure the Linux kernel from a nicely-presented UI:


make x86_64-shell
make menuconfig

{{:menuconfig.png?400|}}

7. Build a single package

To build a single package, you can open a shell or use the -pkg target. Examples:


make rk3326-pkg PKG=Batocera-splash
make x86_64-shell PKG=libretro-MAME

Although this will build package itself, it does not do so in the same way that the regular make x86_64-build does. Using a package build cannot be used for testing a package’s successful build, always use -build or -cleanbuild to confirm before making a pull request.

8. ccache

开启编译加速与执行彻底清理

如果你希望为所有的编译任务开启加速，可以调整“Batocera.mk”文件中的相关选项。文件里已经为你提供了一个示例，直接查看“额外选项（EXTRA_OPTS）”部分即可，不需要去修改“默认配置（defconfig）”文件。

9. 执行彻底清理编译（Clean Build）

这个操作会清空输出目录（output/）中的所有数据，并“从零开始”构建系统。

生活化类比： 这就像是你想重新装修房子，与其在旧地板上贴新瓷砖（这可能会导致地面不平或粘贴不牢），不如把旧装修全部铲掉清空，这样新装修才不会出差错。

在以下几种情况下，执行“彻底清理编译”非常有必要：

  • 版本“降级”编译： 如果你刚编译完一个新版本的 Batocera，现在想回头编译旧版本，请务必先清理。这能保证编译缓存（Build Cache）里的新包不会和旧包打架，避免产生那些让人看不懂的错误信息。
  • 处理代码冲突： 尽量避免只挑选特定的代码提交（Cherry-pick Commits）。在 Batocera 中，每个提交可能都依赖于前一个，像链条一样环环相扣。如果你之前尝试过挑选某个提交来编译，请清理一次，确保后续编译不出错。
  • 切换回最新版本： 当你编译完旧版本，又想重新编译最新的主分支版本时，也要再清理一次。
  • 遇到“玄学”报错： 当你遇到一些奇怪的报错，而其他开发者却没遇到时，或者编译过程突然中断导致文件损坏，请直接执行彻底清理。

【提示】只有当你一直紧跟“主分支（Master Branch）”且不做任何自定义修改进行连续编译时，才建议直接使用常规编译命令。

操作步骤：
第一步：打开终端窗口。
第二步：输入并运行以下指令：

make x86_64-cleanbuild

10. 搭建网页服务器（Webserver）升级你的系统

你可以轻松地用刚编译好的成果来升级你的 Batocera 测试机。

生活化类比： 这就像是在你的电脑上开了一家“外卖店”，你的测试机通过网络连接过来，就能直接把刚出炉的系统包“吃”进去。

假设你的编译服务器 IP 地址是 10.0.0.2，且机器上安装了 Python3，你就可以启动这个服务。

操作步骤：
第一步：确认你的编译服务器网络连接正常。
第二步：输入以下指令开启网页服务器：

make x86_64-webserver

接下来，你可以直接在你的 Batocera 测试机上发起升级。

假设托管网页服务器（Webserver）的编译机 IP 地址是 10.0.0.10，你只需要通过 SSH 远程连接（Secure Shell）进入 Batocera 测试机，执行简单的命令，就能像喝到“刚酿好的新鲜啤酒”一样，用你刚刚编译出来的固件进行升级。

操作步骤：
第一步：在你的测试机上开启 SSH 访问。
第二步：在终端输入以下升级指令：

batocera-upgrade http://10.0.0.10:8000

11. 清理旧版本的残留文件

随着时间的推移，系统包会经历多次更新。默认情况下，所有旧版本的源码包和对应的编译产物都会堆积在你的 Batocera 工作目录里。

生活化类比： 这就像是你一直在给手机下载新软件，但旧安装包都还留在手机里占地方。定期清理这些“过时垃圾”，能让你的硬盘重新获得“呼吸空间”。

你可以通过以下指令来管理你的存储空间：

  • 查看过时的源码包： 检查下载目录（dl/）中，哪些包已经有了更新的版本。
    bash
    make find-dl-dups
  • 清理过时的源码包： 彻底删掉下载目录里这些占地方的旧包。
    bash
    make remove-dl-dups
  • 查看过时的编译目录： 在编译树（Build Tree）中，找出因为产生新版本而变得不再需要的旧目录。
    bash
    make x86_64-find-build-dups
  • 清理过时的编译目录： 移除这些过时的编译临时文件夹。
    bash
    make x86_64-remove-build-dups

【提示】上述命令中的 x86_64 只是一个例子，你可以根据你所使用的架构（Arch）名称进行灵活替换。

查找镜像文件位置

如果你是在容器（Container）环境里进行的编译，请先退出容器。

操作步骤：
第一步：进入目录 output/images/batocera/images/<架构名称>。
第二步：找到以 .img.gz 结尾的压缩文件。

【注意】镜像文件名中包含了版本号、平台以及编译日期。
例如：output/images/batocera/images/x86_64/batocera-x86_64-33-20220130.img.gz。

刷写与安装固件

拿到镜像后，你有多种方式来安装它：
1. 工具刷写： 参照安装指南，使用 Raspberry Pi Imager 等工具将镜像写入存储卡或磁盘。
2. 网络升级： 使用上文中提到的网页服务器命令进行在线升级。
3. 手动升级： 按照常规手动替换文件的方式升级。
4. 快速指令刷写： 使用以下指令直接将镜像“闪存（Flash）”到目标设备中。

操作步骤：
第一步：确认你的目标存储设备路径（如 /dev/sdX）。
第二步：运行以下指令（请根据你的实际设备路径和平台进行修改）：

make DEV=/dev/TARGETDEVICE x86_64-flash

实用技巧汇总

调整编译配置

你可以通过修改 “Batocera.mk” 文件中的编译选项，让编译过程更符合你的个人偏好。

【注意】在修改该文件时，请务必保证每一行选项的开头都有一个空格符，千万不要删掉它。

1. 控制性能占用
默认情况下，Docker 容器在编译时会“压榨”你电脑的所有硬件资源。如果你想在编译的同时还能流畅地干点别的（比如看个视频或写文档），建议降低并行任务数（MAKE_JLEVEL）。

生活化类比： 这就像家里的大扫除。默认情况下是全家老少齐上阵，屋里乱成一团你啥也干不了；把数值调低，就像只留一个人干活，虽然慢点，但你能清静地坐在沙发上玩手机。

操作步骤：
第一步：打开配置文件。
第二步：将数值修改为 1。

MAKE_JLEVEL := 1

你也可以通过将“并行编译（PARALLEL_BUILD）”设置为 n 来限制系统仅使用单核运行。
【提示】这样做会导致编译时间大幅增加（甚至可能慢上 12 倍！），请谨慎操作。

PARALLEL_BUILD := n

2. 管理缓存空间
默认情况下，系统会使用编译器缓存（CCACHE）来存储常用的编译函数，这样下次编译就能快很多，但代价是占用磁盘空间。如果你的硬盘空间告急，可以给缓存设个“上限”。

操作步骤：
第一步：找到配置文件中的“额外选项（EXTRA_OPTS）”行。
第二步：在末尾添加限额参数（例如限制为 50G）。

EXTRA_OPTS  :=  BR2_CCACHE_INITIAL_SETUP="--max-size=50G"

预下载源码

在正式开始“大兴土木”编译之前，你可以先从互联网上下载好所有的源代码（Source Code）。

操作步骤：
第一步：确定你的目标架构（以 x86_64 为例）。
第二步：运行预下载指令。

make x86_64-source

【提示】经验分享：可以先让这个命令跑上 10 分钟，然后再正式开启并行编译。

实时监控编译进度

想知道你的 x86_64 编译任务现在进度如何了吗？你可以随时“监工”。

操作步骤：
第一步：打开终端。
第二步：输入以下指令追踪编译日志（Build Log）。

tail -f output/x86_64/build/build-time.log

检查待编译项目

如果你之前运行过源码预下载，可以通过一段简单的指令找出还有多少项目“排队待办”。

操作步骤：
第一步：复制并运行以下组合指令。
第二步：观察输出，它会列出尚未完成编译的目录并统计总数。

for i in output/x86_64/build/*; do test -d "$i" && test -e "$i"/.stamp_built || echo "$i"; done | tee /dev/tty | wc -l

多版本共用下载文件夹

如果你同时编译多个架构，让它们共用同一个下载文件夹（Download Folder）可以节省大量空间和时间。

操作步骤：
第一步：在终端中输入以下指令，将你的本地下载目录挂载到容器中，实现资源共享：

docker run -it --rm -v $PWD:/build -v $HOME/dev/Batocera/DL:/build/dl batocera-docker

Docker 镜像与容器管理

你可以通过以下简单的指令来维护你的 Docker 环境。

1. 查看本地镜像
列出你电脑上已经下载或生成的镜像列表（Docker Images）：

docker image ls

2. 更新镜像
确保你的开发环境处于最新状态：

make update-docker-image

3. 删除镜像
清理掉不再需要的镜像以节省空间：

docker rmi <镜像名称> 或 docker image rm <镜像名称>

4. 查看运行中的容器
查看当前有哪些正在工作的 Docker 容器（Containers）：

docker ps

5. 强制停止容器
如果某个容器卡死或者你需要立即停止它：

docker kill [容器名称]

更多进阶技巧

了解文件夹结构

想要深入了解 Batocera 源代码的组织逻辑，以及你应该在哪里进行代码修改，请参考专门的“源码结构”页面。

解决 Ubuntu 环境下的 qt5base 编译错误

如果在 Ubuntu 系统的 Docker 中遇到 qt5base 编译报错，你可以尝试在启动 Docker 的命令行中添加安全选项，或者更新 libseccomp2 软件包。

操作步骤：
在启动命令中加入：--security-opt seccomp:unconfined

【注意】根据 2020 年 2 月的反馈，这个步骤在较新版本的系统中可能已经不再是必需的了。

在 LXC 容器中编译

如果你更倾向于使用 LXC 容器（Linux Containers）而不是 Docker，请查阅“在 LXC 容器上编译”的相关页面。

跳过特定软件包的编译

在编译过程中，如果你遇到某个包（Package）报错，但你想绕过它先测试后面的内容，可以采用“假装完成”的办法。

生活化类比： 这就像你在做一套考卷，遇到一道死活算不出来的难题。为了不耽误后面的题目，你先在答题纸上填个数字，假装已经做完了，然后继续往下写。

  • 临时跳过： 在对应的编译目录中手动创建后缀名为 .stamp_built 的“印记文件”，系统就会认为它已经成功编译。
  • 永久跳过： 如果你想彻底不编译某个东西，可以去负责它的主包配置文件 Config.in 中将其删掉或注释掉。

操作示例：
例如，你想跳过独立模拟器 PCSX2 及其对应的核心（libretro core），可以找到 package/batocera/core/batocera-system/Config.in 文件，并在对应行前面加上 # 号：

#select BR2_PACKAGE_PCSX2                        if BR2_PACKAGE_BATOCERA_TARGET_X86_64

#select BR2_PACKAGE_PCSX2_AVX2                   if BR2_PACKAGE_BATOCERA_TARGET_X86_64
#select BR2_PACKAGE_LIBRETRO_PCSX2               if BR2_PACKAGE_BATOCERA_TARGET_X86_64

定义特定平台的 Buildroot 配置

假设你打算为树莓派 3（Raspberry Pi 3）编译系统。你可以通过运行以下指令来刷新该平台的编译配置：

操作步骤：
第一步：在终端输入配置命令：

make batocera-rpi3_defconfig

第二步：系统会自动根据 configs/batocera-rpi3_defconfig 生成一份完整的 .config 文件。

生活化类比： defconfig 就像是一张“精简版购物清单”，只写了主菜（比如 Kodi 和 EmulationStation）；而生成的 .config 则是“终极详细清单”，它会自动把做主菜需要的配料（比如 sdl2 依赖包）全部列出来，并标记是否需要购买（编译）。

【提示】如果你在开发或测试过程中手动改乱了 .config 文件，只需再次运行上面的 make 命令，就能将其重置回初始状态。

故障排除

Docker 权限不足导致无法开始编译

如果你选择使用 Docker 进行编译，必须先将你的用户账号添加到“Docker 用户组（Docker Group）”中，否则会因为权限问题被拦截。

【注意】如果由于某些原因你无法将用户加入该组，有一个临时的补救方案：在命令前加上 sudo 来提升权限（例如 sudo make x86_64-build）。但出于系统安全性考虑，不建议在日常操作中频繁使用这种方法。

忽略 Batocera.mk 的变更

如果你本地的 Git 仓库正在追踪 Batocera.mk 的修改，而你又不希望提交这些改动，可以使用以下指令让 Git 显式地忽略它：

git update-index --assume-unchanged Batocera.mk

git update-index --assume-unchanged Batocera.mk

应用 Linux 内核补丁时编译意外停止

这种情况通常是因为目录下的 Linux 内核（Linux Kernel）文件不完整，或者之前的编译过程被强行中断了。

生活化类比： 这就像是你盖房子盖到一半突然停工了，墙砖只垒了一半，现在想重新刷墙漆（打补丁）肯定会出问题。最稳妥的办法就是把这堵烂尾的墙拆掉重建。

操作步骤：
第一步：进入编译环境的终端界面（Shell）。
第二步：手动删除出错的内核构建目录。

make x86_64-shell
rm -rf build/linux-*

【提示】如果编译过程中突然停电、遇到雷暴天气断网或者其他意外导致包编译中断，你也可以用这个方法来“修复”任何受损的软件包。

编译在随机的时间点卡住

首先，请确保你已经更新了最新的 Docker 镜像。

编译可能会在任何阶段卡住，通常与某个特定的模拟器有关。在每个包的 output/build/<包名>-<版本号> 文件夹中，藏着一些“印记文件（.stamp files）”，它们记录了编译进行到了哪一步，比如：下载（download）、解压（extract）、打补丁（patch）、配置（configure）、构建（built）、安装到暂存区（staging_install）或安装到目标位置（target_install）。

操作步骤：
当你识别并解决了问题后，可以通过删除整个包的构建文件夹来让系统重新编译该项目。

以 bsnes 模拟器为例，如果你想手动标记“构建”和“安装”步骤已完成，可以这样做：

touch ~/batocera.linux/output/x86_64/build/libretro-bsnes-hd-0fd18e0f5767284fd373aebd75b00b5bab0d44a9/{.stamp_built,.stamp_target_installed}

如果你想彻底重来，确保彻底解决该包的编译问题，请执行以下动作：
第一步：删除该模拟器的构建文件夹。
第二步：单独重新编译该包。

rm -rf ~/batocera.linux/output/x86_64/build/libretro-bsnes-hd-0fd18e0f5767284fd373aebd75b00b5bab0d44a9
make libretro-bsnes-hd

【提示】通过这个方法，你可以排查出问题到底是出在这个特定的包上，还是整个 Batocera 系统环境出了故障。

编译故障深层排查

编译在随机时间停止，且无法通过印记文件修复

如果你发现即便尝试了手动标记进度，编译依然莫名其妙地中断，那很有可能是下载的代码已经损坏或者版本过时了。

生活化类比： 这就像是你买了一盒拼图，结果里面有几块零件在出厂时就压变形了，或者混进了旧版拼图的碎块。这时候最好的办法不是死磕这几块，而是把这一盒清空，去换一套全新的零件重新开始。

操作步骤：
第一步：确定你的目标架构（Target）。
第二步：运行彻底清理编译指令。

make <target>-cleanbuild

软件包下载地址失效或出现 404 错误

有时候，源代码的下载链接失效了。你可以通过手动下载来临时绕过这个“断头路”。

操作步骤：
第一步：找到报错的软件包，手动从其他渠道下载对应的压缩包（例如 xa-2.3.11.tar.gz）。
第二步：将该文件放入项目下的 dl/<软件包名称> 文件夹中。

目录结构示例：

Batocera.Linux/
└─ dl/
   └─ xa/
      └─ xa-2.3.11.tar.gz

此外，当你切换到全新的 Batocera 版本进行 x86_64 编译时，也可能遇到这种情况。比如 wine/wow64 这个巨大的包，如果 GitHub 仓库里还没上传对应版本的 wine-x86-<版本号>.tar.lzma，就会报错 404。

【提示】 解决办法是：先运行一次 make x86_wow64-cleanbuild，然后将生成的包手动放进你的 dl/wine-x86/ 目录中。

在 Docker 下编译时，下载工具（wget）卡死无响应

这通常是因为 Docker 内部的最大传输单元（MTU）与你宿主系统的设置不匹配，导致数据传输“对不上信号”。

生活化类比： 就像是一条隧道（网络接口），Docker 觉得自己的车（数据包）能过，但宿主系统的隧道入口其实更窄。车卡在洞口，交通就彻底瘫痪了。

操作步骤：
第一步：通过 ifconfig 或 ip a 命令，检查宿主机网卡和 Docker 网卡的 mtu 值。
第二步：如果你使用了 Wireguard 等虚拟网络，它们的 MTU 通常低于默认的 1500（例如是 1420）。
第三步：编辑或创建 /etc/docker/daemon.json 文件，将 Docker 的 MTU 修改为相同数值：

{
  "mtu": 1420
}

常见编译后疑问处理

编译完成后，一大堆 .po 文件被修改了，但我根本没碰过它们！

如果你发现本地出现了一堆国际化多语言文件（.po 文件）的改动，别担心，这通常是因为有人在合并主分支（Master Branch）代码前没有进行编译，导致这些文件版本过旧。当你开始编译时，系统会自动更新它们。

生活化类比： 这就像是你接手了一个账本，虽然你没改账目，但因为之前的会计漏算了几笔，你一打开计算器（开始编译），账本就会自动跳到正确的总额。这属于“自动补课”，不必惊慌。

【提示】 通常情况下你可以忽略这些改动。如果你的修改没有涉及新的文字内容，可以放心丢弃所有的 Batocera-es-system.po 和 Batocera-es-system.pot 文件。当然，把它们包含在提交里也没问题，下次主分支编译时它们还是会被更新。

【注意】但有一个例外： 如果主分支合并了新代码但未编译（增加了新词条），而此时某位效率极高的翻译员已经提前翻译好了这些新词。如果你此时提交自己自动生成的 PO 文件，就会覆盖掉人家辛苦翻译的成果。在这种特定情况下，你必须丢弃这些自动生成的文件。

编译成功了，但我做的改动却没生效

如果你没有修改软件包（Package）的版本号，且该包的文件夹已经存在于 output/<架构>/build/<软件包名> 中，Buildroot 编译工具就会“偷懒”，直接沿用旧的、未修改的版本，从而跳过重新编译。

生活化类比： 这就像是厨师发现厨房里有一盘现成的配菜，只要你没告诉他这菜过期了（改版本号），他为了省事就会直接端上去，而不会发现你其实偷偷换了调料。

操作步骤：
第一步：在 output 目录下找到对应的软件包文件夹。
第二步：手动删除该文件夹。
第三步：重新运行编译指令，强制系统从头构建。

例如，如果你修改了 es_systems.yml 文件来添加新系统，你需要执行以下操作：
第一步：定位到编译目录。
第二步：删除 build/batocera-configgen 文件夹。
第三步：再次开始编译。

原文: 从源码编译Batocera • 翻译: DIY8 Bot

© 版权声明
文章版权归作者所有，未经允许请勿转载。
评论 抢沙发

请登录后发表评论

    暂无评论内容

搜索Batocera教程
Batocera教程
搜索Batocera教程
主题文档