а это cabal-library или stack не умеет работать с файлами, у меня периодически VM-ка прибивается OOM-киллером пока stack там что-то собирает (при кабал-инсталл такого не было), так вот с вероятностью практически 1, он убивает свою базу пакетов, что меня очень печалит.
а вот stack или cabal осилят сбилдить следующие зависимости:
A.cabal
library
...
executable test-stuff
build-depends: B
B.cabal
library
build-depends: A
т.е. в пакете A есть библиотека, и исполняемый файл зависящий от пакета B, зависящего от билиотеки A.
Есть докер файл, в нём:
COPY my-project.cabal /opt/server
RUN cd /opt/server && cabal install --dependencies-only
что позволяет мне в случае если зависимости не изменились, а код изменился не пересобирать layer.
Теперь я хочу разбить проект на куски и радостно собирать его stack-ом, но тут возникает засада, ту же самую фишку я уже провернуть не могу, т.к. просто install --dependencies-only там уже нету.
Что делать?
как бы скачать все зависимости пакета автоматом?
cabal install --dependencies-only не подходит
сам пакет не установлен, но имеется cabal.config сделанный через cabal freeze --enable-tests
Зачем надо: с поставляемого образа пакет будет ставиться в сетке, где не будет доступа к hackage, соотвественно нужно гарантировать, чтобы сборка не обращалась к hackage.
как получить cabal-1.22 на системе с ghc-7.6 не поломав базу?
Вариант: склонировать cabal, собрать его при помощи ghc Setup.hs .. и т.д. установить его, потом с помощью утановленного cabal сделать песочницу и установить кабал в песочницу, котом удалить ~/.cabal и ~/.ghc выглядит каким-то адом.
Убунтуспецифичный вариант принимается, т.к. в нормальных системах проблема решается проще.
А что хуков для cabal check не бывает?
и куда бы тогда запихнуть дополнительные всякие тесты, типа проверки лицензий изменяемых файлов и прочую дребедень, которую в проекте бы хорошо иметь, но при этом пускать не всегда
а как при cabal install foo делать разным задать разные флаги разным пакетам?
а хаддок билдит же либу чтобы сгенерить документацию, т.е. документация с ffi либой на хакадже не сгенерится и надо самому заливать?
а как --enable-library-coverage у cabal работает, оно мержит результаты собранные со всех тестов или нет? если нет, то как автоматизировать? и можно ли summary в .txt получить?
А кабал оказывается не видит измений в .hs-boot файлах, и нужно cabal clean делать.. репорт чтоли отослать..
Такое ощущение что sandbox-ы и вообще половина реализации cabal принадлежит знатному извращенцу, возможно конечно были причины именно такого подхода. Но это что-то.. кто не верит попробуйте сделать мегапроект содержащий в себе подпроекты с зависимостями др. на друга, которые нужно пересобирать и запускать их тесты, всё это усложняется тем, что нужно собирать в двух вариантах (с разными настройками окружения и флагами).
такие дела..
Warning: This package indirectly depends on multiple versions of the same
package. This is highly likely to cause a compile failure.
package distributed-process-tests-0.4 requires network-transport-0.3.0.1
package distributed-process-0.4.2 requires network-transport-0.3.0.1
package network-transport-tcp-0.3.1 requires network-transport-0.3.0.1
как нынче модно делать coverage репорты, через --enable-hpc и прогонку тестов, или кустарными скриптами?
а кто-нить в курсе можно ли при установке в cabal выдернуть переменные из pkg-config и сложить их в константу?
а как принято простым образом добавить патч к программе ставящейся во время cabal install --only-dependencies?