nixpkgs 中的 haredo 构建钩子为 Hare 项目接管 build / check / install 三个阶段【免费下载链接】nixpkgsNix Packages collection NixOS项目地址: https://gitcode.com/GitHub_Trending/ni/nixpkgs本文围绕 nixpkgs 的haredosetup hook文档见 doc/hooks/haredo.section.md展开讲解它如何用haredo这个 Unix 风格构建工具自动接管 stdenv 的buildPhase、checkPhase与installPhase覆盖haredoBuildTargets、haredoCheckTargets、haredoInstallTargets、dontUseHaredoBuild/Check/Install等全部配置项。读完本文你将能够把任意使用*.do构建脚本的 Hare 项目封装成 nixpkgs 包往往只需几行 Nix 代码理解三个阶段各自如何探测目标、如何并行并在需要时精确关闭或定制其中任何一个阶段。haredo 与这个 hook 是什么haredo是 Hare 生态中一个“简单且符合 Unix 惯例”的构建自动化工具它读取项目里的*.do脚本例如build.do、test.do、install.do按目标名执行相应的构建步骤。nixpkgs 中它的定义见 pkgs/by-name/ha/haredo/package.nix当前收录版本为 1.0.6WTFPL 许可outputs [ out man ]并从 Sourcehut 拉取源码、附带 man 页通过scdoc生成。而本文主角是与它同目录的 setup hook —— pkgs/by-name/ha/haredo/setup-hook.sh。只要把haredo放进某个包的nativeBuildInputsstdenv 的 setup 机制就会在构建沙箱里自动 source 这个钩子钩子随后在用户没有自定义对应阶段的前提下把三个阶段替换为原 stdenv 阶段被替换为行为buildPhaseharedoBuildPhase构建默认目标checkPhaseharedoCheckPhase寻找并运行check.do/test.do目标installPhaseharedoInstallPhase构建install目标阶段替换的条件写在钩子末尾setup-hook.sh#L59-L69if [[ -z ${dontUseHaredoBuild-} -z ${buildPhase-} ]]; then buildPhaseharedoBuildPhase fi也就是说只有当对应的dontUseHaredo*变量未设置、且用户没有自己写buildPhase/checkPhase/installPhase时hook 才生效。这一优先级设计意味着你在 package.nix 里手写任一阶段就会自动“压过”钩子的默认行为而不必显式关闭。buildPhase构建默认目标haredoBuildPhasesetup-hook.sh#L1-L13的完整实现只有几行haredoBuildPhase() { runHook preBuild local buildTargets jobs read -ra buildTargets ${haredoBuildTargets-} echoCmd haredo build targets ${buildTargets[]} if [[ ! -v enableParallelBuilding || -n ${enableParallelBuilding-} ]]; then jobs${NIX_BUILD_CORES} fi haredo ${jobs:-j${jobs}} ${buildTargets[]} runHook postBuild }要点逐条说明默认目标不传任何目标时haredo build会构建项目的默认目标Hare 约定即build.do里定义的默认 target。haredoBuildTargets文档说明“可通过向haredoBuildTargets列表添加字符串来显式指定目标”。实现上它把该字符串按空格切分成多个目标传给haredo例如haredoBuildTargets core extra;会构建两个目标。dontUseHaredoBuild true关闭该阶段的 hook 接管回到 stdenv 默认空buildPhase或配合你自己的buildPhase使用。前后钩子runHook preBuild/runHook postBuild保证 stdenv 中preBuild、postBuild等通用变量在接管后依然可用行为与常规buildPhase一致。checkPhase自动发现 check.do / test.doharedoCheckPhasesetup-hook.sh#L15-L43比 build 阶段更“聪明”它的目标发现逻辑是if [[ -n ${haredoCheckTargets:-} ]]; then read -ra checkTargets ${haredoCheckTargets} else for dofile in check.do test.do; do [[ -r ${dofile} ]] { checkTargets(${dofile%.do}) break } done fi if [[ -z ${checkTargets:-} ]]; then printf -- haredoCheckPhase ERROR: no check targets were found 12 exit 1对应三条可验证的行为显式优先设置了haredoCheckTargets就直接按该列表执行自动发现否则按check.do→test.do的顺序探测源树中可读的 do 文件命中哪个就用哪个check.do优先找不到即失败两个文件都不存在、又没有显式目标时钩子直接打印haredoCheckPhase ERROR: no check targets were found并exit 1。因此如果你的包确实没有测试可跑应设置dontUseHaredoCheck true或doCheck false而不是任由阶段报错。同样地dontUseHaredoCheck true会跳过整个接管并行则由enableParallelChecking控制见下文。installPhase默认构建 install 目标haredoInstallPhasesetup-hook.sh#L45-L57local installTargets jobs read -ra installTargets ${haredoInstallTargets:-install}默认目标是install即使上游的 do 文件名或目标名就叫install.do这里传给haredo的也是目标名install。注意与 check 阶段不同它不自动探测install.do只按“目标存在才成功”的语义交给haredo去执行文档表述为“尝试构建install.do目标若存在”。haredoInstallTargets显式指定安装目标列表空格分隔。dontUseHaredoInstall true关闭接管便于手写installPhase做自定义安装比如额外拷贝 man 页、做 wrapper。由于 do 脚本通常使用PREFIX决定安装位置包定义里需要把PREFIX指到 Nix 输出目录典型写法是env.PREFIX placeholder out;见 pkgs/by-name/tr/treecat/package.nix 与 haredo 自身 package.nix#L43。并行构建-j$NIX_BUILD_CORES从何而来文档说“若enableParallelBuilding为true钩子会并行构建目标”。对照源码三个阶段分别读取各自的开关逻辑完全一致# build 阶段 if [[ ! -v enableParallelBuilding || -n ${enableParallelBuilding-} ]]; then jobs${NIX_BUILD_CORES} fi haredo ${jobs:-j${jobs}} ${buildTargets[]}check 阶段读enableParallelCheckingL36-L39install 阶段读enableParallelInstallingL51-L53。当开关“视为开启”时就附加-j${NIX_BUILD_CORES}让haredo用构建机可用的核心数并行执行 do 脚本内的步骤开关关闭时不加该参数退回顺序执行。从源码结构看这三个变量与 pkgs/stdenv/generic/make-derivation.nix 中的 stdenv 选项联动enableParallelBuilding为真时会连带把enableParallelChecking、enableParallelInstalling一并置真make-derivation.nix#L756-L759而 Linux 平台的 stdenv 默认enableParallelBuilding truepkgs/stdenv/linux/default.nix#L501。因此在 nixpkgs 的 Linux 构建环境下使用 haredo hook 的包默认就是并行构建/检查/安装的要恢复串行把对应的enableParallel*选项设为false即可。与 hareHook 的配套关系haredo只是“执行 do 脚本的人”真正干活的是 Hare 编译器链。所以实际打包时nativeBuildInputs通常同时包含hareHook和haredo。看 pkgs/by-name/ha/hare/hook.nix 中的注释hook.nix#L40-L51makeSetupHook { name hare-hook; # The propagation of qbe and harec ... is needed for # build frameworks like haredo, which set the HAREC and QBE env vars # to harec and qbe respectively. propagatedBuildInputs [ hareWrapper ] harePropagationInputs; substitutions { hare_unconditional_flags -q -a${arch}; hare_stdlib ${hare}/src/hare/stdlib; }; ... }也就是说hareHook会把hare、harec、qbe传播进包的构建环境——这正是haredo运行 do 脚本时所需的编译器路径同时它注入NIX_HAREFLAGS-q -a${arch}与标准库路径。hare还被包了一层 wrapperhook.nix#L13-L28对test/run/build子命令自动附加这些标志。平台兼容性方面两个包的meta.platforms/badPlatforms都直接继承自hareHook.meta见 haredo 的 package.nix#L87可以理解为 haredo 系包只在 Hare 工具链支持的平台上有意义。一个值得注意的自举细节haredo自身并不使用这个 hook 构建自己它是“造钩子”的那一方而是直接hare build -o bin/haredo ./src并scdoc生成 man 页package.nix#L49-L56同时打了一个补丁 001-use-nix-store-sh.patch把 haredo 执行 do 脚本时的sh替换为 Nix store 中的 bash以/bin/sh身份提供因为 haredo 期望一个 POSIX shell。这解释了为什么它的nativeBuildInputs里有hareHook和makeWrapper。实战几行 Nix 代码打包一个 haredo 项目nixpkgs 里的treecat“把目录序列化为树形图并可还原”是这套钩子最精简的用法示例stdenv.mkDerivation (finalAttrs: { pname treecat; version 1.0.3; outputs [ out man ]; src fetchFromSourcehut { owner ~autumnull; repo treecat; tag finalAttrs.version; hash sha256-UCGx1vAP9BeAktrniTXctkPp5mprf77fkapdhPWrqg; }; nativeBuildInputs [ hareHook haredo scdoc ]; env.PREFIX placeholder out; dontConfigure true; meta { description Serialize a directory to a tree diagram, and vice versa; license lib.licenses.wtfpl; ... }; })对照前文的机制可以逐项读出它的含义没有写任何buildPhase/checkPhase/installPhase—— 三个阶段全部由 hook 接管build 走默认目标check 自动发现上游的check.do/test.doinstall 执行install目标hareHook haredo scdoc构成完整工具链scdoc用于生成 man 页对应man输出env.PREFIX placeholder out让 do 脚本里的安装步骤写入$outdontConfigure true跳过 stdenv 默认的 configure 阶段因为 haredo 项目没有 configure 概念。如果你的项目结构更特殊可按需叠加这些变量均通过 stdenv 的finalAttrs直接传入即可# 显式目标列表空格分隔字符串 haredoBuildTargets mybin lib; haredoCheckTargets check; haredoInstallTargets install install-dev; # 关闭某阶段的接管之后可自行定义对应 Phase dontUseHaredoCheck true; # 恢复串行执行 enableParallelBuilding false; enableParallelChecking false; enableParallelInstalling false;小结haredosetup hook 是 nixpkgs 里 stdenv 钩子机制的一个典型样本用一份约 70 行的 shell 钩子pkgs/by-name/ha/haredo/setup-hook.sh把haredo的“do 脚本 目标名”模型完整映射到 stdenv 三阶段同时保留了preBuild/postCheck等 stdenv 惯例、与enableParallel*并行开关的联动以及“用户自定义 Phase 优先、dontUse*可逃生”的优先级规则。对于维护 Hare 生态包的人来说记住一张速查表即可变量作用默认行为haredoBuildTargets显式构建目标构建默认目标haredoCheckTargets显式检查目标按check.do→test.do自动发现找不到则exit 1haredoInstallTargets显式安装目标执行install目标dontUseHaredoBuild/dontUseHaredoCheck/dontUseHaredoInstall分别关闭三阶段接管未设置则接管生效且用户自定义 Phase 优先enableParallelBuilding/Checking/Installing分别为三阶段附加-j$NIX_BUILD_CORESLinux stdenv 下默认全部并行【免费下载链接】nixpkgsNix Packages collection NixOS项目地址: https://gitcode.com/GitHub_Trending/ni/nixpkgs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
nixpkgs 中的 haredo 构建钩子为 Hare 项目接管 build / check / install 三个阶段【免费下载链接】nixpkgsNix Packages collection NixOS项目地址: https://gitcode.com/GitHub_Trending/ni/nixpkgs本文围绕 nixpkgs 的haredosetup hook文档见 doc/hooks/haredo.section.md展开讲解它如何用haredo这个 Unix 风格构建工具自动接管 stdenv 的buildPhase、checkPhase与installPhase覆盖haredoBuildTargets、haredoCheckTargets、haredoInstallTargets、dontUseHaredoBuild/Check/Install等全部配置项。读完本文你将能够把任意使用*.do构建脚本的 Hare 项目封装成 nixpkgs 包往往只需几行 Nix 代码理解三个阶段各自如何探测目标、如何并行并在需要时精确关闭或定制其中任何一个阶段。haredo 与这个 hook 是什么haredo是 Hare 生态中一个“简单且符合 Unix 惯例”的构建自动化工具它读取项目里的*.do脚本例如build.do、test.do、install.do按目标名执行相应的构建步骤。nixpkgs 中它的定义见 pkgs/by-name/ha/haredo/package.nix当前收录版本为 1.0.6WTFPL 许可outputs [ out man ]并从 Sourcehut 拉取源码、附带 man 页通过scdoc生成。而本文主角是与它同目录的 setup hook —— pkgs/by-name/ha/haredo/setup-hook.sh。只要把haredo放进某个包的nativeBuildInputsstdenv 的 setup 机制就会在构建沙箱里自动 source 这个钩子钩子随后在用户没有自定义对应阶段的前提下把三个阶段替换为原 stdenv 阶段被替换为行为buildPhaseharedoBuildPhase构建默认目标checkPhaseharedoCheckPhase寻找并运行check.do/test.do目标installPhaseharedoInstallPhase构建install目标阶段替换的条件写在钩子末尾setup-hook.sh#L59-L69if [[ -z ${dontUseHaredoBuild-} -z ${buildPhase-} ]]; then buildPhaseharedoBuildPhase fi也就是说只有当对应的dontUseHaredo*变量未设置、且用户没有自己写buildPhase/checkPhase/installPhase时hook 才生效。这一优先级设计意味着你在 package.nix 里手写任一阶段就会自动“压过”钩子的默认行为而不必显式关闭。buildPhase构建默认目标haredoBuildPhasesetup-hook.sh#L1-L13的完整实现只有几行haredoBuildPhase() { runHook preBuild local buildTargets jobs read -ra buildTargets ${haredoBuildTargets-} echoCmd haredo build targets ${buildTargets[]} if [[ ! -v enableParallelBuilding || -n ${enableParallelBuilding-} ]]; then jobs${NIX_BUILD_CORES} fi haredo ${jobs:-j${jobs}} ${buildTargets[]} runHook postBuild }要点逐条说明默认目标不传任何目标时haredo build会构建项目的默认目标Hare 约定即build.do里定义的默认 target。haredoBuildTargets文档说明“可通过向haredoBuildTargets列表添加字符串来显式指定目标”。实现上它把该字符串按空格切分成多个目标传给haredo例如haredoBuildTargets core extra;会构建两个目标。dontUseHaredoBuild true关闭该阶段的 hook 接管回到 stdenv 默认空buildPhase或配合你自己的buildPhase使用。前后钩子runHook preBuild/runHook postBuild保证 stdenv 中preBuild、postBuild等通用变量在接管后依然可用行为与常规buildPhase一致。checkPhase自动发现 check.do / test.doharedoCheckPhasesetup-hook.sh#L15-L43比 build 阶段更“聪明”它的目标发现逻辑是if [[ -n ${haredoCheckTargets:-} ]]; then read -ra checkTargets ${haredoCheckTargets} else for dofile in check.do test.do; do [[ -r ${dofile} ]] { checkTargets(${dofile%.do}) break } done fi if [[ -z ${checkTargets:-} ]]; then printf -- haredoCheckPhase ERROR: no check targets were found 12 exit 1对应三条可验证的行为显式优先设置了haredoCheckTargets就直接按该列表执行自动发现否则按check.do→test.do的顺序探测源树中可读的 do 文件命中哪个就用哪个check.do优先找不到即失败两个文件都不存在、又没有显式目标时钩子直接打印haredoCheckPhase ERROR: no check targets were found并exit 1。因此如果你的包确实没有测试可跑应设置dontUseHaredoCheck true或doCheck false而不是任由阶段报错。同样地dontUseHaredoCheck true会跳过整个接管并行则由enableParallelChecking控制见下文。installPhase默认构建 install 目标haredoInstallPhasesetup-hook.sh#L45-L57local installTargets jobs read -ra installTargets ${haredoInstallTargets:-install}默认目标是install即使上游的 do 文件名或目标名就叫install.do这里传给haredo的也是目标名install。注意与 check 阶段不同它不自动探测install.do只按“目标存在才成功”的语义交给haredo去执行文档表述为“尝试构建install.do目标若存在”。haredoInstallTargets显式指定安装目标列表空格分隔。dontUseHaredoInstall true关闭接管便于手写installPhase做自定义安装比如额外拷贝 man 页、做 wrapper。由于 do 脚本通常使用PREFIX决定安装位置包定义里需要把PREFIX指到 Nix 输出目录典型写法是env.PREFIX placeholder out;见 pkgs/by-name/tr/treecat/package.nix 与 haredo 自身 package.nix#L43。并行构建-j$NIX_BUILD_CORES从何而来文档说“若enableParallelBuilding为true钩子会并行构建目标”。对照源码三个阶段分别读取各自的开关逻辑完全一致# build 阶段 if [[ ! -v enableParallelBuilding || -n ${enableParallelBuilding-} ]]; then jobs${NIX_BUILD_CORES} fi haredo ${jobs:-j${jobs}} ${buildTargets[]}check 阶段读enableParallelCheckingL36-L39install 阶段读enableParallelInstallingL51-L53。当开关“视为开启”时就附加-j${NIX_BUILD_CORES}让haredo用构建机可用的核心数并行执行 do 脚本内的步骤开关关闭时不加该参数退回顺序执行。从源码结构看这三个变量与 pkgs/stdenv/generic/make-derivation.nix 中的 stdenv 选项联动enableParallelBuilding为真时会连带把enableParallelChecking、enableParallelInstalling一并置真make-derivation.nix#L756-L759而 Linux 平台的 stdenv 默认enableParallelBuilding truepkgs/stdenv/linux/default.nix#L501。因此在 nixpkgs 的 Linux 构建环境下使用 haredo hook 的包默认就是并行构建/检查/安装的要恢复串行把对应的enableParallel*选项设为false即可。与 hareHook 的配套关系haredo只是“执行 do 脚本的人”真正干活的是 Hare 编译器链。所以实际打包时nativeBuildInputs通常同时包含hareHook和haredo。看 pkgs/by-name/ha/hare/hook.nix 中的注释hook.nix#L40-L51makeSetupHook { name hare-hook; # The propagation of qbe and harec ... is needed for # build frameworks like haredo, which set the HAREC and QBE env vars # to harec and qbe respectively. propagatedBuildInputs [ hareWrapper ] harePropagationInputs; substitutions { hare_unconditional_flags -q -a${arch}; hare_stdlib ${hare}/src/hare/stdlib; }; ... }也就是说hareHook会把hare、harec、qbe传播进包的构建环境——这正是haredo运行 do 脚本时所需的编译器路径同时它注入NIX_HAREFLAGS-q -a${arch}与标准库路径。hare还被包了一层 wrapperhook.nix#L13-L28对test/run/build子命令自动附加这些标志。平台兼容性方面两个包的meta.platforms/badPlatforms都直接继承自hareHook.meta见 haredo 的 package.nix#L87可以理解为 haredo 系包只在 Hare 工具链支持的平台上有意义。一个值得注意的自举细节haredo自身并不使用这个 hook 构建自己它是“造钩子”的那一方而是直接hare build -o bin/haredo ./src并scdoc生成 man 页package.nix#L49-L56同时打了一个补丁 001-use-nix-store-sh.patch把 haredo 执行 do 脚本时的sh替换为 Nix store 中的 bash以/bin/sh身份提供因为 haredo 期望一个 POSIX shell。这解释了为什么它的nativeBuildInputs里有hareHook和makeWrapper。实战几行 Nix 代码打包一个 haredo 项目nixpkgs 里的treecat“把目录序列化为树形图并可还原”是这套钩子最精简的用法示例stdenv.mkDerivation (finalAttrs: { pname treecat; version 1.0.3; outputs [ out man ]; src fetchFromSourcehut { owner ~autumnull; repo treecat; tag finalAttrs.version; hash sha256-UCGx1vAP9BeAktrniTXctkPp5mprf77fkapdhPWrqg; }; nativeBuildInputs [ hareHook haredo scdoc ]; env.PREFIX placeholder out; dontConfigure true; meta { description Serialize a directory to a tree diagram, and vice versa; license lib.licenses.wtfpl; ... }; })对照前文的机制可以逐项读出它的含义没有写任何buildPhase/checkPhase/installPhase—— 三个阶段全部由 hook 接管build 走默认目标check 自动发现上游的check.do/test.doinstall 执行install目标hareHook haredo scdoc构成完整工具链scdoc用于生成 man 页对应man输出env.PREFIX placeholder out让 do 脚本里的安装步骤写入$outdontConfigure true跳过 stdenv 默认的 configure 阶段因为 haredo 项目没有 configure 概念。如果你的项目结构更特殊可按需叠加这些变量均通过 stdenv 的finalAttrs直接传入即可# 显式目标列表空格分隔字符串 haredoBuildTargets mybin lib; haredoCheckTargets check; haredoInstallTargets install install-dev; # 关闭某阶段的接管之后可自行定义对应 Phase dontUseHaredoCheck true; # 恢复串行执行 enableParallelBuilding false; enableParallelChecking false; enableParallelInstalling false;小结haredosetup hook 是 nixpkgs 里 stdenv 钩子机制的一个典型样本用一份约 70 行的 shell 钩子pkgs/by-name/ha/haredo/setup-hook.sh把haredo的“do 脚本 目标名”模型完整映射到 stdenv 三阶段同时保留了preBuild/postCheck等 stdenv 惯例、与enableParallel*并行开关的联动以及“用户自定义 Phase 优先、dontUse*可逃生”的优先级规则。对于维护 Hare 生态包的人来说记住一张速查表即可变量作用默认行为haredoBuildTargets显式构建目标构建默认目标haredoCheckTargets显式检查目标按check.do→test.do自动发现找不到则exit 1haredoInstallTargets显式安装目标执行install目标dontUseHaredoBuild/dontUseHaredoCheck/dontUseHaredoInstall分别关闭三阶段接管未设置则接管生效且用户自定义 Phase 优先enableParallelBuilding/Checking/Installing分别为三阶段附加-j$NIX_BUILD_CORESLinux stdenv 下默认全部并行【免费下载链接】nixpkgsNix Packages collection NixOS项目地址: https://gitcode.com/GitHub_Trending/ni/nixpkgs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
