资讯详情

Lapce 如何用 docker buildx bake 按目标版本构建 Linux 发布包并交叉编译多架构?

📅 2026/9/12 11:11:49 | 华诺云谱 👁 阅读
Lapce 如何用 docker buildx bake 按目标版本构建 Linux 发布包并交叉编译多架构?
Lapce 如何用 docker buildx bake 按目标版本构建 Linux 发布包并交叉编译多架构【免费下载链接】lapceLightning-fast and Powerful Code Editor written in Rust项目地址: https://gitcode.com/GitHub_Trending/la/lapce如果你需要在本地为 Lapce 构建 Linux 发布包deb / rpm / 静态二进制并且一次构建同时产出linux/amd64与linux/arm64两种架构的产物仓库提供了完整的构建编排方案根目录的 docker-bake.hcl 定义了所有构建阶段与目标配合docker buildx bake驱动各发行版的多阶段 Dockerfile位于 extra/linux/docker/。docs/building-from-source.md 的 “Building using Docker or Podman” 一节说明发布页面上的软件包就是通过这些容器构建出来的并且该流程同时支持 Docker 与 Podman。构建环境与必备变量开始之前需要满足以下条件本地已安装 Docker或 Podman并可用buildx子命令已检出 Lapce 仓库源码docker-bake.hcl位于仓库根目录bake 文件的context .即以仓库根为构建上下文见 docker-bake.hcl必须设置环境变量RELEASE_TAG_NAME。它是 bake 文件中无默认值的必填变量docker-bake.hcl文档原文说明它 “used to tell what kind of release is being built as well as baking in the version itself”。RELEASE_TAG_NAME的取值会被各 Dockerfile 内的版本处理逻辑解析以 ubuntu Dockerfile 为例nightly-commit包版本为lapce版本号commitdebug或nightly包版本为lapce版本号日期时间其他值如版本 tag去掉前导v后作为包版本。另外bake 文件根据该变量决定包名RELEASE_TAG_NAME nightly时PACKAGE_NAME为lapce-nightly否则为lapce见 docker-bake.hcl构建出的 deb 中两个包会互相声明Conflicts避免正式包与 nightly 包同时安装。bake 文件把构建分成两类目标构建参数不同docker-bake.hclbinary目标静态链接产物设置LIBGIT2_STATIC1、OPENSSL_STATIC1、PKG_CONFIG_ALL_STATIC1等 build argspackage目标产物依赖发行版系统库OPENSSL_NO_VENDOR1、各静态开关为0deb 的依赖通过 Dockerfile 内dpkg-shlibdeps计算rpm 通过rpmbuild生成。按目标发行版版本构建发布包bake 文件通过 matrix 为每个发行版展开多个具体版本目标目标名形如${os_name}-${版本}-${类型}。matrix 覆盖的版本docker-bake.hcl发行版matrix 中的版本构建类型ubuntubionic (18.04)、focal (20.04)、jammy (22.04)、noble (24.04)、oracular (24.10)、plucky (25.04)focal 额外含一个 static binary 构建packagefocal 另有 binarydebianbullseye (11)、bookworm (12)packagefedora39、40、41、42、43、rawhidepackage且 platforms 固定为linux/amd64alpine空值latest、3.22、3.20、3.18binary静态链接要构建单个目标版本文档给出的命令是按 matrix 中的版本名指定目标例如只构建 Ubuntu Focal 的软件包RELEASE_TAG_NAMEnightly docker buildx bake ubuntu-focal要构建某个发行版的全部版本直接使用发行版名RELEASE_TAG_NAMEnightly docker buildx bake ubuntu注意文档中的警告不要在没有非常强力机器的情况下运行ubuntu、fedora这类裸目标因为 matrix 会同时启动大量并发构建任务耗时很长docs/building-from-source.md。机器资源有限时优先按ubuntu-focal这类单版本目标逐个构建。bake 文件的defaultgroup 指向binary目标platforms [local]docker-bake.hcl即不带目标名时构建的是本机架构的静态二进制而不是发行版软件包。交叉编译多架构amd64 / arm64bake 文件中platforms变量的默认值是[linux/amd64, linux/arm64]docker-bake.hcl每个发行版目标通过inherits引入_platforms或对应的cross-*目标如 cross-ubuntu、cross-debian、cross-alpine因此 Docker 构建会同时交叉编译 Lapce 到其他架构。文档强调这一点不需要安装 QEMU这是真正的交叉编译HOST运行在你本机原生操作系统/ CPU 架构上TARGET才是目标架构而不是启动一个运行目标架构操作系统的模拟容器。具体实现见各 Dockerfile构建阶段在--platform$BUILDPLATFORM的基础镜像上安装 tonistiigi/xx 工具链用xx-clang、xx-cargo完成目标 triple 的编译如 ubuntu Dockerfile 的 build 阶段所以docker buildx bake ubuntu-focal这类命令本身就同时产出两种架构的产物。确认构建结果构建流水线自带产物校验每个 Dockerfile 在打包之前都会对新编译出的二进制执行xx-verify例如 ubuntu Dockerfile 中的xx-verify ${CARGO_TARGET_DIR}/$(xx-cargo --print-target-triple)/release-lto/lapce如果校验不通过该 RUN 阶段会失败后续打包阶段不会执行构建即视为失败。产物命名也可用于核对结果。deb 包按以下模式输出ubuntu Dockerfiledpkg-deb --root-owner-group --build . ${OUTPUT_DIR}/${PACKAGE_NAME}.${ID}.${VERSION_CODENAME}.${_PACKAGE_ARCHITECTURE}.deb其中PACKAGE_NAME为lapce或lapce-nightlyID/VERSION_CODENAME来自容器内/etc/os-release_PACKAGE_ARCHITECTURE由xx-info debian-arch得到。按此模式Ubuntu Focal 的产物名形如lapce.ubuntu.focal.架构.deb以上为按该模式拼出的示例名具体以构建输出为准。rpm 侧则由 fedora Dockerfile 中的rpmbuild生成并收集到/output。限制与可选分支RELEASE_TAG_NAME未设置时 bake 会因缺少必填变量而失败所有 bake 命令都应带上它fedora 目标在 bake 文件中将platforms写死为[linux/amd64]docker-bake.hcl因此 fedora 产物只有 amd64 架构alpine 目标继承的是binary目标产出静态链接二进制而非包docker-bake.hcl可选分支bake 文件还定义了alpine-dev目标它基于alpine-3-20构建dev阶段并以typedocker输出到本地 Docker daemon镜像 tag 为lapce/lapce:devdocker-bake.hcl适合需要开发容器而非发布产物的场景。完成单版本构建后可以按 matrix 继续构建其余目标版本发布版本号的同步维护metainfo、Cargo.toml、changelog、rpm spec 等文件见 docs/new-release.md。【免费下载链接】lapceLightning-fast and Powerful Code Editor written in Rust项目地址: https://gitcode.com/GitHub_Trending/la/lapce创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
📝

华诺云谱内容团队

资深建站顾问 · 行业研究员

10年+企业数字化服务经验,专注智能建站、SEO优化与品牌营销,持续输出建站技巧、行业洞察与营销干货,已帮助5000+企业实现数字化增长。

你可能需要的服务

订阅华诺云谱资讯周报

每周一封,精选建站技巧、SEO与营销干货,直达邮箱。已有 8,000+ 企业主订阅,助你少走弯路。