在 Red Hat 上从源代码安装 Haskell Platform 2014 的官方方法是什么？答案

【问题标题】：What is the official way to install Haskell Platform 2014, from source, on Red Hat?在 Red Hat 上从源代码安装 Haskell Platform 2014 的官方方法是什么？
【发布时间】：2014-11-13 11:33:24
【问题描述】：

我正在尝试在 Red Hat Enterprise Linux 6.5 上从源代码安装 Haskell Platform 2014.2.0.0。我有两年前的 Haskell Platform 2012.4.0.0 和 GHC 7.4.2 的功能安装，以及 JustHub 最近安装的 Haskell Platform 2013.2.0.0 和 GHC 7.6.3。

我已经从源代码构建了 GHC 7.8.3，但它在测试套件中不断出现七处故障。我不知道这些测试失败是否无害。（测试失败与我的问题无关，但以后可能会变得很重要。）

我解压了 2014.2.0.0 的源码包，阅读 README。它说构建这个 Haskell 迭代的方法是使用一个 shell 脚本，它被调用：

./platform.sh $PATH_TO_GHC_BINDIST_TARBALL

我没有 GHC 二进制分发 tarball。据我所知，对于任何版本的 Red Hat Enterprise Linux，都没有 GHC 7.8.3 的二进制分发 tarball。我有一个内置的 GHC 7.8.3。我如何告诉platform.sh——或者它下面的任何东西——没有tarball，它应该只使用$PATH 中的内容？或者，如何打包我现有的 GHC 7.8.3 安装，以便 platform.sh 接受它？

构建的 GHC 没有“cabal”命令，因此 platform.sh 中的 cabal 命令回退到 $PATH，我可以将其配置为其他已安装版本（2013.2/7.6.3 或 2012.4 /7.4.2)。这似乎没有什么区别：没有人认出“阴谋集团——沙盒”。两者都会导致抱怨我应该运行 'cd hptool ; cabal install --only-dependencies'，我已经重复了。 platform.sh 永远不会超过这一点。

如果我手动运行 platform.sh 中的命令，我会进入 'cd hptool; cabal build'，错误输出：“cabal-1.16.0.2：首先运行'configure'命令。”。但是 hptool 目录中没有可用的“配置”命令。

我现在卡住了。如何在 RHEL 6 上构建 Haskell Platform 2014？

【问题讨论】：

你应该尝试在不使用 platform.sh 的情况下构建 hptool（hptool 只是一个 cabal 包 - cabal configure; cabal build 应该可以工作，如果你有 GHC 和 cabal 工作）。 hptool 本身似乎需要 GHC 二进制发行版，所以我不知道这是否可行。如果它不起作用，HP 只是一堆软件包 - 转到 HP tarball 中的 packages 目录和 cabal configure; cabal install 这些软件包。如果这仍然不起作用，则 GHC 或 cabal 都不起作用。
这让我更进一步。我已经在包下的每个子目录中运行了配置/构建/安装序列，但是许多配置序列抛出错误，其中许多与缺少模块有关。一些缺失的位是这个特定版本的 Haskell Platform 2014 的内部依赖项（例如 vector-0.10.9.1 想要原语 0.5.2.1）。我假设 hptool 知道事情的顺序，并且可以处理为一个包提供它需要的另一个包的依赖项。有没有办法将我构建的 GHC 7.8.3 打包到 hptool 可以使用的路径结构中？
我从来没有从源代码构建 HP，所以我不能告诉你如何将你自己的 GHC 打包成 hptool 可以接受的格式。原语不是 hptool 或 HP 内部的，它是一个常规的 cabal 包，您可以通过 cabal install primitive 获得。

标签： haskell installation redhat rhel platform

【解决方案1】：

您需要使用您的 GHC 资源来制作您自己的“bindist”。路线https://ghc.haskell.org/trac/ghc/wiki/MakingReleases

【讨论】：

【解决方案2】：

我设法安装了 Haskell 平台，并且可以正常运行。我最终放弃了 platform.sh 并使用手动 cabal 命令手动安装了 Haskell Platform tarball 中的所有软件包及其依赖项。连同坏掉的platform.sh，我在途中遇到了很多问题。

我记得的那些：

如果你安装了 Haskell Platform 2013 或以前的版本，platform.sh 将永远不会成功。它需要一个能够识别“--sandbox”选项的阴谋集团，而阴谋集团 1.18 不知道该选项。您必须安装比 Haskell Platform 2013 提供的更新的 cabal。（不过，GHC 7.4 或 7.6 似乎还不错。）
我有一个现有的 .cabal 和 .ghc 目录，其中包含不兼容的构建和/或各种包的版本。我在测试时多次删除了这两个目录。
cabal install --global 的行为与默认的 cabal install --user 完全不同。在我执行“cabal install cabal-install”之后，.cabal 包含了一些有用的东西。花了两三次尝试才弄清楚新的阴谋集团二进制文件的去向。
ghc 和 cabal 在 .ghc 和 .cabal 中选择新库，但不是新的二进制文件。
GHC 和 cabal 安装都不是默认为 --enable-shared，除非有什么需要它。在此之前，我必须使用 --enable-shared 重建所有内容——一直回到 GHC 7.8.3 本身。
黑线鳕与构建它所使用的 GHC 版本非常紧密地绑定在一起。我必须重建它以使 --enable-documentation 能够适用于使用 GHC 7.8.3 构建的任何东西。
测试包和文本包紧密集成，如果您尝试执行“cabal install text --enable-tests”，它们具有循环依赖关系。即使安装了最新版本的 text 和测试包，cabal 仍然不会运行 text 测试套件，所以我放弃并安装了 text 没有测试它。
我的默认环境包括“LC_ALL=C”。这会触发 cabal 中的一个已知错误（显然在所有版本中），它会破坏一些包构建。为了解决这个问题，我不得不将其转换为“LC_ALL=en_US.utf8”。如果您将 LC_ALL 或任何其他语言环境变量（例如 LANG 或 LC_）设置为 C，我不知道受影响的软件包是否会起作用。
cabal install --global 关于包的存储位置非常不一致。我们将各个包拆分到它们自己的子目录中，然后在所有这些子目录的已知位置构建符号链接树。所以 ghc 在它自己的 /usr/sup/ghc-7.8.3 子目录中； Haskell 平台位于另一个子目录 /usr/sup/haskell-platform-2014.2.0.0 中。我一直在每个“cabal install”命令中使用 --prefix=/usr/sup/haskell-platform-2014.2.0.0，但即便如此，一些库最终还是在 /usr/sup/ghc-7.8.3 中。
GHC 和 Haskell 平台在 /usr/sup/ghc-7.8.3/lib/ghc- 中都有一个关于已构建内容及其所在位置的字典 - 也许作为安装位置不一致的解决方法 - 7.8.3/package.conf.d/package.cache。如果那个包字典不是世界可读的，ghc 就会中断。它应该做的是查看实际的文件结构以查找内容。如果字典不可用，则 ghc 会中断，因此不应将文件称为“缓存”，因为缓存未命中不应导致灾难性故障。也许将其重命名为“package-mandatory-dictionary”？

最终，一切都安装好了，但我不得不怀疑我的头撞在墙上造成的伤害。

【讨论】：