这不是咆哮;这是一个技术问题。
所有能力的Haskell程序员似乎都同意构建gtk是一个巨大的障碍。甚至专家们在安装它们时似乎也会用手指交叉。这是一个包含许多组件的大型系统;在安装gtk的系统上，组件的年龄和版本变化很大;某些部分和配置在不同的操作系统等上完全不同。
这些技术限制是否会永远存在？或者是否存在构建不可靠的其他原因，可以在将来解决？
答案 0 :(得分：2)
我认为一个主要问题是gtk2hs依赖于Cabal范围之外的资源 - 它需要外部库才能正常工作。 Cabal非常适合仅限Haskell的东西，但它在支持外部资源和依赖性方面并不是特别擅长。
我认为稳定的gtk2hs构建的最大希望是使用系统的包管理器，主要是因为这些包管理器在处理所有这些不同的依赖项方面要好得多。
然而，把我所说的一切都拿出来：我没有第一手经验;我的想法主要基于我读过的this post。
答案 1 :(得分：1)
Gtk2Hs实际上已经很容易安装，目前在Windows上很容易这样做：你从GTK安装“all-in-one-package”，然后“cabal install gtk2hs-buildtools”那么“cabal install gtk”就行了......在linux上它并不难：你只需要在cabal序列之前安装gtk的开发包。
我不会说这是完美的并且每次都有效（有些版本的GTK必须避免，尽管不是最新版本），但现在的情况要好过去（在cabalization之前）
当然主要的问题不是Haskell在所有这些情况下都是如此，它与库的C部分有关，Haskell和Cabal带来了他们自己的困境，但他们并没有真正相关，我仍然希望对cabal-install，特别是ghc-pkg的一些改进将来会有所帮助（阅读有关潜在问题的优秀文章：http://www.vex.net/~trebla/haskell/sicp.xhtml，每个人都应该在挥舞阴谋之前阅读它！）。