1. 项目概述为什么 Spack 的构建系统不是“配个环境就完事”的玩具Spack 自定义构建系统Custom Build Systems这个标题里“自定义”两个字是灵魂而“Phase”、“装饰器”、“手写构建脚本”则是三条实打实的腿。我第一次在某高校高性能计算中心接手一个需要编译 OpenFOAM自研求解器耦合模块的项目时才真正意识到Spack 默认的autotools、cmake、meson这些构建系统就像一套标准尺码的西装——对绝大多数开源软件管用但一旦你面对的是带私有补丁链、依赖非标 Fortran 编译器链、需要在 configure 前后插入三段 Python 脚本做预处理和后验证、还要把生成的二进制按 MPI 版本号打上不同 tag 的场景标准西装立刻绷开线。这时候Spack 的 Custom Build Systems 就不是可选项而是唯一能让你不重写整个包管理逻辑的救命稻草。它解决的核心问题非常具体当软件的构建生命周期无法被现有构建系统抽象覆盖时如何让 Spack 依然能完整参与依赖解析、环境隔离、变体控制、安装路径管理、元数据记录这一整套科学计算软件供应链流程换句话说它不是让你放弃 Spack 去写 Makefile而是让你把 Makefile、Shell 脚本、Python 工具链重新“注册”进 Spack 的世界观里让它认得、管得住、记得清、装得稳。适合谁不是刚学 Linux 的新手而是每天和 HPC 集群打交道、要维护几十个科研软件栈、经常被 PI 一句“这个新版本的 XYZ 库必须用我们自己改过的编译器参数”逼到墙角的系统管理员、计算平台工程师或者正在把实验室代码工程化、准备提交到超算中心软件仓库的科研开发者。它不教你怎么写 C但会告诉你怎么让 Spack 理解你写的那行gfortran -fopenmp -marchnative -J${INSTALL_PREFIX}/mod/ ...不是乱码而是构建逻辑里不可分割的一环。2. 构建系统设计哲学Phase 是骨架装饰器是神经手写脚本是血肉Spack 的构建系统设计本质上是一次对“软件构建”这个动作的深度解构与再封装。它没有选择大而全地模拟所有构建工具的行为而是提炼出一个普适性极强的生命周期模型——Phase 模型。这就像给所有软件构建过程画了一张通用流程图从源码获取fetch、校验stage、打补丁patch到真正的编译前准备configure、编译build、安装install再到最后的测试test和清理clean。每一个 Phase就是一个明确的、可被 Spack 调度的执行点。它的精妙之处在于Phase 本身不包含任何具体实现它只是一个契约、一个占位符、一个钩子hook。你告诉 Spack“我的包在build这个阶段要执行一段我写的 Python 代码”Spack 就会在它认为该build的时候调用你提供的这段代码。这就彻底解耦了 Spack 的核心调度引擎和具体软件的构建细节。而装饰器Decorator就是你向 Spack “注册”这些自定义行为的语法糖。run_before(configure)、run_after(install)、on_package这些看似简单的装饰器背后是 Spack 对 Python 函数对象的深度元编程操作。它在包类加载时就扫描所有被装饰的方法把它们按 Phase 名称归类存入一个内部的执行队列。当你运行spack install mypackageSpack 就像一个精密的流水线调度员按顺序拉取队列里的函数来执行。这种设计的好处是显而易见的你的自定义逻辑可以零散地、按关注点分离地写在类的不同位置但最终会被 Spack 按照严格的构建时序无缝编织在一起。你不必为了一个pre-configure步骤就去重写整个configure方法你也不必为了一个post-install的文件权限修复就去 hackinstall的底层逻辑。这种“声明式”的编程范式极大降低了复杂构建逻辑的维护成本。至于手写构建脚本它才是整个自定义系统的血肉和终点。Spack 并不强制你用 Python 写一切。它非常务实如果你有一段经过千锤百炼、跑在多个集群上都无比稳定的 Shell 脚本build.shSpack 完全支持你用self.spawn(./build.sh)或者sh which(sh); sh(./build.sh)来调用它。甚至如果你的构建流程极度复杂需要一个独立的 Python 工具链来管理Spack 也允许你通过subprocess.run()或import的方式把它接入进来。这里的关键词是“接入”而不是“替代”。Spack 的角色是那个提供沙箱环境self.stage.path、注入环境变量env[CC],env[FC]、管理安装路径self.prefix、记录构建日志self.log_path的“基础设施提供商”。你手写的脚本则是那个在沙箱里挥洒自如的“施工队”。两者各司其职缺一不可。我见过最典型的反面案例是某团队试图用纯 Bash 脚本绕过 Spack结果在依赖冲突、多版本共存、环境变量污染上栽了大跟头最后花三倍时间又把脚本重构成符合 Spack Phase 规范的 Python 包。所以理解这个设计哲学是避免走弯路的第一步Phase 是骨架决定了流程的骨架装饰器是神经决定了信号的传递手写脚本是血肉决定了功能的实现。三者缺一自定义构建系统就只是空中楼阁。3. 核心细节解析从PackageBase到BuildSystemMixin的继承链与方法重载要真正动手写一个自定义构建系统你必须搞清楚 Spack 包类的继承体系。这不是一个可选的理论问题而是一个直接决定你代码能否跑起来的实践前提。Spack 的包类其根是spack.package_base.PackageBase。这是一个极其精简的基类只定义了name、version、url等最基础的元数据属性以及do_fetch、do_install这样最顶层的调度方法。它本身不包含任何关于configure、build、install这些 Phase 的具体实现。那么这些 Phase 方法是从哪里来的答案是spack.build_systems下的各个 Mixin 类。BuildSystemMixin是所有构建系统 Mixin 的父类它定义了phases这个核心属性——一个字符串列表例如[configure, build, install]。这个列表就是 Spack 构建流水线的“路线图”。紧接着AutotoolsPackage、CMakePackage、MesonPackage这些具体的构建系统类都继承自BuildSystemMixin并各自实现了configure_args()、build_targets()、install_targets()等方法。它们的工作原理是在PackageBase.do_install()的调度过程中Spack 会遍历self.phases列表对于列表中的每一个 Phase 名称如configure它会尝试调用self.configure()方法。如果self对象即你的包实例没有这个方法Spack 就会向上查找直到在AutotoolsPackage这个 Mixin 里找到它并执行其中的默认逻辑。所以当你想创建一个自定义构建系统时正确的做法不是去继承PackageBase而是去继承一个更合适的 Mixin。最常用、也最推荐的起点是spack.build_systems.autotools.AutotoolsPackage。为什么因为它已经为你处理了大量“脏活累活”它自动帮你设置了self.configure_args的默认值比如--prefix{self.prefix}它内置了self.configure()方法该方法会自动拼接./configure命令并执行它还提供了self.make和self.make_install这样的便捷方法。你只需要在这个坚实的基础上进行“增量式”的定制。例如你不需要重写整个configure()而只需要用run_before(configure)装饰一个方法来生成一个动态的config.h头文件你也不需要重写build()而只需要用run_after(build)来运行一个单元测试。另一个关键细节是self.stage.path和self.prefix的使用。self.stage.path是 Spack 为你准备的、一个干净的、临时的构建工作目录。所有源码解压、补丁应用、configure 执行、make 编译都应该发生在这里。而self.prefix则是 Spack 为你规划好的、最终的安装根目录通常形如/opt/spack/opt/spack/linux-centos8-x86_64/gcc-11.2.0/myapp-2.1.0-abc123。你所有的make install命令都必须确保其目标是self.prefix。这是 Spack 实现“多版本共存”和“环境隔离”的基石。我曾经在一个项目中因为疏忽在build.sh脚本里硬编码了/usr/local作为安装路径结果导致spack load myapp时环境变量PATH指向的却是/usr/local/bin而不是 Spack 管理的路径造成了严重的环境污染。这个坑几乎每个初学者都会踩一次。提示永远不要在你的自定义方法里直接os.chdir()到某个绝对路径。Spack 的调度是基于self.stage.path的你应该始终以它为基准。例如os.path.join(self.stage.path, src)是安全的而/home/user/src是危险的。4. 实操过程从零开始编写一个带预处理和后验证的 Fortran 库包现在让我们进入最硬核的部分一个完整的、可运行的实战案例。假设我们要打包一个名为libfluid的 Fortran 数值库它的构建流程如下Pre-configure: 运行一个 Python 脚本gen_config.py根据当前系统的 MPI 版本生成一个config.mk文件。Configure: 运行./configure --prefix$PREFIX但它会读取上一步生成的config.mk。Build: 运行make -f Makefile.fortran而不是默认的Makefile。Post-install: 安装完成后运行一个verify_install.py脚本检查生成的.mod文件是否完整并将一个VERSION文件写入self.prefix。下面就是这个包的完整package.py文件# Copyright 2013-2024, Lawrence Livermore National Security, LLC. # See the top-level LICENSE file for details. # SPDX-License-Identifier: (Apache-2.0 OR MIT) from spack.package import * from spack.build_systems import AutotoolsPackage class Libfluid(AutotoolsPackage): A high-performance Fortran library for computational fluid dynamics. homepage https://example.com/libfluid url https://example.com/libfluid-2.1.0.tar.gz version(2.1.0, sha256a1b2c3d4e5f6...) # 我们显式地覆盖 phases 列表因为我们不使用默认的 configure # 而是用一个自定义的 pre_configure 和 real_configure 来替代。 # 注意这里我们保留了 build 和 install因为它们的默认行为是适用的。 phases [pre_configure, real_configure, build, install, post_install] # Step 1: Pre-configure phase - 生成 config.mk run_before(real_configure) def pre_configure(self): # 获取当前 MPI 的版本信息 mpi self.spec[mpi] mpi_version mpi.version # 构建 config.mk 的内容 config_content f# Auto-generated by Spack MPI_VERSION {mpi_version} FC {self.compiler.fc} FFLAGS -O3 -fopenmp -I{self.spec[mpi].prefix.include} LDFLAGS -L{self.spec[mpi].prefix.lib} -lmpi # 将内容写入 stage 目录下的 config.mk config_path os.path.join(self.stage.path, config.mk) with open(config_path, w) as f: f.write(config_content) tty.info(fGenerated config.mk for MPI {mpi_version}) # Step 2: Real-configure phase - 替代默认的 configure run_before(build) def real_configure(self): # 进入 stage 目录 with working_dir(self.stage.path): # 手动执行 configure 命令 # 注意我们没有调用 self.configure()因为我们完全接管了这个阶段 configure Executable(./configure) configure(--prefix{0}.format(self.prefix)) # Step 3: Build phase - 使用自定义的 Makefile run_before(install) def build(self): with working_dir(self.stage.path): # 使用 make 的 -f 参数指定 Makefile make which(make) make(-f, Makefile.fortran, all) # Step 4: Install phase - 使用默认的 install但我们需要确保它能找到我们的 Makefile # 因为我们的 build 阶段已经生成了目标文件所以默认的 install 会尝试运行 make install # 但我们希望它运行 make -f Makefile.fortran install所以我们需要重写 install_targets def install_targets(self, spec, prefix): # 这个方法会返回一个列表Spack 会将其作为参数传给 make # 我们返回 [install]但前提是 make 会使用我们指定的 Makefile # 更稳妥的做法是在 build 阶段就完成所有安装然后让 install 阶段什么都不做 pass # Step 5: Post-install phase - 验证和写入 VERSION run_after(install) def post_install(self): # 首先验证 .mod 文件 mod_dir os.path.join(self.prefix, mod) if not os.path.isdir(mod_dir): raise InstallError(Fortran module directory not found after install) expected_mods [fluid_types.mod, solver_core.mod, io_utils.mod] missing_mods [mod for mod in expected_mods if not os.path.exists(os.path.join(mod_dir, mod))] if missing_mods: raise InstallError(fMissing Fortran modules: {missing_mods}) # 然后写入 VERSION 文件 version_file os.path.join(self.prefix, VERSION) with open(version_file, w) as f: f.write(flibfluid {self.version}\n) f.write(fBuilt with MPI {self.spec[mpi].version}\n) tty.info(Installation verified and VERSION file written.)这个例子展示了几个关键实操要点Phases 的灵活定制我们没有使用默认的configure而是定义了pre_configure和real_configure两个新 Phase并通过run_before装饰器精确控制它们的执行顺序。self.spec的强大威力self.spec[mpi]不仅能拿到 MPI 的安装路径还能拿到它的version、compiler等所有元信息。这是 Spack 依赖解析能力的直接体现你无需自己去which mpif90或mpif90 --version。working_dir上下文管理器这是 Spack 提供的一个极其重要的工具。它确保了with working_dir(...):块内的所有操作都在指定的目录下进行并且在块结束时自动切回原目录。这比手动os.chdir()安全一万倍。Executable类的使用Executable(./configure)创建了一个可执行对象它会自动处理 PATH 查找、错误捕获等。比直接用subprocess.run()更符合 Spack 的风格。错误处理的规范性我们使用raise InstallError(...)来报告失败。Spack 会捕获这个异常并给出清晰的错误信息包括构建日志的位置这对于调试至关重要。5. 装饰器的高级用法与陷阱on_package、when与条件执行的实战装饰器是 Spack 自定义构建系统中最灵活、也最容易误用的部分。除了最常用的run_before和run_after还有两个高级装饰器值得深入探讨on_package和when。on_package装饰器的作用是让你的方法只在特定的“包上下文”中生效。这听起来有点抽象但它的典型应用场景非常明确当你需要为一个包族family中的多个包提供统一的、但又不希望污染全局命名空间的构建逻辑时。例如你有一个my-hpc-tools包族里面包含了libfluid、libheat、libstruct三个库它们共享一套相同的 Fortran 模块管理规范。你不想在每个包里都复制粘贴一遍post_install的验证逻辑。这时你可以创建一个MyHpcToolsBase基类class MyHpcToolsBase(Package): # 这个方法会被所有继承自 MyHpcToolsBase 的包在 install 后自动调用 on_package run_after(install) def verify_fortran_modules(self): mod_dir os.path.join(self.prefix, mod) # ... 公共的验证逻辑然后让Libfluid、Libheat都继承MyHpcToolsBase。on_package确保了这个方法只对MyHpcToolsBase及其子类有效不会影响到其他无关的包。这是一种非常优雅的代码复用方式。而when装饰器则是实现“条件构建逻辑”的终极武器。它的语法是when(condition)其中condition是一个字符串会被 Spack 解析为一个布尔表达式。最常见的用法是基于变体variant或依赖dependency来开启或关闭某个构建步骤。例如libfluid可能有一个cuda变体用于启用 GPU 加速。那么你就可以这样写# 只有在启用了 cuda 变体时才执行 CUDA 相关的配置 when(cuda) run_before(real_configure) def cuda_configure(self): # 设置 CUDA 相关的环境变量 env[CUDA_HOME] self.spec[cuda].prefix env[NVCC] join_path(self.spec[cuda].prefix, bin, nvcc) # 只有在启用了 cuda 且 MPI 版本 4.0 时才执行一个特殊的链接步骤 when(cuda ^mpi4.0:) run_after(build) def link_cuda_mpi(self): # 执行一个特殊的链接命令 pass这里的^mpi4.0:是一个依赖约束表达式意思是“依赖于 MPI且其版本号大于等于 4.0”。Spack 会自动解析这个字符串并在满足条件时才调用被装饰的方法。然而这些高级装饰器也伴随着陷阱。最大的陷阱是装饰器的执行顺序。Spack 的装饰器执行顺序是on_packagewhenrun_before/run_after。这意味着when的条件判断是在on_package的包上下文筛选之后进行的。如果你把when放在on_package前面Spack 会报错因为它还不知道这个方法属于哪个包。另一个陷阱是when表达式的书写。它不是一个 Python 表达式而是一个 Spack 特有的 DSL领域特定语言。你不能写when(self.spec.satisfies(cuda))因为self在装饰器执行时还不存在。你必须使用 Spack 的标准语法如cuda、^mpi4.0:、platformlinux。注意when装饰器的条件是静态的在包类定义时就被解析。它不能访问运行时的self对象。因此所有需要动态判断的逻辑例如检查某个文件是否存在都必须放在方法体内部而不是装饰器里。6. 手写构建脚本的接入策略何时该用spawn何时该用subprocess何时该用which当构建逻辑过于复杂无法用几行 Python 清晰表达时手写脚本就成了必然选择。但如何将外部脚本“接入” Spack却有多种策略每种都有其适用场景和性能权衡。策略一self.spawn()—— 最简单、最安全的“一键执行”self.spawn()是 Spack 封装的最底层、最直接的执行接口。它等价于subprocess.run(..., checkTrue)会严格检查命令的返回码。如果命令失败返回码非零spawn会立即抛出ProcessError异常Spack 会捕获并终止整个安装流程。这是最推荐的、用于执行“关键构建步骤”的方式。例如执行一个核心的build.shrun_before(install) def build_with_script(self): # spawn 会自动在 self.stage.path 下执行 self.spawn([./build.sh, --enable-optimization])它的优点是简洁、安全、与 Spack 的错误处理机制无缝集成。缺点是它会阻塞当前线程直到脚本执行完毕且你无法轻易地捕获和处理脚本的 stdout/stderr除非你额外传入output和error参数。策略二which()Executable()—— 最灵活、最符合 Spack 风格的“专业调用”which()是 Spack 的“PATH 查找器”它会搜索$PATH中的所有目录找到第一个匹配的可执行文件。Executable()则是对这个可执行文件的包装提供了更丰富的调用选项。这是 Spack 官方文档最推崇的方式因为它体现了 Spack 的“环境感知”哲学run_before(install) def build_with_make(self): # 查找系统中的 make make which(make) # 如果没找到Spack 会自动报错提示用户安装 make # 调用 make并传递参数 make(-j, str(make_jobs), -f, Makefile.custom, all)这种方式的优点是它尊重用户的环境which会找到用户PATH里指定的make它能自动处理找不到命令的错误which返回None时会抛出CommandNotFoundError并且Executable对象支持env参数可以方便地注入环境变量。缺点是对于非常复杂的脚本调用代码可能略显冗长。策略三subprocess.run()—— 最强大、但也最“危险”的“自由发挥”当你需要完全掌控子进程的输入输出、需要设置超时、需要处理流式数据时subprocess.run()就是你的终极武器。但请务必记住使用它就意味着你主动放弃了 Spack 的一部分错误处理和环境管理能力。你必须自己处理returncode、stdout、stderr并且要手动确保cwd工作目录是self.stage.path。一个典型的、谨慎的用法是run_after(install) def run_custom_test(self): try: result subprocess.run( [./run_tests.sh], cwdself.stage.path, envdict(os.environ), # 复制当前环境 capture_outputTrue, textTrue, timeout300 # 5分钟超时 ) if result.returncode ! 0: # 手动构造错误信息包含 stdout 和 stderr raise InstallError( fCustom tests failed:\nSTDOUT:\n{result.stdout}\nSTDERR:\n{result.stderr} ) except subprocess.TimeoutExpired as e: raise InstallError(fCustom tests timed out after {e.timeout} seconds)这个例子展示了如何安全地使用subprocess.run()设置了cwd、env、timeout并手动检查了returncode最后用InstallError将错误信息包装起来交还给 Spack 的错误处理系统。如果你跳过这些步骤就很容易写出一个“静默失败”或“环境污染”的脚本。7. 常见问题与排查技巧实录从Phase not found到Environment pollution的真实战场在真实的 Spack 包开发中你遇到的绝大多数问题都不会出现在官方文档的“Hello World”例子里。它们往往隐藏在构建流程的缝隙中需要你像一个侦探一样去日志、看环境、查路径。以下是我在多个项目中总结出的、最高频、也最棘手的五个问题及其排查技巧。7.1 问题Phase xxx not found in package现象运行spack install mypackage时报错Phase pre_configure not found in package。原因这是最经典的“拼写错误”陷阱。Spack 的phases列表和run_before(xxx)中的字符串必须完全一致包括大小写和下划线。pre_configure和pre-configure是两个完全不同的 Phase。排查技巧首先检查你的phases [...]列表确认pre_configure确实存在。然后检查所有run_before和run_after装饰器确认它们引用的 Phase 名称与phases列表中的完全一致。最后运行spack debug report mypackage它会打印出该包解析后的所有 Phase 列表这是最权威的“真相”。7.2 问题Command xxx not found现象在pre_configure阶段which(python)返回None或者self.spawn([./script.sh])报错找不到script.sh。原因which()只在$PATH中查找而self.spawn()默认在self.stage.path下执行。如果script.sh不在self.stage.path下或者python不在$PATH中就会失败。排查技巧在出问题的方法开头添加一行tty.info(fCurrent PATH: {os.environ.get(PATH, NOT SET)})确认PATH是否包含了你需要的目录。对于脚本使用os.path.join(self.stage.path, script.sh)来构造绝对路径然后用self.spawn([script_path])。对于which()如果它返回None不要直接调用而是先检查if not which(python): raise InstallError(Python is required but not found in PATH)。7.3 问题构建成功但spack load后找不到库或头文件现象spack install mypackage成功但spack load mypackage后gcc -lfluid报错library not found或者#include fluid.h报错no such file。原因这是“路径污染”的典型表现。你的构建脚本或make install命令没有将文件正确地安装到self.prefix下的lib和include子目录中。排查技巧在post_install阶段添加一个“路径审计”run_after(install) def audit_install(self): for subdir in [lib, include, bin]: path os.path.join(self.prefix, subdir) if not os.path.exists(path): tty.warn(fExpected directory {path} does not exist) else: files os.listdir(path) tty.info(f{path} contains {len(files)} files: {files[:3]})运行spack install --keep-stage mypackage它会保留构建目录。然后手动进入self.stage.path检查make install命令实际生成了什么对比self.prefix下的内容。7.4 问题configure阶段失败错误信息模糊现象./configure报错但只显示configure: error: ...没有详细的config.log。原因Spack 默认会将configure的 stdout/stderr 重定向到日志文件但有时configure脚本本身会将错误信息直接输出到stderr而 Spack 的日志可能没有捕获到全部。排查技巧使用spack install -v mypackage-v表示 verbose它会将构建过程的实时输出打印到终端。查看 Spack 的详细日志文件spack location -i mypackage找到安装目录然后ls -la $(spack location -i mypackage)/.spack里面会有spack-build-out.txt和spack-build-env.txt前者是构建输出后者是构建时的完整环境变量是排查环境相关问题的黄金线索。7.5 问题spack install卡住CPU 占用为 0现象安装过程在某个 Phase 后就完全不动了top显示spack进程 CPU 占用为 0。原因这几乎 100% 是你的自定义脚本尤其是 Shell 脚本在等待一个交互式输入read或者在后台启动了一个守护进程却没有正确处理其生命周期。排查技巧立即按CtrlC中断。Spack 会打印出当前正在执行的 Python 堆栈你能看到卡在了哪个方法里。检查你调用的脚本确保所有read都有默认值read -r -p Enter value: input || inputdefault所有后台进程都用wait等待其结束或者用nohup/dev/null 彻底脱离终端。8. 性能优化与最佳实践让自定义构建系统既强大又高效一个功能完备的自定义构建系统如果慢得像蜗牛那它的价值就会大打折扣。在 HPC 环境中一个包的构建时间可能长达数小时任何微小的优化乘以几十个包、上百个用户都能带来巨大的效率提升。以下是我从实践中总结出的、最有效的几条性能优化与最佳实践。第一善用spack buildcache构建缓存。这是 Spack 最强大的性能加速器但它对自定义构建系统提出了一个隐含要求构建过程必须是“确定性的”。这意味着对于同一组输入源码、spec、环境构建过程必须产生完全相同的输出。如果你的pre_configure阶段会根据当前时间戳生成一个BUILD_ID那么这个包就无法被缓存。最佳实践是所有动态生成的内容都必须基于self.spec.dag_hash()或self.spec.concrete_hash()这样的稳定哈希值。例如run_before(real_configure) def gen_build_id(self): # 使用 spec 的稳定哈希而不是 time.time() build_id self.spec.dag_hash()[:8] with open(os.path.join(self.stage.path, BUILD_ID), w) as f: f.write(build_id)第二精细控制make -j的并行度。make -j是双刃剑。-j$(nproc)在单机上很爽但在共享的 HPC 集群上它会让所有用户同时启动数百个编译进程瞬间拖垮整个登录节点。Spack 提供了make_jobs属性它默认是spack.config.get(config:build_jobs, 16)。但这个值往往是全局的。最佳实践是让你的包根据其自身的复杂度来调整property def make_jobs(self): # 对于一个轻量级的 Fortran 库4 个 job 就足够了 if self.spec.satisfies(:2.0): return 4 # 对于一个大型的 C 库可以激进一点 elif self.spec.satisfies(cuda): return 8 else: return spack.config.get(config:build_jobs, 16)第三避免在configure阶段进行耗时的网络操作。我曾见过一个包在configure阶段调用curl去下载一个在线的许可证文件。这不仅慢而且在网络不稳定时会导致整个安装失败。最佳实践是所有网络 I/O都应该放在fetch阶段由 Spack 统一管理。fetch阶段有重试、有缓存、有代理支持而你在configure里写的curl什么都没有。第四利用spack mirror进行离线构建。在一些安全要求极高的环境中集群是完全断网的。这时spack mirror就是你唯一的救星。它允许你将所有源码、二进制缓存、甚至构建日志都镜像到一个本地的 HTTP 或文件服务器上。要让你的自定义包支持镜像唯一的要求是**所有外部资源的获取都必须通过 Spack 的标准机制url、git
