Stack项目中使用GHCup管理多版本GHC的实践指南

问题背景

在使用Haskell开发过程中，开发者经常需要同时处理多个项目，这些项目可能依赖不同版本的GHC编译器。Stack作为Haskell的构建工具，默认会自行管理GHC版本，但有时我们希望与GHCup工具配合使用，实现更灵活的版本管理。

环境配置要点

在Ubuntu 23.10系统上，通过以下配置可以实现Stack与GHCup的协同工作：

1. 禁用Stack的自动GHC安装功能：

stack config set install-ghc false --global

2. 禁用系统GHC的使用：

stack config set system-ghc false --global

3. 确保GHCup管理的GHC位于PATH环境变量中

常见问题解析

问题一：Stack忽略stack.yaml中指定的GHC版本

现象：即使stack.yaml中指定了LTS-14.27（对应GHC 8.6.5），Stack仍使用GHC 9.6.4。

原因分析：经过排查发现，这是由于手动修改了stack.yaml.lock文件导致的。该文件记录了快照的SHA256校验值，错误的修改会导致Stack无法正确识别快照版本。

解决方案：

• 删除项目中的stack.yaml.lock文件
• 重新运行Stack命令，让其自动生成正确的lock文件

问题二：Cabal文件中的通配符路径问题

现象：构建过程中出现文件复制失败的错误，提示找不到某些目录。

根本原因：Cabal文件中使用了**通配符匹配路径，这在较旧版本的Cabal（如2.4.0.1）中存在兼容性问题。

解决方案：

1. 升级到支持更完善通配符功能的Cabal版本（3.0+）
2. 或者将通配符路径替换为具体的文件列表：

data-files: 
  vendor/tree-sitter-typescript/typescript/src/node-types.json
  vendor/tree-sitter-typescript/typescript/corpus/common/declarations.txt
  vendor/tree-sitter-typescript/typescript/corpus/common/expressions.txt
  vendor/tree-sitter-typescript/typescript/corpus/common/functions.txt
  vendor/tree-sitter-typescript/typescript/corpus/common/types.txt

最佳实践建议

1. 避免手动修改lock文件：stack.yaml.lock文件应由Stack自动维护，手动修改可能导致不可预期的问题。

2. 注意Cabal版本兼容性：在使用路径通配符等功能时，需考虑构建环境中Cabal的版本支持情况。

3. 合理配置构建环境：对于需要特定GHC版本的项目，可以通过Stack的--compiler参数明确指定：

stack build --compiler ghc-8.6.5 --resolver lts-14.27

4. 理解工具链协作原理：Stack与GHCup的协作需要正确理解各工具的职责边界，避免配置冲突。

通过以上分析和解决方案，开发者可以更好地在Stack项目中使用GHCup管理多版本GHC，提高开发效率并减少环境配置问题。