← All posts tagged cabal

А никто не задавался вопросом, как кастомный build-tool подцепить к cabal-файлу? Какой-нибудь левый кодогенератор, например (несмотря на слабую нужность такого для хацкеля). Ведь всякие hsc2hs и alex-ы цепляются...

а cabal-debian оказался даж юзабельным, правда зависимости пришлось задаунгрейдить (Дэвид обещает скоро новую версию выпустить с актулными версиями), ну и c2hs оно не подцепило из build-tools (пришлось строчку в depends добавить), лончпад, правда, сфейлил libssh2-hs сбилдить под i386, но он вроде пока не особо нужен и вопрос к самой библиотеке

или я чот не понимаю или это какой-то косяк в Cabal (или cabal-dev) — проблемы с линковкой решились выкидыванием hs-source-dirs: test и указанием полного пути от корня

а никто не делал кабальный test-suite с линкуемыми либами? ощущение, что cabal кладёт болт на pkgconfig-depends для этой секции — линкер не может собрать тесты. Флажок -lMyLib в ghc-options тоже не помогает. Есть ещё варианты заставить его собираться?

новый cabal-install, конечно, получше будет, чем старый: предупреждает, что зависимые пакеты могут сломаться при установке/апгрейде какого-нибудь пакета. Проблемы становятся более видимыми, но в итоге один хрен приходится руками выправлять зависимости — делать ghc-pkg unregister старым версиям и т.п. До нирваны пока не добрались

а кто-нибудь обладает тайным знанием как использовать локальные зависимые пакеты cabal? Т.е. если packageB зависит от packageA, чтоб изменения можно было просто подцепить. Пока через cabal-dev получается геморойно: cabal-dev install <relative-path>/packageA; cabal-dev configuire; cabal-dev build. Да ещё в haskell-mode REPL приходится перегружать.

а никто не подскажет, как корректно удавить лишнюю зависимость от shared library, которая пришла из другого пакета и которая в реальности 100% не используется?