Хаскелл будує і артефактне середовище схоже на Мейвен

Я довго був розробником Java, але нещодавно я приєднався до команди Haskell. У світі java, якщо у вас великий проект, де над ним працюють декілька команд, загальним підходом є використання сервера артефактів, такого як Maven, для полегшення та прискорення розвитку. Численні інструменти збирання, такі як Ant, Maven, Gradle, можуть скласти проект та завантажити файл jar на сервер артефактів, який може без особливих зусиль використовувати решта команди. Тому, розділяючи проект на менші підпроекти, час збирання також різко скорочується.

З боку Haskell ми використовуємо cabalдля побудови проекту. Нашому проекту потрібно приблизно 10–15 хвилин, щоб не робити оптимізації. Якщо ввімкнено оптимізацію компілятора, це боляче, що займає кілька годин.

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

— Окси
джерело

Не відповідь на ваше запитання, але ви посилаєтесь на "збірку / встановлення кабалу" за допомогою параметра -j?

— Даніель Діас Каріт

Так, але я не бачу великих прискорень. Використання процесора становить близько 15% -20% під час створення. Я не впевнений , де проблема: cabal, GHC, Test.Frameworkабо лінкер.

— Окси

Відповідно до цієї відповіді ТА, stackoverflow.com/questions/27173910/… головною причиною є рідний характер виконуваних файлів Haskell.

— Даніель Діас Каріт

Я в основному кажу про розвиток. Це правда, що бінарне може спричинити несумісність через різні ОС, архітектури процесора та навіть версії компілятора. Але чому я повинен витрачати стільки часу, коли я розробляю на одній і тій же машині, одній і тій же ОС і того ж компілятора?

— Окси

Схоже, Halcyon з кешем може бути корисним: halcyon.sh/reference/#private-storage-options

— Lubomír Sedlář

Ви можете подумати про використання Nix , який є менеджером пакетних пакетів загального призначення з гідною підтримкою Haskell.

У Nix є власна мова програмування для визначення пакетів (які так просто бувають чистими, функціональними та ледачими). Визначити нові пакети та розширити існуючі досить просто (наприклад, щоб змінити залежності, отримати джерело з іншого git repo тощо).

Пакети ідентифікуються хешами, які включають залежності. Отже, кілька версій або одна і та ж версія з різними залежностями можуть жити поряд без конфлікту. Nix може шукати потрібний хеш на сервері "бінарного кеша", щоб перевірити, чи вже створений цей конкретний пакет із цими залежностями; якщо так, то ви завантажуєте збірний продукт, а не компілюєте.

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

— Варбо
джерело