Entorno de construcción y artefactos de Haskell similar a Maven

Solía ser desarrollador de Java durante mucho tiempo, pero recientemente me uní al equipo de Haskell. En el mundo de Java, si tiene un proyecto grande, con varios equipos trabajando en él, un enfoque común es utilizar un servidor de artefactos como Maven para facilitar y acelerar el desarrollo. Numerosas herramientas de compilación, como Ant, Maven, Gradle, pueden compilar el proyecto y subir un archivo jar al servidor de artefactos que el resto del equipo puede usar sin problemas. Por lo tanto, al dividir el proyecto en subproyectos más pequeños, el tiempo de construcción también se reduce drásticamente.

En el lado de Haskell, estamos utilizando cabalpara construir el proyecto. Nuestro proyecto tarda entre 10 y 15 minutos en construirse sin optimización. Tarda unas horas si la optimización del compilador está activada, lo cual es doloroso.

Me pregunto cómo podemos hacer lo mismo que hacemos en Java aquí. ¿Hay una manera fácil de compilar y cargar el binario de los paquetes (bibliotecas) a un servidor de artefactos y usar los binarios precompilados en el momento de la compilación? Sé que dado que Haskell genera código de máquina (en lugar de código de byte en Java) puede haber problemas de compatibilidad, pero probablemente podamos tener diferentes binarios para diferentes arquitecturas / sistemas operativos almacenados en el servidor de artefactos.

— Oxi
fuente

No es una respuesta a tu pregunta pero, ¿invocas "cabal build / install" con la opción -j?

— Daniel Díaz Carrete

Sí, pero no veo mucha aceleración. El uso de la CPU es de alrededor del 15% -20% al construir. No estoy seguro de dónde está el problema: cabal, GHC, Test.Frameworko el enlazador.

— Oxy

De acuerdo con esta respuesta SO stackoverflow.com/questions/27173910/…, la razón principal es la naturaleza nativa de los ejecutables de Haskell.

— Daniel Díaz Carrete

Estoy hablando principalmente de desarrollo. Es cierto que el binario puede causar incompatibilidad debido a diferentes sistemas operativos, arquitecturas de CPU e incluso versiones de compilador. Pero, ¿por qué debería perder tanto tiempo cuando estoy desarrollando en la misma máquina, el mismo sistema operativo y el mismo compilador todos los días?

— Oxy

Parece que Halcyon con un caché podría ser útil: halcyon.sh/reference/#private-storage-options

— Lubomír Sedlář

Puede considerar usar Nix , que es un administrador de paquetes multiplataforma de propósito general con un soporte decente para Haskell.

Nix tiene un lenguaje de programación personalizado para definir paquetes (que resulta ser puro, funcional y vago). Definir nuevos paquetes y ampliar los existentes es bastante fácil (por ejemplo, alterar dependencias, obtener la fuente de un repositorio de git diferente, etc.).

Los paquetes se identifican mediante hashes, que incluyen dependencias. Por lo tanto, varias versiones, o la misma versión con diferentes dependencias, pueden convivir sin conflicto. Nix puede buscar el hash deseado en un servidor de "caché binario", para ver si ese paquete particular con esas dependencias particulares ya se ha creado; si es así, descargará el producto de compilación en lugar de compilarlo.

Actualmente, el repositorio de nixpkgs incluye la mayoría / todo de Hackage, varias versiones de GHC (7.10.1, 7.8.4 y algunos backends JS) y una cabal2nixutilidad que hace un trabajo bastante bueno al generar paquetes Nix a partir de archivos .cabal. También está el servidor CI "hydra" basado en Nix, que podría usar para activar compilaciones basadas en confirmaciones SCM.

— Warbo
fuente