)
桌面应用【免费下载链接】BottlesRun Windows software and games on Linux项目地址https://gitcode.com/gh_mirrors/bo/Bottles点击查看免费下载本指南以仓库根目录下的 CODING_GUIDE.md 为主线结合 Bottles 项目的构建清单build-aux/com.usebottles.bottles.Devel.json、Meson 构建脚本、测试目录与 i18n 配置完整还原开发者在本地搭建 Bottles在 Linux 上运行 Windows 软件与游戏的图形前端开发环境的四类标准操作Flatpak 构建与运行、单元测试执行、Python 依赖清单再生成、翻译PO文件维护。读完本文你将能够在自己的机器上构建并运行 Bottles 的开发版com.usebottles.bottles.Devel、跑通全量单元测试并规范化地维护项目的依赖与多语言翻译文件。一、总览CODING_GUIDE 的核心开发脉络CODING_GUIDE.md 是 Bottles 面向开发者的最短操作手册全文围绕四条主线展开本地构建与运行通过flatpak-builder使用仓库内的 Devel manifest 构建并安装开发版随后运行、卸载单元测试在仓库根目录直接运行pytest .依赖清单当requirements.txt变化时重新生成 Python 依赖的 Flatpak 清单pypi-depsi18n 文件维护维护po/POTFILES、po/bottles.pot与各语言po/*.po的再生成流程。这些步骤分别对应仓库中的 build-aux/、tests/、requirements.txt 与 po/ 目录。下面按文档顺序逐一展开并补充源码级细节。二、使用 Flatpak 构建、运行与卸载开发版Bottles 官方以 Flatpak 为主要分发形态见 README.md 的 Building 一节因此 CODING_GUIDE 给出的本地开发路径也是 Flatpak 化的。开发版与正式版共用源码但通过Devel后缀的 manifest 与 application ID 区分。2.1 构建并安装 Devel 版文档给出的构建命令flatpak-builder --install --user --force-clean ./.flatpak-builder/out ./build-aux/com.usebottles.bottles.Devel.json参数含义flatpak-builderFlatpak 构建工具读取 manifest 后解析模块依赖、下载源码与运行时并执行构建--install --user构建完成后安装到当前用户的应用目录无需 root--force-clean每次构建前清空输出目录./.flatpak-builder/out保证干净构建./build-aux/com.usebottles.bottles.Devel.json开发版 manifest位于 build-aux/com.usebottles.bottles.Devel.json。从 meson.build 可以看到Devel后缀的由来当 Meson 的profile选项为development时APP_ID会被追加.Devel即com.usebottles.bottles.Devel版本号末尾还会追加git rev-parse --short HEAD得到的短提交哈希。也就是说开发版与应用商店版共享同一份源码只是以不同的 application ID 并行安装、互不冲突。仓库还提供了封装好的构建脚本 build-aux/build.sh它基于org.flatpak.BuilderGNOME 官方推荐的 Flatpak 构建器实现同一流程使用host-spawn flatpak run org.flatpak.Builder --force-clean --user --install ...指向同一份 Devel manifest并把构建状态目录放到项目根下的.flatpak-builder。你也可以直接执行该脚本代替手敲长命令。注意构建前请确保系统已安装org.freedesktop.Sdk对应的 GNOME 运行时manifest 中声明了 runtime 与 SDK并提前备份重要数据——README 特别提醒测试实验性构建前请备份所有数据。2.2 运行开发版flatpak run com.usebottles.bottles.Devel该命令会启动以com.usebottles.bottles.Devel为 ID 的 Flatpak 应用。由于开发版与稳定版共用 Bottles 数据目录~/.var/app/com.usebottles.bottles/下的配置与瓶容器数据README 提示两者修改的数据会互相影响因此在开发版上做的改动也会作用于稳定版数据测试实验性功能时务必留意。2.3 卸载开发版flatpak uninstall com.usebottles.bottles.Devel该命令从用户环境移除开发版应用但不会影响已安装的稳定版com.usebottles.bottles。卸载后如需重新开发重复 2.1 的构建命令即可。三、单元测试pytest .与测试目录结构文档规定的最简测试入口pytest .在仓库根目录执行即可发现并运行全部测试。测试代码按后端/前端/仓库抽象层组织在 tests/ 目录下tests/backend/覆盖后端管理器与工具层例如 tests/backend/manager/test_manager.py、tests/backend/manager/test_versioning.py、tests/backend/umu/test_executor.pytests/backend/integration/playtime/针对游玩时长playtime聚合、信号、失败恢复等场景的集成测试tests/frontend/覆盖 GTK 前端视图、对话框与工具函数例如 tests/frontend/test_bottle_details.py、tests/frontend/test_umu_frontend.pytests/fvs/文件验证服务FVS抽象层测试顶层还有 tests/conftest.py 与 tests/test_funding.py 等。在运行pytest .时tests/conftest.py 会自动把仓库根目录插入sys.path保证未安装包时import bottles也能工作。这解释了为什么文档要求在仓库根目录执行pytest .——所有测试都假定仓库根目录可导入。提示完整测试依赖第三方包如 pytest、PyYAML、yara-python 等请参照 requirements.dev.txt 与 requirements.txt 安装开发依赖后再执行。四、依赖管理重新生成 Flatpak Python 依赖清单Bottles 后端依赖较多全部通过requirements.txt固定版本。当该文件变更后需要重新生成供 Flatpak manifest 使用的 Python 依赖模块清单文档给出的命令是python ./build-aux/flatpak-pip-generator.py --runtime org.gnome.Sdk -r requirements.txt -o com.usebottles.bottles.pypi-deps --yaml这条命令的逻辑读取-r requirements.txt中的依赖基于--runtime org.gnome.Sdk计算 wheel 与 sdist 的下载地址输出为--yaml格式的依赖模块文件供 manifest 引用。需要说明的事实校正从当前仓库快照看build-aux/ 目录下并未包含flatpak-pip-generator.py脚本其中仅有req2flatpak子目录、fvs2.yaml、umu-launcher.yaml等而 build-aux/pypi-deps.yaml 的文件头注释明确标注Generated by req2flatpak.py --requirements-file requirements.txt --yaml --target-platforms 313-x86_64 -o build-aux/pypi-deps.yaml即当前仓库实际的依赖清单由req2flatpak.py生成。因此若你基于当前快照维护依赖请以仓库实际的生成脚本与产物为准CODING_GUIDE 中的flatpak-pip-generator.py命令属于历史工作流在部署新环境时应与仓库现有工具链对齐。生成的 build-aux/pypi-deps.yaml 结构如下节选关键字段# Generated by req2flatpak.py ... name: python3-package-installation buildsystem: simple build-commands: - pip3 install --verbose --exists-actioni --no-index --find-linksfile://${PWD} --prefix${FLATPAK_DEST} --no-build-isolation wheel PyYAML pycurl chardet requests PySocks Markdown icoextract patool pathvalidate FVS orjson pycairo PyGObject ... sources: - type: file url: https://files.pythonhosted.org/packages/.../FVS-0.3.4.tar.gz sha256: c987741f37706ea07d91ec498c145162676ca16b59b5c8c2351cf464954ce422 - type: file url: https://files.pythonhosted.org/packages/.../pygobject-3.56.3.tar.gz sha256: 12760e4a0e3d04b6eb95e06f7a27e362c826d567ea613373a92c003b6c70d2d6该 YAML 以buildsystem: simple定义了一个 pip 安装模块构建时通过pip3 install --no-index --find-links从本地文件安装全部锁定版本的包每个包以type: file的 source 携带 PyPI 下载 URL 与sha256校验值。这份文件被 build-aux/com.usebottles.bottles.Devel.json 与fvs2.yaml一起引用是 Flatpak 构建时拉取 Python 依赖的唯一来源——所以任何requirements.txt的变更都必须同步再生这份清单否则构建会因依赖缺失或校验失败而中断。五、i18n 翻译文件维护Bottles 的界面文本通过 gettext 体系管理全部翻译资源位于 po/ 目录。文档将其分为两类文件并有各自的再生成流程。5.1po/POTFILES含可翻译字符串的源文件清单po/POTFILES是哪些源码文件包含可翻译字符串的清单在新增/移动/删除/重命名了含翻译字符串的文件后必须重新生成。文档给出的是基于 grep 的生成命令cat po/POTFILES EOF # List of source files containing translatable strings. # Please keep this file sorted alphabetically. EOF grep -rlP _\([\] bottles | sort po/POTFILES cat po/POTFILES EOF data/com.usebottles.bottles.desktop.in.in data/com.usebottles.bottles.gschema.xml data/com.usebottles.bottles.metainfo.xml.in.in EOF其工作原理用grep -rlP _\([\] bottles在bottles/源码树中递归找出所有出现_(...)/_(...)翻译宏的 Python 文件再sort排序除 Python 源码外把三个数据文件固定追加进清单data/com.usebottles.bottles.desktop.in.in桌面入口、data/com.usebottles.bottles.gschema.xmlGSettings schema与 data/com.usebottles.bottles.metainfo.xml.in.in应用元信息。当前 po/POTFILES 即为该流程的产物开头是两行注释随后是bottles/backend/managers/backup.py、bottles/backend/managers/eagle.py、bottles/frontend/main.py、bottles/frontend/ui/details.blp等一系列按字母序排列的源码与.blpBlueprint UI文件路径。5.2po/bottles.pot与po/*.po翻译模板与语言文件po/bottles.pot是主翻译模板gettext POT其余po/语言.po是各语言翻译文件仓库中已包含zh_CN.po、zh_Hans.po、fr.po、ja.po等数十种语言语言列表见 po/LINGUAS。当任何可翻译字符串被增删改后需要重新生成 POT 与各 PO文档给出的命令# make sure you have meson and blueprint-compiler installed meson setup /tmp/i18n-build meson compile -C /tmp/i18n-build/ bottles-pot meson compile -C /tmp/i18n-build/ bottles-update-po流程说明meson setup /tmp/i18n-build在临时目录配置一个独立的构建树不污染源码目录meson compile -C /tmp/i18n-build/ bottles-pot调用自定义 targetbottles-pot从po/POTFILES提取字符串生成/刷新po/bottles.potmeson compile -C /tmp/i18n-build/ bottles-update-po用新的 POT 合并更新所有po/*.pomsgmerge语义。这些 target 由 po/meson.build 中的i18n.gettext(com.usebottles.bottles, install_dir: localedir, preset: glib, args: --from-codeUTF-8, languages: language_list)自动注册。注意该文件还做了一件重要的事从 po/LINGUAS 读取语言列表后追加了zh_CN、zh_HK、zh_SG、zh_TW四个中文别名注释引用了 Bottles issue #1692 与 Weblate 文档确保简体/繁体中文在各类发行版 locale 命名下都能正确匹配到翻译。这正是po/目录同时存在zh_CN.po、zh_Hans.po、zh_Hant.po、zh_TW.po、zh_SG.po、zh_HK.po多个变体的原因。六、补充Meson 直接构建路径非 Flatpak对于不想经 Flatpak 沙箱调试的场景README 提供了仓库内的 Meson 构建脚本 build-aux/install.shmeson --prefix$PWD/build build ninja -j$(nproc) -C build install即在 Flatpak 开发环境的 shell 内flatpak run -d --filesystem$PWD --commandbash com.usebottles.bottles.Devel执行该脚本将 Bottles 安装到仓库内的build/目录再以./build/bin/bottles启动。由于 Bottles 官方仅以 Flatpak 形式分发这种直接构建方式必须运行在 Devel Flatpak 提供的沙箱 shell 中才能获得完整运行时依赖这点与 CODING_GUIDE 的 Flatpak 主线互为补充。七、开发自检清单完成一次完整的 Bottles 开发迭代可按以下顺序自检依赖变更修改 requirements.txt 后立即用仓库实际的生成工具req2flatpak.py产物 build-aux/pypi-deps.yaml再生成依赖清单构建验证在仓库根目录执行flatpak-builder --install --user --force-clean ./.flatpak-builder/out ./build-aux/com.usebottles.bottles.Devel.json或直接运行 build-aux/build.sh确认com.usebottles.bottles.Devel能构建、安装与运行测试回归执行pytest .确认全部单元测试与集成测试通过仓库根目录下的 tests/conftest.py 已自动处理导入路径翻译同步若改动涉及界面字符串依次执行po/POTFILES的 grep 再生成流程与meson setup /tmp/i18n-build meson compile -C /tmp/i18n-build/ bottles-pot meson compile -C /tmp/i18n-build/ bottles-update-po让 po/POTFILES、po/bottles.pot 与各po/*.po保持同步。以上就是 CODING_GUIDE.md 给出的完整开发工作流。它是仓库中最小但最实用的开发入口文档围绕 Flatpak 构建、测试、依赖与翻译四条主线配合上述源码证据你可以在本地完整复现 Bottles 的日常开发闭环。赞分享桌面应用【免费下载链接】BottlesRun Windows software and games on Linux项目地址https://gitcode.com/gh_mirrors/bo/Bottles点击查看免费下载相关推荐Cockpit 开发实战指南从环境搭建、构建测试到调试的完整工作流HACKING.md 深度解读Cockpit 开发实战指南从环境搭建、构建测试到调试的完整工作流HACKING.md 深度解读 Cockpit 是一个基于 Web 的服务器图形管理界面后端运维Conductor 工作流单元测试与回归测试实战指南Conductor 工作流单元测试与回归测试实战指南 工作流编排引擎 Conductor 提供了一套完整的测试机制允许开发者不启动任何 Worker 程序仅工作流自动化任务调度后端深入解读 Angular CLI 生成的 SSRWebpack项目开发、构建与测试工作流实战深入解读 Angular CLI 生成的 SSRWebpack项目开发、构建与测试工作流实战 本文以 Angular CLI 仓库中的 SSR 项目示例CLI开发工具前端构建构建工具代码生成前端上一篇终极README模板实战指南从零到专业文档的10个技巧下一篇告别模板脸taste-skill 让 AI 前端生成带上设计品味创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考