Environnement de construction et d'artefacts Haskell similaire à Maven

20

J'étais développeur Java depuis longtemps, mais récemment, j'ai rejoint une équipe Haskell. Dans le monde java, si vous avez un grand projet, avec plusieurs équipes qui y travaillent, une approche courante consiste à utiliser un serveur d'artefacts tel que Maven pour faciliter et accélérer le développement. De nombreux outils de génération, tels que Ant, Maven, Gradle, peuvent générer le projet et télécharger un fichier jar sur le serveur d'artefacts qui peut être utilisé par le reste de l'équipe sans douleur. Par conséquent, en divisant le projet en sous-projets plus petits, le temps de construction est également considérablement réduit.

Du côté de Haskell, nous utilisons cabalpour construire le projet. Notre projet prend environ 10-15 minutes à construire sans optimisation. Cela prend quelques heures si l'optimisation du compilateur est activée, ce qui est pénible.

Je me demande comment nous pouvons faire la même chose que nous faisons ici en Java. Existe-t-il un moyen facile de compiler et de télécharger le binaire des packages (bibliothèques) sur un serveur d'artefacts et d'utiliser les binaires précompilés au moment de la construction? Je sais que puisque Haskell génère du code machine (plutôt que du code octet en Java), il peut y avoir des problèmes de compatibilité, mais nous pouvons probablement avoir différents binaires pour différentes architectures / OS stockés sur le serveur d'artefacts.

java haskell maven build-system Oxy
la source
Pas une réponse à votre question mais, invoquez-vous "cabal build / install" avec l'option -j?
Daniel Díaz Carrete
Oui, mais je ne vois pas beaucoup d'accélération. L'utilisation du processeur est d'environ 15% à 20% lors de la construction. Je ne sais pas où le problème est: cabal, GHC, Test.Frameworkou l'éditeur de liens.
Oxy
Selon cette réponse SO stackoverflow.com/questions/27173910/… la raison principale est la nature native des exécutables Haskell.
Daniel Díaz Carrete
Je parle surtout de développement. Il est vrai que le binaire peut provoquer une incompatibilité en raison de différents OS, architectures CPU et même des versions de compilateur. Mais pourquoi devrais-je perdre autant de temps quand je développe tous les jours sur la même machine, le même système d'exploitation et le même compilateur?
Oxy
Il semble que Halcyon avec un cache pourrait être utile: halcyon.sh/reference/#private-storage-options
Lubomír Sedlář

Réponses:

2

Vous pourriez envisager d'utiliser Nix , qui est un gestionnaire de packages multi-plateforme à usage général avec un support décent pour Haskell.

Nix a un langage de programmation personnalisé pour définir des packages (qui se trouve être pur, fonctionnel et paresseux). Définir de nouveaux paquets et étendre ceux qui existent est assez facile (par exemple pour modifier les dépendances, obtenir la source d'un autre dépôt git, etc.).

Les packages sont identifiés par des hachages, qui incluent des dépendances. Ainsi, plusieurs versions, ou la même version avec des dépendances différentes, peuvent vivre côte à côte sans conflit. Nix peut rechercher le hachage souhaité sur un serveur de "cache binaire", pour voir si ce paquet particulier avec ces dépendances particulières a déjà été construit; si tel est le cas, il télécharge le produit de génération plutôt que de le compiler.

Actuellement, le référentiel nixpkgs comprend la plupart / la totalité du Hackage, plusieurs versions de GHC (7.10.1, 7.8.4 et certains backends JS) et un cabal2nixutilitaire qui fait un très bon travail de génération de packages Nix à partir de fichiers .cabal. Il y a aussi le serveur CI "hydra" basé sur Nix, que vous pouvez utiliser pour déclencher des builds basés sur des validations SCM.

Warbo
la source