Nixpkgs 中 Jule 语言构建钩子 julec.hook 完全指南配置、变量与源码剖析【免费下载链接】nixpkgsNix Packages collection NixOS项目地址: https://gitcode.com/GitHub_Trending/ni/nixpkgs导读本文以 Nixpkgs 官方文档 doc/hooks/julec.section.md 为主体结合 hook.sh 与 hook.nix 的源码级实现完整讲解julec.hook如何在mkDerivation中接管 Jule 项目的构建build、测试check与安装install三个阶段。读完本文你将掌握全部 7 个配置变量的默认值与作用、3 个禁用开关的用法并能独立写出可复制的 Jule 打包表达式。Jule 语言与 julec.hook 的定位Jule 是一门致力于构建高效、快速、可靠且安全软件的同时保持简洁的编程语言。在 Nixpkgs 中Jule 编译器以julec为包名提供并随包附带一个名为julec.hook的构建钩子。与众多 Nixpkgs 语言钩子如 zig.section.md 中的 zig.hook、go.section.md 中的 buildGoModule类似julec.hook的作用是当把它加入nativeBuildInputs后自动覆盖mkDerivation默认的 build、check 和 install 三个 phase使开发者无需手写 phase 逻辑仅通过环境变量即可驱动 Jule 项目的标准打包流程。其实现入口位于 pkgs/by-name/ju/julec/hook.nixmakeSetupHook { name julec-hook; propagatedBuildInputs [ julec ]; ... } ./hook.sh即该钩子通过makeSetupHook将 hook.sh 包装为一个 setup hook并把编译器julec作为propagatedBuildInputs传递确保钩子脚本执行时julec命令一定在 PATH 中可用。快速上手完整的代码示例在clangStdenv.mkDerivation中接入julec.hook的最简用法如下取自官方文档示例{ julec, clangStdenv, }: clangStdenv.mkDerivation (finalAttrs: { # ... nativeBuildInputs [ julec.hook ]; # Customize filenames if needed JULE_SRC_DIR ./src; JULE_OUT_DIR ./bin; JULE_OUT_NAME hello-jule; JULE_TEST_DIR ./tests; JULE_TEST_OUT_DIR ./test-bin; JULE_TEST_OUT_NAME hello-jule-test; # ... })要点说明nativeBuildInputs [ julec.hook ];是唯一必须的设置它同时注入钩子脚本与julec编译器其余变量均为可选定制项若未设置会自动回退到默认值示例中的./src、./tests等路径均相对于mkDerivation解包后的构建目录即源码根目录。仓库自带的集成测试 pkgs/by-name/ju/julec/test/default.nix 是这一用法的真实范例它构建名为hello-jule的包源码目录中包含 main.jule打印Hello, Jule!与_test.jule测试文件并且没有显式设置任何 JULE_* 变量完全依靠钩子默认值运行同时打开doCheck true验证 check 阶段clangStdenv.mkDerivation (finalAttrs: { pname hello-jule; inherit (julec) version; src ./hello-jule; nativeBuildInputs [ julec.hook ]; doCheck true; meta { inherit (julec.meta) platforms; }; })变量详解7 个控制项及其源码默认值julec.hook的全部配置均通过环境变量完成这些变量在 hook.sh 的julecSetEnv函数中被统一处理只有变量未设置-z判断为空时才会赋予默认值因此你在 derivation 属性中写入的值会优先保留。变量作用默认值源码位置JULE_SRC_DIR包含main.jule的源码目录./srchook.sh L4-L6JULE_OUT_DIR编译产物的输出目录./binhook.sh L7-L9JULE_OUT_NAME编译产物的二进制文件名outputhook.sh L10-L12JULE_TEST_DIR包含测试文件的目录取JULE_SRC_DIR的值hook.sh L13-L15JULE_TEST_OUT_DIR测试二进制的输出目录取JULE_OUT_DIR的值hook.sh L16-L18JULE_TEST_OUT_NAME测试二进制的文件名JULE_OUT_NAME加-test后缀hook.sh L19-L21dontUseJulecBuild/dontUseJulecCheck/dontUseJulecInstall禁用对应钩子阶段false未设置即视为不禁用hook.sh L72-L79JULE_SRC_DIR源码目录指定包含main.jule的目录默认./src。它同时是构建与测试共用的源码入口——测试目录在未显式配置时直接复用该值。JULE_OUT_DIR与JULE_OUT_NAME构建产物位置与名称分别指定编译二进制的输出目录与文件名默认./bin与output。在julecBuildHook中钩子会先mkdir -p $JULE_OUT_DIR再执行编译hook.sh L30-L31julec build --opt L2 -p -o $JULE_OUT_DIR/$JULE_OUT_NAME $JULE_SRC_DIR注意这里的编译参数是源码中硬编码的--opt L2启用 L2 级别的优化-p打印print编译过程相关信息-o指定输出二进制路径。这意味着最终产物总是$JULE_OUT_DIR/$JULE_OUT_NAME路径拼接逻辑不可通过额外变量改变。JULE_TEST_DIR、JULE_TEST_OUT_DIR、JULE_TEST_OUT_NAME测试三件套三者默认值分别继承自JULE_SRC_DIR、JULE_OUT_DIR与JULE_OUT_NAMEhook.sh L13-L21。在julecCheckHook中的完整测试流程为hook.sh L38-L56执行preCheck钩子mkdir -p $JULE_TEST_OUT_DIR创建测试输出目录调用julec test -o $JULE_TEST_OUT_DIR/$JULE_TEST_OUT_NAME $JULE_TEST_DIR编译测试直接执行生成的测试二进制$JULE_TEST_OUT_DIR/$JULE_TEST_OUT_NAME运行测试执行postCheck钩子。可见 check 阶段被设计为编译 运行两步且测试文件默认与主源码同目录.jule后缀的_test.jule文件即会被julec test识别。dontUseJulecBuild、dontUseJulecCheck、dontUseJulecInstall阶段禁用开关三个开关分别控制是否使用预定义的构建、检查与安装钩子默认均为 false未设置。源码中的条件赋值逻辑hook.sh L72-L79同时兼顾了mkDerivation阶段自定义的优先级if [ -z ${dontUseJulecBuild-} ] [ -z ${buildPhase-} ]; then buildPhasejulecBuildHook fi if [ -z ${dontUseJulecCheck-} ] [ -z ${checkPhase-} ]; then checkPhasejulecCheckHook fi if [ -z ${dontUseJulecInstall-} ] [ -z ${installPhase-} ]; then installPhasejulecInstallHook fi即只有当你既没有禁用钩子、又没有自行定义对应的buildPhase/checkPhase/installPhase时默认钩子才会被启用。这一设计让开发者可以在保留其他阶段默认行为的同时灵活替换或扩展任意阶段。典型的使用场景项目需要自定义安装逻辑如安装多个二进制、资源文件时设置dontUseJulecInstall true;并自行编写installPhase。安装阶段的行为julecInstallHookhook.sh L58-L70的逻辑非常直接执行preInstall钩子mkdir -p $out/bin创建输出目录用cp -r $JULE_OUT_DIR/$JULE_OUT_NAME $out/bin/将编译产物复制到$out/bin/执行postInstall钩子。由于-r选项的存在即使产物是目录也能完整复制。这也意味着构建产物名JULE_OUT_NAME直接决定了最终安装到$out/bin下的可执行文件名是影响安装结果的关键变量。与其他 phase 钩子的协同与 Nixpkgs 中其他语言钩子一样julec.hook的三个内部函数都通过runHook preBuild/runHook postBuild等标准机制预留了扩展点hook.sh L27、L33、L41、L53、L61、L67。这意味着你可以继续使用 Nixpkgs 通用的preBuild、postInstall等属性在钩子前后插入自定义逻辑而无需推翻钩子本身。常见问题与最佳实践忘记设置JULE_SRC_DIR导致找不到 main.jule钩子默认从./src查找源码若你的项目把main.jule放在仓库根目录请显式设置JULE_SRC_DIR .;。只想构建、跳过测试不设置doCheck默认 false即可julecCheckHook只在 check 阶段被调用而 Nixpkgs 默认不执行 check 阶段。自定义构建方式设置dontUseJulecBuild true;并编写自己的buildPhase此时JULE_*变量将不再参与构建但仍可用于你自定义的脚本中因为环境变量仍会被导出。查看钩子实际行为构建时添加-v或观察日志中的Executing julecBuildHook/Executing julecCheckHook/Executing julecInstallHook输出即可确认各阶段是否按预期执行。参考资源官方文档doc/hooks/julec.section.md钩子脚本实现pkgs/by-name/ju/julec/hook.sh钩子 Nix 封装pkgs/by-name/ju/julec/hook.nix集成测试pkgs/by-name/ju/julec/test/default.nix、测试源码目录同目录文档参考doc/hooks/index.md【免费下载链接】nixpkgsNix Packages collection NixOS项目地址: https://gitcode.com/GitHub_Trending/ni/nixpkgs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Nixpkgs 中 Jule 语言构建钩子 julec.hook 完全指南：配置、变量与源码剖析
Nixpkgs 中 Jule 语言构建钩子 julec.hook 完全指南配置、变量与源码剖析【免费下载链接】nixpkgsNix Packages collection NixOS项目地址: https://gitcode.com/GitHub_Trending/ni/nixpkgs导读本文以 Nixpkgs 官方文档 doc/hooks/julec.section.md 为主体结合 hook.sh 与 hook.nix 的源码级实现完整讲解julec.hook如何在mkDerivation中接管 Jule 项目的构建build、测试check与安装install三个阶段。读完本文你将掌握全部 7 个配置变量的默认值与作用、3 个禁用开关的用法并能独立写出可复制的 Jule 打包表达式。Jule 语言与 julec.hook 的定位Jule 是一门致力于构建高效、快速、可靠且安全软件的同时保持简洁的编程语言。在 Nixpkgs 中Jule 编译器以julec为包名提供并随包附带一个名为julec.hook的构建钩子。与众多 Nixpkgs 语言钩子如 zig.section.md 中的 zig.hook、go.section.md 中的 buildGoModule类似julec.hook的作用是当把它加入nativeBuildInputs后自动覆盖mkDerivation默认的 build、check 和 install 三个 phase使开发者无需手写 phase 逻辑仅通过环境变量即可驱动 Jule 项目的标准打包流程。其实现入口位于 pkgs/by-name/ju/julec/hook.nixmakeSetupHook { name julec-hook; propagatedBuildInputs [ julec ]; ... } ./hook.sh即该钩子通过makeSetupHook将 hook.sh 包装为一个 setup hook并把编译器julec作为propagatedBuildInputs传递确保钩子脚本执行时julec命令一定在 PATH 中可用。快速上手完整的代码示例在clangStdenv.mkDerivation中接入julec.hook的最简用法如下取自官方文档示例{ julec, clangStdenv, }: clangStdenv.mkDerivation (finalAttrs: { # ... nativeBuildInputs [ julec.hook ]; # Customize filenames if needed JULE_SRC_DIR ./src; JULE_OUT_DIR ./bin; JULE_OUT_NAME hello-jule; JULE_TEST_DIR ./tests; JULE_TEST_OUT_DIR ./test-bin; JULE_TEST_OUT_NAME hello-jule-test; # ... })要点说明nativeBuildInputs [ julec.hook ];是唯一必须的设置它同时注入钩子脚本与julec编译器其余变量均为可选定制项若未设置会自动回退到默认值示例中的./src、./tests等路径均相对于mkDerivation解包后的构建目录即源码根目录。仓库自带的集成测试 pkgs/by-name/ju/julec/test/default.nix 是这一用法的真实范例它构建名为hello-jule的包源码目录中包含 main.jule打印Hello, Jule!与_test.jule测试文件并且没有显式设置任何 JULE_* 变量完全依靠钩子默认值运行同时打开doCheck true验证 check 阶段clangStdenv.mkDerivation (finalAttrs: { pname hello-jule; inherit (julec) version; src ./hello-jule; nativeBuildInputs [ julec.hook ]; doCheck true; meta { inherit (julec.meta) platforms; }; })变量详解7 个控制项及其源码默认值julec.hook的全部配置均通过环境变量完成这些变量在 hook.sh 的julecSetEnv函数中被统一处理只有变量未设置-z判断为空时才会赋予默认值因此你在 derivation 属性中写入的值会优先保留。变量作用默认值源码位置JULE_SRC_DIR包含main.jule的源码目录./srchook.sh L4-L6JULE_OUT_DIR编译产物的输出目录./binhook.sh L7-L9JULE_OUT_NAME编译产物的二进制文件名outputhook.sh L10-L12JULE_TEST_DIR包含测试文件的目录取JULE_SRC_DIR的值hook.sh L13-L15JULE_TEST_OUT_DIR测试二进制的输出目录取JULE_OUT_DIR的值hook.sh L16-L18JULE_TEST_OUT_NAME测试二进制的文件名JULE_OUT_NAME加-test后缀hook.sh L19-L21dontUseJulecBuild/dontUseJulecCheck/dontUseJulecInstall禁用对应钩子阶段false未设置即视为不禁用hook.sh L72-L79JULE_SRC_DIR源码目录指定包含main.jule的目录默认./src。它同时是构建与测试共用的源码入口——测试目录在未显式配置时直接复用该值。JULE_OUT_DIR与JULE_OUT_NAME构建产物位置与名称分别指定编译二进制的输出目录与文件名默认./bin与output。在julecBuildHook中钩子会先mkdir -p $JULE_OUT_DIR再执行编译hook.sh L30-L31julec build --opt L2 -p -o $JULE_OUT_DIR/$JULE_OUT_NAME $JULE_SRC_DIR注意这里的编译参数是源码中硬编码的--opt L2启用 L2 级别的优化-p打印print编译过程相关信息-o指定输出二进制路径。这意味着最终产物总是$JULE_OUT_DIR/$JULE_OUT_NAME路径拼接逻辑不可通过额外变量改变。JULE_TEST_DIR、JULE_TEST_OUT_DIR、JULE_TEST_OUT_NAME测试三件套三者默认值分别继承自JULE_SRC_DIR、JULE_OUT_DIR与JULE_OUT_NAMEhook.sh L13-L21。在julecCheckHook中的完整测试流程为hook.sh L38-L56执行preCheck钩子mkdir -p $JULE_TEST_OUT_DIR创建测试输出目录调用julec test -o $JULE_TEST_OUT_DIR/$JULE_TEST_OUT_NAME $JULE_TEST_DIR编译测试直接执行生成的测试二进制$JULE_TEST_OUT_DIR/$JULE_TEST_OUT_NAME运行测试执行postCheck钩子。可见 check 阶段被设计为编译 运行两步且测试文件默认与主源码同目录.jule后缀的_test.jule文件即会被julec test识别。dontUseJulecBuild、dontUseJulecCheck、dontUseJulecInstall阶段禁用开关三个开关分别控制是否使用预定义的构建、检查与安装钩子默认均为 false未设置。源码中的条件赋值逻辑hook.sh L72-L79同时兼顾了mkDerivation阶段自定义的优先级if [ -z ${dontUseJulecBuild-} ] [ -z ${buildPhase-} ]; then buildPhasejulecBuildHook fi if [ -z ${dontUseJulecCheck-} ] [ -z ${checkPhase-} ]; then checkPhasejulecCheckHook fi if [ -z ${dontUseJulecInstall-} ] [ -z ${installPhase-} ]; then installPhasejulecInstallHook fi即只有当你既没有禁用钩子、又没有自行定义对应的buildPhase/checkPhase/installPhase时默认钩子才会被启用。这一设计让开发者可以在保留其他阶段默认行为的同时灵活替换或扩展任意阶段。典型的使用场景项目需要自定义安装逻辑如安装多个二进制、资源文件时设置dontUseJulecInstall true;并自行编写installPhase。安装阶段的行为julecInstallHookhook.sh L58-L70的逻辑非常直接执行preInstall钩子mkdir -p $out/bin创建输出目录用cp -r $JULE_OUT_DIR/$JULE_OUT_NAME $out/bin/将编译产物复制到$out/bin/执行postInstall钩子。由于-r选项的存在即使产物是目录也能完整复制。这也意味着构建产物名JULE_OUT_NAME直接决定了最终安装到$out/bin下的可执行文件名是影响安装结果的关键变量。与其他 phase 钩子的协同与 Nixpkgs 中其他语言钩子一样julec.hook的三个内部函数都通过runHook preBuild/runHook postBuild等标准机制预留了扩展点hook.sh L27、L33、L41、L53、L61、L67。这意味着你可以继续使用 Nixpkgs 通用的preBuild、postInstall等属性在钩子前后插入自定义逻辑而无需推翻钩子本身。常见问题与最佳实践忘记设置JULE_SRC_DIR导致找不到 main.jule钩子默认从./src查找源码若你的项目把main.jule放在仓库根目录请显式设置JULE_SRC_DIR .;。只想构建、跳过测试不设置doCheck默认 false即可julecCheckHook只在 check 阶段被调用而 Nixpkgs 默认不执行 check 阶段。自定义构建方式设置dontUseJulecBuild true;并编写自己的buildPhase此时JULE_*变量将不再参与构建但仍可用于你自定义的脚本中因为环境变量仍会被导出。查看钩子实际行为构建时添加-v或观察日志中的Executing julecBuildHook/Executing julecCheckHook/Executing julecInstallHook输出即可确认各阶段是否按预期执行。参考资源官方文档doc/hooks/julec.section.md钩子脚本实现pkgs/by-name/ju/julec/hook.sh钩子 Nix 封装pkgs/by-name/ju/julec/hook.nix集成测试pkgs/by-name/ju/julec/test/default.nix、测试源码目录同目录文档参考doc/hooks/index.md【免费下载链接】nixpkgsNix Packages collection NixOS项目地址: https://gitcode.com/GitHub_Trending/ni/nixpkgs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考