为什么安装Haskell-Stack和GHC会占用如此之大的空间？

Question

为什么安装Haskell-Stack和GHC会占用如此之大的空间？

20

当通过此处的安装脚本进行 Haskell Stack 的全新安装时：

wget -qO- https://get.haskellstack.org/ | sh

接着是：

stack setup

你最终会得到一个1.5 GB大小的$HOME/.stack/目录（仅从120+ MB的下载中）。此外，如果您运行：

stack update

大小增加到2.5GB。

我习惯于Java，通常被认为是大的（几乎涵盖了所有内容，并且具有向后兼容性的弃用替代品），但是作为比较：包括JDK、独立JDK和JDK源代码的IDE大小可能约为1.5GB。

另一方面，Haskell是一种“小而美”的语言（根据我听到和阅读的内容，这可能主要是指语法和语义，但仍然如此），它如此之大，对我来说似乎有些奇怪。

为什么它这么大（与这个问题有关吗）？
这个大小正常还是我安装了额外的东西？
如果有几个（4个？5个？）“口味”可供选择，那我可以删除所有但一个吗？
是否有一些数据缓存/临时文件可以删除？
最大的目录是：.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.2.2/lib/ghc-8.2.2（1.3GB）和.stack/indices/Hackage（980MB）。我假设第一个是已安装的软件包（与stack setup相关），后者是Hackage软件包归档的某些索引（与stack update有关）。这些可以缩小吗（如上文“3.”中所述，或在线获取所需的Hackage信息）？

- Klorax

作为比较，Maven中央仓库每个包的每个版本的pom.xml副本需要占用多少磁盘空间？ - Josh Lee

1

一个被cargo使用的打包git仓库可以在这种包注册数据上实现10倍的压缩比（并且仍然支持随机访问和增量更新，不像.tar.gz），但这当然不是一个答案 ;) - Josh Lee

2

可能不是索引的问题；Haskell有相当多的包，但并不是那么多。如果我没记错的话，GHC本身很大，因为它包含了几个不同调试级别的基础库版本。还要注意，“小”和“美丽”与可执行文件大小无关；Haskell可执行文件并不巨大，但静态链接的Hello World仍然可能超过1MB。 - Cubic

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- K. A. Buhr · Accepted Answer

如你所见，它是以下内容的组合：

GHC运行时（静态、动态和分析）的三种版本（共约400兆字节）和核心GHC库（另外700兆字节），加上100兆字节的接口文件，以及200兆字节的文档和120兆字节的压缩源代码（总计1.5个千兆字节，全部在programs/x86_64-linux/ghc-8.2.2*或类似目录下）
未压缩的Hackage索引的两个相同副本00-index.tar和01-index.tar，每个包含Hackage数据库中发布的每个软件包的每个版本的.cabal文件，每个文件大约457兆字节，再加上一些其他文件，总计为1.0个千兆字节

第一个内容在运行stack setup命令时安装；第二个内容在运行stack update命令时安装。

回答你的问题：

这么大显然是因为没有人尝试使它更小，正如整个00-index.tar，00-index.tar.gz和01-index.tar情况所证明的那样。
这是最小安装的正常大小。
如果你从未想过编译带有分析标记的程序，可以删除分析版本（*_p.a文件）。虽然我没有进行广泛测试，但它似乎可以工作。这样做可以节约大约800兆字节。如果你只想使用动态链接程序（即使用ghc -dynamic），则可以删除静态版本（所有*.a文件）。同样，我没有进行广泛测试，但它似乎可以工作。删除动态版本将非常困难-必须找到一种方法，只删除GHC本身不需要的那些*.so文件，并且任何你删除的内容都将无法在解释器中加载。

有几个东西被缓存了，你可以删除它们。例如，你可以删除00-index.tar和00-index.tar.gz（节省约半GB），然后Stack似乎还能正常运行。不过，下次运行stack update的时候，它会重新创建这些文件。我认为这并没有在任何地方有记录，所以确定哪些可以安全地删除会需要大量的试验和错误。

我认为这个问题已经在上面讨论过了。

顺便说一下，前几天我看到一些3TB硬盘的好价钱，兴奋地买了两个，然后才意识到其实我没有什么东西可以放在上面。这应该让几GB大小的文件相对来说显得微不足道了吧？

我想至少在配置不错的桌面机上，不要花太多力气去削减你的.stack目录。如果你在一台相对较小的SSD上工作的笔记本电脑上，考虑把.stack目录放在支持透明压缩的文件系统上（例如Btrfs），如果你认为它可能会变得过于庞大。