尧图网站建设 
Zelda64Recomp Flatpak 打包全流程从 Manifest 构建到 Bundle 发行【免费下载链接】Zelda64RecompStatic recompilation of Majoras Mask (and soon Ocarina of Time) for PC (Windows/Linux/Mac)项目地址: https://gitcode.com/GitHub_Trending/ze/Zelda64Recomp本文以 flatpak/README.md 为主线完整讲解 Zelda64Recomp《Majoras Mask》PC 端静态重编译项目如何在 Linux 发行版中以 Flatpak 形式构建与发布。读完后你将掌握为何 patches 必须在 Flatpak 之外预先编译、manifest 文件io.github.zelda64recomp.zelda64recomp.json中 runtime、sdk-extensions、finish-args 与 build-commands 的各项含义以及flatpak-builder/flatpak build-bundle两条核心命令背后的完整构建链路并能结合源码中的RECOMP_FLATPAK宏理解 Flatpak 运行时环境/app、/var/data沙箱路径对程序行为的实际影响。为什么必须在打包前先编译 patchesflatpak/README.md 开宗明义地指出Before building the Flatpak, you must build the patches on the root directory first.The LLVM Extension for freedesktop does not include the MIPS compiler and will fail to build the patches inside the flatpak.原因是Zelda64Recomp 的 patches/ 目录中是一组针对 N64 原版机器码的 C 语言补丁需要用 Clang 以MIPS 交叉目标编译再用 LLD 链接成patches.elf。而 Flatpak 构建沙箱中提供的org.freedesktop.Sdk.Extension.llvm18扩展只带通用 LLVM 工具链没有 MIPS 目标后端因此在沙箱内编译 patches 必然失败。README 给出的解决方案就是在宿主机仓库根目录先手动编译make -C patches CCclang LDld.lld结合 patches/Makefile 可以看到这条命令实际做了什么CC ? clang LD ? ld.lld CFLAGS : -target mips -mips2 -mabi32 -O2 -G0 -mno-abicalls -mno-odd-spreg -mno-check-zero-division \ -fomit-frame-pointer -ffast-math -fno-unsafe-math-optimizations -fno-builtin-memset ... CPPFLAGS : -nostdinc -D_LANGUAGE_C -DMIPS -I dummy_headers -I ../lib/mm-decomp/include -I ../lib/mm-decomp/src -I ../lib/mm-decomp/assets -I../lib/rt64/include LDFLAGS : -nostdlib -T patches.ld -T syms.ld -Map patches.map --unresolved-symbolsignore-all --emit-relocs $(C_OBJS): %.o : %.c $(CC) $(CFLAGS) $(CPPFLAGS) $ -MMD -MF $(:.o.d) -c -o $几个关键点-target mips -mips2 -mabi32指定了 N64 CPU 的指令集与调用约定这就是为什么需要系统级安装的 Clangapt-get install clang lld之类参见 BUILDING.md 的依赖安装一节而不是沙箱内的 LLVM 扩展CPPFLAGS中的-I ../lib/mm-decomp/...说明补丁依赖mm-decomp反编译代码的头文件-nostdlib -T patches.ld -T syms.ld表示无标准库、使用仓库自带的链接脚本 patches/patches.ld 与 patches/syms.ld 进行裸链接--emit-relocs则保留重定位信息供后续 N64Recomp 重编译消费。编译产物patches/patches.elf被 CMake 主构建流程直接引用CMakeLists.txt 中PatchesBin目标会以CCclang LDld.lld环境再次运行make并由./N64Recomp patches.toml把 ELF 重编译为patches.c/patches.bin/recomp_overlays.inl。由于 Flatpak 沙箱无法完成这一步README 才要求构建者提前在根目录生成好这些中间产物。Manifest 文件结构解析构建的输入是 flatpak/io.github.zelda64recomp.zelda64recomp.json这是标准的 Flatpak manifest。逐段解读应用 ID 与运行时{ id: io.github.zelda64recomp.zelda64recomp, runtime: org.freedesktop.Platform, runtime-version: 23.08, sdk: org.freedesktop.Sdk, sdk-extensions: [ org.freedesktop.Sdk.Extension.llvm18 ] }id采用反向域名风格的io.github.org.app后续 desktop 文件、metainfo 与 bundle 文件名都以此为基准运行时固定为 freedesktop 23.08 分支SDK 额外挂载llvm18 扩展为构建期提供 CMake 编译所需的 ClangC 侧工具链。注意它只有 x86_64 通用目标MIPS 交叉编译仍需宿主机的 Clang上一节所述。finish-args运行时沙箱授权finish-args: [ --sharenetwork, --socketwayland, --socketfallback-x11, --socketpulseaudio, --deviceall, --filesystemhost, --filesystem/media, --filesystem/run/media, --filesystem/mnt ]Flatpak 默认是完全隔离的沙箱这组参数逐项放开了游戏运行所需的能力参数作用对本项目的意义--sharenetwork开放网络访问从源码结构看构建期build-args也用了--sharenetwork以便从 git 拉取 N64Recomp 子模块--socketwayland/--socketfallback-x11Wayland 优先X11 兜底RT64 渲染引擎基于 SDL2 窗口Linux 分支使用RT64_SDL_WINDOW_VULKAN见 CMakeLists.txt必须有显示协议通道--socketpulseaudio音频输出游戏通过 SDL 音频子系统以 48kHz 采样率初始化src/main/main.cpp 中SDL_InitSubSystem(SDL_INIT_AUDIO); reset_audio(48000);--deviceall访问全部设备节点需要访问/dev/input/*等以支持手柄metainfo 中声明了 gamepad 支持--filesystemhost可访问宿主机全部路径允许用户在任意位置存放 ROM 文件--filesystem/media、--filesystem/run/media、--filesystem/mnt可读写可移动存储覆盖 U 盘、SD 卡等挂载点方便从外部介质读取 ROMModule 与构建步骤manifest 只有一个 moduleZelda64Recompiled采用buildsystem: simple——即不套 meson/autotools 等标准构建系统而是按build-commands数组原样执行脚本。命令可分为三个阶段阶段一构建并运行重编译器生成 C 代码cmake -DCMAKE_BUILD_TYPERelease -DCMAKE_CXX_COMPILERclang -DCMAKE_C_COMPILERclang \ -DCMAKE_MAKE_PROGRAMninja -G Ninja -S lib/N64Recomp -B lib/N64Recomp/cmake-build cmake --build lib/N64Recomp/cmake-build --config Release --target N64Recomp --parallel cmake --build lib/N64Recomp/cmake-build --config Release --target RSPRecomp --parallel cp lib/N64Recomp/cmake-build/N64Recomp N64Recomp cp lib/N64Recomp/cmake-build/RSPRecomp RSPRecomp ./N64Recomp us.rev1.toml ./RSPRecomp aspMain.us.rev1.toml ./RSPRecomp njpgdspMain.us.rev1.toml这段与 BUILDING.md 第 4 节的本地流程完全对应先编译出N64RecompCPU 重编译器与RSPRecomp协处理器 DSP 重编译器再用仓库根目录的三个配置文件 us.rev1.toml、aspMain.us.rev1.toml、njpgdspMain.us.rev1.toml 作为输入把《Majoras Mask》US rev1 的主程序与两块 DSP 固件静态重编译为 C 源码输出到RecompiledFuncs/、rsp/目录供后续 CMake 编译进可执行文件。阶段二以 RECOMP_FLATPAK 开关构建主程序cmake -DCMAKE_BUILD_TYPERelease -DCMAKE_CXX_COMPILERclang -DCMAKE_C_COMPILERclang \ -DCMAKE_MAKE_PROGRAMninja -DPATCHES_C_COMPILERclang -DPATCHES_LDld.lld \ -DRECOMP_FLATPAKON -G Ninja -S . -B cmake-build cmake --build cmake-build --config Release --target Zelda64Recompiled --parallel这里-DRECOMP_FLATPAKON是关键差异项。对照 CMakeLists.txtif (CMAKE_SYSTEM_NAME MATCHES Linux) option(RECOMP_FLATPAK Configure the build for Flatpak compatibility. OFF) endif() if (RECOMP_FLATPAK) add_compile_definitions(RECOMP_FLATPAK) endif()该选项仅在 Linux 下存在开启后向整个工程注入RECOMP_FLATPAK编译宏。宏在源码中的两处消费src/main/support.cpp 的get_program_path()std::filesystem::path get_program_path() { #if defined(__APPLE__) return get_bundle_resource_directory(); #elif defined(__linux__) defined(RECOMP_FLATPAK) return /app/bin; #else return ; #endif }Flatpak 应用的可执行文件被安装到/app/bin因此资源基路径固定为/app/binget_asset_path()在其后拼接assets/文件。这也解释了 manifest 中为何要把assets/整目录拷到/app/bin/assets。src/main/main.cpp 的启动逻辑#if defined(__linux__) defined(RECOMP_FLATPAK) // When using Flatpak, applications tend to launch from the home directory by default. // Mods might use the current working directory to store the data, so we switch it to a directory // with persistent data storage and write permissions under Flatpak to ensure it works. std::error_code ec; std::filesystem::current_path(/var/data, ec); #endifFlatpak 启动时工作目录默认落在 home而沙箱中/var/data是官方保证的持久化数据目录跨版本升级保留这里主动把 CWD 切过去是为了让依赖“当前工作目录”存放数据的 Mod 在升级后数据不丢失。另外构建期的build-options把 llvm18 扩展的路径接入沙箱build-options: { append-path: /usr/lib/sdk/llvm18/bin, prepend-ld-library-path: /usr/lib/sdk/llvm18/lib, build-args: [ --sharenetwork ] }其中--sharenetwork允许构建沙箱联网拉取sources中的 git 依赖——N64Recomp按 commit989a86b...固定检出到lib/N64Recompmanifest 内dest字段指定另一个 source{type: dir, path: ../}则把仓库根目录整体灌入构建环境所以 build-commands 里能直接引用us.rev1.toml、patches/等文件。阶段三安装到 /apprm -rf assets/scss mkdir -p /app/bin cp cmake-build/Zelda64Recompiled /app/bin/Zelda64Recompiled cp recompcontrollerdb.txt /app/bin/recompcontrollerdb.txt cp -R assets /app/bin/assets install -Dm644 icons/512.png /app/share/icons/hicolor/512x512/apps/${FLATPAK_ID}.png install -Dm644 flatpak/io.github.zelda64recomp.zelda64recomp.metainfo.xml /app/share/metainfo/${FLATPAK_ID}.metainfo.xml install -Dm644 flatpak/io.github.zelda64recomp.zelda64recomp.desktop /app/share/applications/${FLATPAK_ID}.desktop逐条对应 Flatpak 的目录规范/app/bin放二进制、controllerdb 与assets与源码中get_program_path()返回值互相印证/app/share/icons、/app/share/metainfo、/app/share/applications分别放置图标、软件中心元数据与桌面项。注意rm -rf assets/scss先移除了 SCSS 源码——它们只是开发期构建recomp.rcss的中间产物运行时只消费编译好的 CSS。执行构建flatpak-builderflatpak/README.md 给出的构建命令为flatpak-builder --force-clean --user --install-deps-fromflathub --reporepo --install builddir io.github.zelda64recomp.zelda64recomp.json参数逐一说明路径相对于flatpak/目录所在仓库布局运行--force-clean每次构建前清空builddir状态保证可重复构建--user在用户级 Flatpak 仓库中安装 SDK 依赖无需 root--install-deps-fromflathub直接从 Flathub 仓库安装 runtime/SDK 依赖省去手动flatpak install--reporepo把构建产物写入本地仓库repo/后续 bundle 命令的输入--install构建完成后直接装进本机builddir构建状态目录。生成可分发 Bundleflatpak build-bundle构建成功后README 的最后一条命令把本地repo/打包成单文件 bundleflatpak build-bundle repo io.github.zelda64recomp.zelda64recomp.flatpak io.github.zelda64recomp.zelda64recomp --runtime-repohttps://flathub.org/repo/flathub.flatpakrepo--runtime-repo参数会在 bundle 内嵌 Flathub 运行时仓库地址用户通过flatpak install安装该.flatpak文件时会自动从 Flathub 拉取org.freedesktop.Platform 23.08运行时无需额外配置仓库来源。产物io.github.zelda64recomp.zelda64recomp.flatpak即可随发行版附带分发。桌面项与元数据bundle 内嵌的两个元数据文件决定了应用在游戏库/软件中心中的呈现flatpak/io.github.zelda64recomp.zelda64recomp.desktopExec/app/bin/Zelda64Recompiled、CategoriesGame;并注册了自定义 URI schemex-scheme-handler/zelda64recomp从源码结构看这为通过链接打开特定存档/配置预留了入口flatpak/io.github.zelda64recomp.zelda64recomp.metainfo.xml声明许可证为GPL-3.0、支持 pointing/keyboard/touch/gamepad 四种输入设备描述中明确指出“需要原版游戏才能运行本项目”the original game is required这与 BUILDING.md 中要求提供 US 版解压 ROMsha1:d6133ace5afaa0882cf214cf88daba39e266c078文件名为mm.us.rev1.rom_uncompressed.z64的前提一致。小结完整工作流把 README 与 manifest 串起来Zelda64Recomp 的 Flatpak 发行流水线是宿主机侧make -C patches CCclang LDld.lld预编译 MIPS patches沙箱 LLVM 扩展无 MIPS 后端此步不可省构建侧flatpak-builder --force-clean --user --install-deps-fromflathub --reporepo --install builddir manifest沙箱内完成 N64Recomp/RSPRecomp 构建 → 重编译 ROM 与 DSP 固件 →RECOMP_FLATPAKON构建主程序 → 安装至/app发行侧flatpak build-bundle --runtime-repo...生成自含运行时来源声明的单文件 bundle。源码层面对应的两处 Flatpak 特化/app/bin资源路径、/var/data工作目录切换保证了打包后的应用在资源查找与 Mod 数据持久化上与桌面规范对齐。整套方案的前提是构建机为 Linux、已安装 Clang/LLD含 MIPS 目标与 flatpak-builder且已按 BUILDING.md 准备好 US rev1 的解压 ROM。【免费下载链接】Zelda64RecompStatic recompilation of Majoras Mask (and soon Ocarina of Time) for PC (Windows/Linux/Mac)项目地址: https://gitcode.com/GitHub_Trending/ze/Zelda64Recomp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Zelda64Recomp Flatpak 打包全流程：从 Manifest 构建到 Bundle 发行
Zelda64Recomp Flatpak 打包全流程从 Manifest 构建到 Bundle 发行【免费下载链接】Zelda64RecompStatic recompilation of Majoras Mask (and soon Ocarina of Time) for PC (Windows/Linux/Mac)项目地址: https://gitcode.com/GitHub_Trending/ze/Zelda64Recomp本文以 flatpak/README.md 为主线完整讲解 Zelda64Recomp《Majoras Mask》PC 端静态重编译项目如何在 Linux 发行版中以 Flatpak 形式构建与发布。读完后你将掌握为何 patches 必须在 Flatpak 之外预先编译、manifest 文件io.github.zelda64recomp.zelda64recomp.json中 runtime、sdk-extensions、finish-args 与 build-commands 的各项含义以及flatpak-builder/flatpak build-bundle两条核心命令背后的完整构建链路并能结合源码中的RECOMP_FLATPAK宏理解 Flatpak 运行时环境/app、/var/data沙箱路径对程序行为的实际影响。为什么必须在打包前先编译 patchesflatpak/README.md 开宗明义地指出Before building the Flatpak, you must build the patches on the root directory first.The LLVM Extension for freedesktop does not include the MIPS compiler and will fail to build the patches inside the flatpak.原因是Zelda64Recomp 的 patches/ 目录中是一组针对 N64 原版机器码的 C 语言补丁需要用 Clang 以MIPS 交叉目标编译再用 LLD 链接成patches.elf。而 Flatpak 构建沙箱中提供的org.freedesktop.Sdk.Extension.llvm18扩展只带通用 LLVM 工具链没有 MIPS 目标后端因此在沙箱内编译 patches 必然失败。README 给出的解决方案就是在宿主机仓库根目录先手动编译make -C patches CCclang LDld.lld结合 patches/Makefile 可以看到这条命令实际做了什么CC ? clang LD ? ld.lld CFLAGS : -target mips -mips2 -mabi32 -O2 -G0 -mno-abicalls -mno-odd-spreg -mno-check-zero-division \ -fomit-frame-pointer -ffast-math -fno-unsafe-math-optimizations -fno-builtin-memset ... CPPFLAGS : -nostdinc -D_LANGUAGE_C -DMIPS -I dummy_headers -I ../lib/mm-decomp/include -I ../lib/mm-decomp/src -I ../lib/mm-decomp/assets -I../lib/rt64/include LDFLAGS : -nostdlib -T patches.ld -T syms.ld -Map patches.map --unresolved-symbolsignore-all --emit-relocs $(C_OBJS): %.o : %.c $(CC) $(CFLAGS) $(CPPFLAGS) $ -MMD -MF $(:.o.d) -c -o $几个关键点-target mips -mips2 -mabi32指定了 N64 CPU 的指令集与调用约定这就是为什么需要系统级安装的 Clangapt-get install clang lld之类参见 BUILDING.md 的依赖安装一节而不是沙箱内的 LLVM 扩展CPPFLAGS中的-I ../lib/mm-decomp/...说明补丁依赖mm-decomp反编译代码的头文件-nostdlib -T patches.ld -T syms.ld表示无标准库、使用仓库自带的链接脚本 patches/patches.ld 与 patches/syms.ld 进行裸链接--emit-relocs则保留重定位信息供后续 N64Recomp 重编译消费。编译产物patches/patches.elf被 CMake 主构建流程直接引用CMakeLists.txt 中PatchesBin目标会以CCclang LDld.lld环境再次运行make并由./N64Recomp patches.toml把 ELF 重编译为patches.c/patches.bin/recomp_overlays.inl。由于 Flatpak 沙箱无法完成这一步README 才要求构建者提前在根目录生成好这些中间产物。Manifest 文件结构解析构建的输入是 flatpak/io.github.zelda64recomp.zelda64recomp.json这是标准的 Flatpak manifest。逐段解读应用 ID 与运行时{ id: io.github.zelda64recomp.zelda64recomp, runtime: org.freedesktop.Platform, runtime-version: 23.08, sdk: org.freedesktop.Sdk, sdk-extensions: [ org.freedesktop.Sdk.Extension.llvm18 ] }id采用反向域名风格的io.github.org.app后续 desktop 文件、metainfo 与 bundle 文件名都以此为基准运行时固定为 freedesktop 23.08 分支SDK 额外挂载llvm18 扩展为构建期提供 CMake 编译所需的 ClangC 侧工具链。注意它只有 x86_64 通用目标MIPS 交叉编译仍需宿主机的 Clang上一节所述。finish-args运行时沙箱授权finish-args: [ --sharenetwork, --socketwayland, --socketfallback-x11, --socketpulseaudio, --deviceall, --filesystemhost, --filesystem/media, --filesystem/run/media, --filesystem/mnt ]Flatpak 默认是完全隔离的沙箱这组参数逐项放开了游戏运行所需的能力参数作用对本项目的意义--sharenetwork开放网络访问从源码结构看构建期build-args也用了--sharenetwork以便从 git 拉取 N64Recomp 子模块--socketwayland/--socketfallback-x11Wayland 优先X11 兜底RT64 渲染引擎基于 SDL2 窗口Linux 分支使用RT64_SDL_WINDOW_VULKAN见 CMakeLists.txt必须有显示协议通道--socketpulseaudio音频输出游戏通过 SDL 音频子系统以 48kHz 采样率初始化src/main/main.cpp 中SDL_InitSubSystem(SDL_INIT_AUDIO); reset_audio(48000);--deviceall访问全部设备节点需要访问/dev/input/*等以支持手柄metainfo 中声明了 gamepad 支持--filesystemhost可访问宿主机全部路径允许用户在任意位置存放 ROM 文件--filesystem/media、--filesystem/run/media、--filesystem/mnt可读写可移动存储覆盖 U 盘、SD 卡等挂载点方便从外部介质读取 ROMModule 与构建步骤manifest 只有一个 moduleZelda64Recompiled采用buildsystem: simple——即不套 meson/autotools 等标准构建系统而是按build-commands数组原样执行脚本。命令可分为三个阶段阶段一构建并运行重编译器生成 C 代码cmake -DCMAKE_BUILD_TYPERelease -DCMAKE_CXX_COMPILERclang -DCMAKE_C_COMPILERclang \ -DCMAKE_MAKE_PROGRAMninja -G Ninja -S lib/N64Recomp -B lib/N64Recomp/cmake-build cmake --build lib/N64Recomp/cmake-build --config Release --target N64Recomp --parallel cmake --build lib/N64Recomp/cmake-build --config Release --target RSPRecomp --parallel cp lib/N64Recomp/cmake-build/N64Recomp N64Recomp cp lib/N64Recomp/cmake-build/RSPRecomp RSPRecomp ./N64Recomp us.rev1.toml ./RSPRecomp aspMain.us.rev1.toml ./RSPRecomp njpgdspMain.us.rev1.toml这段与 BUILDING.md 第 4 节的本地流程完全对应先编译出N64RecompCPU 重编译器与RSPRecomp协处理器 DSP 重编译器再用仓库根目录的三个配置文件 us.rev1.toml、aspMain.us.rev1.toml、njpgdspMain.us.rev1.toml 作为输入把《Majoras Mask》US rev1 的主程序与两块 DSP 固件静态重编译为 C 源码输出到RecompiledFuncs/、rsp/目录供后续 CMake 编译进可执行文件。阶段二以 RECOMP_FLATPAK 开关构建主程序cmake -DCMAKE_BUILD_TYPERelease -DCMAKE_CXX_COMPILERclang -DCMAKE_C_COMPILERclang \ -DCMAKE_MAKE_PROGRAMninja -DPATCHES_C_COMPILERclang -DPATCHES_LDld.lld \ -DRECOMP_FLATPAKON -G Ninja -S . -B cmake-build cmake --build cmake-build --config Release --target Zelda64Recompiled --parallel这里-DRECOMP_FLATPAKON是关键差异项。对照 CMakeLists.txtif (CMAKE_SYSTEM_NAME MATCHES Linux) option(RECOMP_FLATPAK Configure the build for Flatpak compatibility. OFF) endif() if (RECOMP_FLATPAK) add_compile_definitions(RECOMP_FLATPAK) endif()该选项仅在 Linux 下存在开启后向整个工程注入RECOMP_FLATPAK编译宏。宏在源码中的两处消费src/main/support.cpp 的get_program_path()std::filesystem::path get_program_path() { #if defined(__APPLE__) return get_bundle_resource_directory(); #elif defined(__linux__) defined(RECOMP_FLATPAK) return /app/bin; #else return ; #endif }Flatpak 应用的可执行文件被安装到/app/bin因此资源基路径固定为/app/binget_asset_path()在其后拼接assets/文件。这也解释了 manifest 中为何要把assets/整目录拷到/app/bin/assets。src/main/main.cpp 的启动逻辑#if defined(__linux__) defined(RECOMP_FLATPAK) // When using Flatpak, applications tend to launch from the home directory by default. // Mods might use the current working directory to store the data, so we switch it to a directory // with persistent data storage and write permissions under Flatpak to ensure it works. std::error_code ec; std::filesystem::current_path(/var/data, ec); #endifFlatpak 启动时工作目录默认落在 home而沙箱中/var/data是官方保证的持久化数据目录跨版本升级保留这里主动把 CWD 切过去是为了让依赖“当前工作目录”存放数据的 Mod 在升级后数据不丢失。另外构建期的build-options把 llvm18 扩展的路径接入沙箱build-options: { append-path: /usr/lib/sdk/llvm18/bin, prepend-ld-library-path: /usr/lib/sdk/llvm18/lib, build-args: [ --sharenetwork ] }其中--sharenetwork允许构建沙箱联网拉取sources中的 git 依赖——N64Recomp按 commit989a86b...固定检出到lib/N64Recompmanifest 内dest字段指定另一个 source{type: dir, path: ../}则把仓库根目录整体灌入构建环境所以 build-commands 里能直接引用us.rev1.toml、patches/等文件。阶段三安装到 /apprm -rf assets/scss mkdir -p /app/bin cp cmake-build/Zelda64Recompiled /app/bin/Zelda64Recompiled cp recompcontrollerdb.txt /app/bin/recompcontrollerdb.txt cp -R assets /app/bin/assets install -Dm644 icons/512.png /app/share/icons/hicolor/512x512/apps/${FLATPAK_ID}.png install -Dm644 flatpak/io.github.zelda64recomp.zelda64recomp.metainfo.xml /app/share/metainfo/${FLATPAK_ID}.metainfo.xml install -Dm644 flatpak/io.github.zelda64recomp.zelda64recomp.desktop /app/share/applications/${FLATPAK_ID}.desktop逐条对应 Flatpak 的目录规范/app/bin放二进制、controllerdb 与assets与源码中get_program_path()返回值互相印证/app/share/icons、/app/share/metainfo、/app/share/applications分别放置图标、软件中心元数据与桌面项。注意rm -rf assets/scss先移除了 SCSS 源码——它们只是开发期构建recomp.rcss的中间产物运行时只消费编译好的 CSS。执行构建flatpak-builderflatpak/README.md 给出的构建命令为flatpak-builder --force-clean --user --install-deps-fromflathub --reporepo --install builddir io.github.zelda64recomp.zelda64recomp.json参数逐一说明路径相对于flatpak/目录所在仓库布局运行--force-clean每次构建前清空builddir状态保证可重复构建--user在用户级 Flatpak 仓库中安装 SDK 依赖无需 root--install-deps-fromflathub直接从 Flathub 仓库安装 runtime/SDK 依赖省去手动flatpak install--reporepo把构建产物写入本地仓库repo/后续 bundle 命令的输入--install构建完成后直接装进本机builddir构建状态目录。生成可分发 Bundleflatpak build-bundle构建成功后README 的最后一条命令把本地repo/打包成单文件 bundleflatpak build-bundle repo io.github.zelda64recomp.zelda64recomp.flatpak io.github.zelda64recomp.zelda64recomp --runtime-repohttps://flathub.org/repo/flathub.flatpakrepo--runtime-repo参数会在 bundle 内嵌 Flathub 运行时仓库地址用户通过flatpak install安装该.flatpak文件时会自动从 Flathub 拉取org.freedesktop.Platform 23.08运行时无需额外配置仓库来源。产物io.github.zelda64recomp.zelda64recomp.flatpak即可随发行版附带分发。桌面项与元数据bundle 内嵌的两个元数据文件决定了应用在游戏库/软件中心中的呈现flatpak/io.github.zelda64recomp.zelda64recomp.desktopExec/app/bin/Zelda64Recompiled、CategoriesGame;并注册了自定义 URI schemex-scheme-handler/zelda64recomp从源码结构看这为通过链接打开特定存档/配置预留了入口flatpak/io.github.zelda64recomp.zelda64recomp.metainfo.xml声明许可证为GPL-3.0、支持 pointing/keyboard/touch/gamepad 四种输入设备描述中明确指出“需要原版游戏才能运行本项目”the original game is required这与 BUILDING.md 中要求提供 US 版解压 ROMsha1:d6133ace5afaa0882cf214cf88daba39e266c078文件名为mm.us.rev1.rom_uncompressed.z64的前提一致。小结完整工作流把 README 与 manifest 串起来Zelda64Recomp 的 Flatpak 发行流水线是宿主机侧make -C patches CCclang LDld.lld预编译 MIPS patches沙箱 LLVM 扩展无 MIPS 后端此步不可省构建侧flatpak-builder --force-clean --user --install-deps-fromflathub --reporepo --install builddir manifest沙箱内完成 N64Recomp/RSPRecomp 构建 → 重编译 ROM 与 DSP 固件 →RECOMP_FLATPAKON构建主程序 → 安装至/app发行侧flatpak build-bundle --runtime-repo...生成自含运行时来源声明的单文件 bundle。源码层面对应的两处 Flatpak 特化/app/bin资源路径、/var/data工作目录切换保证了打包后的应用在资源查找与 Mod 数据持久化上与桌面规范对齐。整套方案的前提是构建机为 Linux、已安装 Clang/LLD含 MIPS 目标与 flatpak-builder且已按 BUILDING.md 准备好 US rev1 的解压 ROM。【免费下载链接】Zelda64RecompStatic recompilation of Majoras Mask (and soon Ocarina of Time) for PC (Windows/Linux/Mac)项目地址: https://gitcode.com/GitHub_Trending/ze/Zelda64Recomp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考