gtk2hs 和 wx 的构建会更加可靠吗?

发布于 2025-01-08 11:00:34 字数 206 浏览 1 评论 0原文

这不是咆哮;这是一个技术问题。

所有能力的 Haskell 程序员似乎都同意构建 gtk 是一个巨大的障碍。即使是专家在阴谋集团安装它时也似乎会祈祷。这是一个包含许多组件的大型系统;在安装 gtk 的系统上,组件的年龄和版本差异很大;有些部件和配置在不同的操作系统上完全不同,等等。

这些技术限制会永远伴随我们吗?或者是否有其他导致构建不可靠性的原因可以在将来解决?

This is not a rant; it's a technical question.

Haskell coders of all abilities seem to agree that building gtk is a huge hurdle. Even experts seem to cross their fingers when they cabal-install it. It's a large system with many components; the age and version of the components varies wildly on the systems gtk is being installed on; some pieces and configurations are completely different on different OSes, etc.

Are these technical limitations that will be with us forever? Or are there other causes of build-unreliability, that can be worked out in the future?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

月牙弯弯 2025-01-15 11:00:34

我认为一个主要问题是 gtk2hs 依赖于 Cabal 范围之外的资源——它需要外部库才能正常工作。 Cabal 非常适合仅使用 Haskell 的东西,但它并不是特别擅长支持外部资源和依赖项。

我认为稳定 gtk2hs 构建的最大希望是使用系统的包管理器,很大程度上是因为这些包管理器在处理所有这些不同的依赖关系方面要好得多。

然而,请对我所说的一切持保留态度:我没有什么第一手经验;我的想法主要基于我读过的东西,例如 这篇文章

I think a major issue is that gtk2hs relies on resources outside of the scope of Cabal--it needs external libraries to work properly. Cabal is great for Haskell-only stuff, but it is not particularly good at supporting external resources and dependencies.

I think the best hope for a stable gtk2hs build would be using the system's package manager, largely because these package managers are much better at handling all these different dependencies.

However, take everything I've said with a grain of salt: I have little first-hand experience; I'm basing my thoughts mainly off stuff I've read like this post.

安静被遗忘 2025-01-15 11:00:34

Gtk2Hs 实际上做了很大的努力,变得更容易安装,目前在 Windows 上很容易做到这一点:您安装 GTK 的“all-in-one-package”,然后“cabal install gtk2hs-buildtools”,然后“cabal安装 gtk”,它就可以工作了...在 Linux 上,这并不难:您只需要在 cabal 序列之前安装 gtk 的开发包即可。

我不会说这是完美的并且每次都有效(必须避免 GTK 的某些版本,尽管不是最新的),但现在的情况比过去(阴谋集团化之前)要好得多。

当然,在所有这些情况下,主要问题并不是真正的 Haskell,而是库的 C 部分,Haskell 和 Cabal 带来了自己的困境,但它们并没有真正相关,我仍然希望有一些改进cabal-install,尤其是 ghc-pkg 将在未来有所帮助(关于潜在问题的优秀文章:http://www.vex.net/~trebla/haskell/sicp.xhtml,每个人在使用阴谋集团之前都应该强制阅读它!)。

Gtk2Hs actually made a good effort to become much easier to install, it is currently very easy to do so on Windows : You install the "all-in-one-package" from GTK, then "cabal install gtk2hs-buildtools" then "cabal install gtk" and it works... On linux it's not much harder : you just need to install the development packages for gtk before the cabal sequence.

I would not say this is perfect and works each and every time (some versions of GTK have to be avoided, though not the most recent), but the situation is now much better than it was in the past (before cabalization).

Of course the main problem is not really with Haskell in all those cases, it is with the C part of the library, Haskell and Cabal bring their own woes to the table but they're not really related and I continue to hope that some improvements to cabal-install and especially ghc-pkg will help in the future (excellent article to read on the potential problems : http://www.vex.net/~trebla/haskell/sicp.xhtml , every one should be forced to read it before wielding cabal !).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文