Построение и создание артефактов на Haskell аналогично Maven

Я долгое время был разработчиком Java, но недавно я присоединился к команде Haskell. В мире Java, если у вас большой проект, над которым работают несколько команд, общий подход заключается в использовании сервера артефактов, такого как Maven, для упрощения и ускорения разработки. Многочисленные инструменты сборки, такие как Ant, Maven, Gradle, могут собрать проект и загрузить файл JAR на сервер артефактов, который может использоваться остальной частью команды безболезненно. Поэтому, разбивая проект на более мелкие подпроекты, время сборки также резко сокращается.

На стороне Haskell, мы используем cabalдля создания проекта. Наш проект занимает около 10-15 минут для сборки без оптимизации. Если оптимизация компилятора включена, это занимает несколько часов, что является болезненным.

Интересно, как мы можем сделать то же самое, что мы делаем в Java здесь? Существует ли простой способ компилировать и загружать двоичные файлы пакетов (библиотек) на сервер артефактов и использовать предварительно собранные двоичные файлы во время сборки? Я знаю, что, поскольку Haskell генерирует машинный код (а не байт-код в Java), могут быть проблемы с совместимостью, но у нас могут быть разные двоичные файлы для разных архитектур / ОС, хранящиеся на сервере артефактов.

— Oxy
источник

Не ответ на ваш вопрос, но вы вызываете «сборку / установку cabal» с опцией -j?

— Даниэль Диас Каррет,

Да, но я не вижу большого ускорения. Загрузка процессора составляет около 15% -20% при сборке. Я не уверен , где проблема: cabal, GHC, Test.Frameworkили линкер.

— Oxy

Согласно этому SO-ответу stackoverflow.com/questions/27173910/… основной причиной является естественная природа исполняемых файлов Haskell.

— Даниэль Диас Каррет

Я в основном говорю о разработке. Это правда, что двоичный код может привести к несовместимости из-за разных ОС, архитектур ЦП и даже версий компилятора. Но зачем мне тратить так много времени, когда я занимаюсь разработкой на одной и той же машине, в одной ОС и в одном и том же компиляторе каждый день?

— Oxy

Похоже, что Halcyon с кешем может быть полезен: halcyon.sh/reference/#private-storage-options

— Lubomír Sedlář

Вы можете подумать об использовании Nix , универсального кроссплатформенного менеджера пакетов с достойной поддержкой Haskell.

В Nix есть собственный язык программирования для определения пакетов (который просто чист, функционален и ленив). Определить новые пакеты и расширить существующие довольно легко (например, изменить зависимости, получить исходный код из другого репозитория git и т. Д.).

Пакеты идентифицируются хэшами, которые включают зависимости. Следовательно, несколько версий или одна и та же версия с разными зависимостями могут жить бок о бок без конфликтов. Nix может найти нужный хеш на сервере «двоичного кэша», чтобы увидеть, был ли уже собран этот конкретный пакет с этими конкретными зависимостями; если это так, он будет загружать продукт сборки, а не компилировать.

В настоящее время репозиторий nixpkgs включает в себя большую часть / все Hackage, несколько версий GHC (7.10.1, 7.8.4 и некоторые бэкэнды JS) и cabal2nixутилиту, которая довольно неплохо работает для генерации пакетов Nix из файлов .cabal. Существует также CI-сервер "hydra" на базе Nix, который можно использовать для запуска сборок на основе фиксации SCM.

— Warbo
источник