Будет ли gtk2hs и wx когда-либо строить более надежно?

Это не напыщенная речь; это технический вопрос.Будет ли gtk2hs и wx когда-либо строить более надежно?

Кодировщики Haskell всех способностей, похоже, согласны с тем, что создание gtk является огромным препятствием. Даже эксперты, кажется, пересекают свои пальцы, когда они устанавливают его. Это большая система со многими компонентами; возраст и версия компонентов сильно зависят от систем, на которых устанавливается gtk; некоторые части и конфигурации полностью различны для разных ОС и т. д.

Являются ли эти технические ограничения, которые будут с нами навсегда? Или существуют другие причины ненадежности сборки, которые могут быть разработаны в будущем?

источник

2012-02-23 amindfv

Я считаю, что это проблема ОС, касающаяся доступности и использования библиотеки; Я никогда не слышал о каких-либо «экспертах», имеющих проблемы с Linux и т. Д. – ivanm

Может быть, некоторые «настоящие» эксперты могут поддержать меня здесь, но лично я поговорил с несколькими, которые согласны с тем, что он часто не будет строить с первой попытки , и занимает много времени. – amindfv

OS X и Windows могут быть хуже, чем Linux, но это мой точный вопрос: насколько вариации в системах пользователей будут приводить к тому, что это никогда не срабатывает, а также насколько ограничены текущие ограничения кода и/или систем сборки? – amindfv

Я думаю, что основная проблема заключается в том, что gtk2hs полагается на ресурсы за пределами области применения Cabal - для правильной работы нужны внешние библиотеки. Cabal отлично подходит для Haskell-only, но он не особенно хорош для поддержки внешних ресурсов и зависимостей.

Я думаю, что лучшая надежда на стабильную конструкцию gtk2hs будет использовать диспетчер пакетов системы, главным образом потому, что эти менеджеры пакетов намного лучше справляются со всеми этими различными зависимостями.

Однако возьмите все, что я сказал, с солью: у меня мало опыта из первых рук; Я основываю свои мысли главным образом на вещах, которые я читал как this post.

источник

2012-02-23 03:29:42

Я не соглашусь с тобой, что кабала замечательная. На самом деле это не так, как функциональность (она не имеет большинства базовых функций деинсталляции) в качестве достойных менеджеров пакетов. – Trismegistos

@Trismegistos: Это потому, что это скорее система сборки, чем менеджер пакетов. Таким образом, он полезен для построения, тестирования и даже делает некоторое базовое разрешение зависимостей, но это все.Вот о чем я связан в статье: P Резюме состоит в том, что вы должны использовать управление пакетами вашей ОС для нетривиальных материалов. –

Gtk2Hs действительно приложил все усилия, чтобы стать намного проще в установке, в настоящее время это очень легко сделать в Windows: вы устанавливаете «все-в-одном-пакет» из GTK, затем «cabal install gtk2hs-buildtools» "then" cabal install gtk ", и он работает ... На linux это не намного сложнее: вам просто нужно установить пакеты разработки для gtk до последовательности cabal.

Я бы не сказал, что это прекрасно и работает каждый раз (некоторые версии GTK следует избегать, хотя и не самые последние), но ситуация сейчас намного лучше, чем в прошлом (до кабализации).

Конечно, основная проблема не в том, что у Haskell во всех этих случаях это происходит с частью C библиотеки, Haskell и Cabal приносят свои проблемы на стол, но они на самом деле не связаны, и я продолжаю надеюсь, что некоторые улучшения в установке cabal и особенно ghc-pkg помогут в будущем (отличная статья, чтобы прочитать о потенциальных проблемах: http://www.vex.net/~trebla/haskell/sicp.xhtml, каждый должен быть вынужден прочитать ее перед тем, как использовать cabal!).

источник

2012-02-23 19:33:31 Jedai

Будет ли gtk2hs и wx когда-либо строить более надежно?

ответ

Смежные вопросы