gtk2hs和wx會更可靠嗎？

這不是一個咆哮;這是一個技術問題。gtk2hs和wx會更可靠嗎？

所有能力的Haskell編碼器似乎都認爲構建gtk是一個巨大的障礙。即使是專家們在安裝它時也會穿過他們的手指。這是一個有很多組件的大型系統;在gtk正在安裝的系統上，組件的年齡和版本差異很大;一些部件和配置在不同的操作系統上完全不同等。

這些技術限制是否會永遠與我們保持一致？還是還有其他造成不可靠性的原因，可以在未來得到解決？

來源

2012-02-23 amindfv

我相信這是一個關於圖書館的可訪問性和使用的操作系統問題;我從來沒有聽說過任何在Linux上有問題的「專家」，等等。 – ivanm 2012-02-23 04:13:17

也許一些「真正的」專家可以在這裏支持我，但是我親自和幾位同事交談過，他們認爲它經常不會在第一次嘗試，並且需要大量修補 – amindfv 2012-02-23 04:36:04

OS X和Windows可能比Linux更差，但這是我的確切問題：用戶系統中的多少變化將導致此失效，與目前的限制有多大代碼和/或構建系統？ – amindfv 2012-02-23 04:42:18

我認爲一個主要問題是gtk2hs依賴於Cabal範圍之外的資源 - 它需要外部庫正常工作。 Cabal對Haskell而言非常好，但它並不擅長支持外部資源和依賴關係。

我認爲穩定的gtk2hs構建的最大希望是使用系統的包管理器，很大程度上是因爲這些包管理器在處理所有這些不同的依賴關係方面要好得多。然而，把我所說的一切都放在一粒鹽裏：我沒有什麼第一手經驗，我將我的想法主要放在我讀過的東西上，比如this post。

來源

2012-02-23 03:29:42

我不會同意你說cabal很棒。事實上，它不像功能豐富（它缺少最基本的卸載功能）與體面的軟件包管理器一樣。 – Trismegistos 2012-02-25 12:13:44

@Trismegistos：這是因爲它比包管理器更像是一個構建系統。所以它對構建，測試甚至做一些基本的依賴關係解析很有用，但就是這樣。這就是我鏈接到的文章的全部內容：P總結是，您應該使用操作系統的包管理來處理不重要的事情。 – 2012-02-25 19:08:51

Gtk2Hs實際上很容易安裝，現在在Windows上很容易實現：從GTK安裝「all-in-one-package」，然後安裝「cabal install gtk2hs-buildtools 「然後」cabal install gtk「，它可以工作......在Linux上，它並不困難：你只需要在cabal序列之前安裝gtk的開發包。

我不會說這是完美的，並且每次都有效（GTK的某些版本必須避免，儘管不是最新的版本），但情況現在比以前好很多（在切分之前）。

當然，在所有這些情況下，Haskell並不是真正的主要問題，它與庫的C部分有關，Haskell和Cabal將他們自己的困境帶到了桌子上，但它們並沒有真正相關，我繼續希望對cabal-install和尤其是ghc-pkg的一些改進將在未來有所幫助（有關潛在問題的優秀文章：http://www.vex.net/~trebla/haskell/sicp.xhtml，每個人在揮舞cabal之前都應該閱讀它！）。

來源

2012-02-23 19:33:31 Jedai

gtk2hs和wx會更可靠嗎？

回答

相關問題