在包含 `cabal` 托管包 DB 的环境中使用 `cabal` 运行可执行文件

Question

我有一个程序

A

，它在内部调用 GHC-as-an-API 来编译其他一些 Haskell 模块

B

。

B

具有外部依赖项（包括编译时插件），这些依赖项记录在

.cabal

文件中作为

A

的依赖项。

如果我通过项目目录中的

stack run A

运行该程序，一切都会正常：

stack

似乎正确设置了环境，当它调用GHC函数时，这些函数在具有依赖包的上下文中运行设置正确。

如果我通过

cabal run A

运行该程序，那么它不起作用：

A

开始运行，一旦调用 GHC 来编译

B

，该步骤就会失败，因为 GHC 找不到插件模块.

如何使用

cabal

在 GHC 包数据库设置为包含所有 Cabal 跟踪的依赖项的上下文中从我的项目目录本地运行我的程序

A

？

（如果有人好奇，在我的例子中

A

是一个Shakefile，

B

是一些Clash代码，以及它无法找到的外部插件

GHC.TypeLits.KnownNat.Solver

）

Answer 1

我认为最正确的（手动）方法是

1. 删除A 中不属于B 的依赖项。
2. 为 B 编写（或让 A 编写）一个模拟 cabal 文件及其所有依赖项（在单独的目录中）。
3. 使用

   cabal install B --only-dependencies --lib --package-env ./some/file

   让 cabal 准备 B 的包环境。
4. 在调用 -package-env

    编译 

   GHC_ENVIRONMENT

    时，将 

   ghc

    或 

   B 设置为您在上面写出的文件。
5. （尽量不要在同一个包环境文件上调用

   cabal install

   两次，至少在几年前它不起作用。如果

   B

   的配置发生变化，只需重新创建它即可。）

您还可以考虑为

A

制作 custom-setup

 的 

B 脚本，并将

B

本身标记为

autogen-modules

。这使上述过程自动化。请再次注意，

A

和

B

将具有独立的依赖项列表（

setup-depends

与

build-depends

）。将

A

和

B

视为生活在不同编译环境中的独立实体是正确的。