Ambiente di compilazione e artefatto di Haskell simile a Maven

Ero uno sviluppatore Java per molto tempo, ma recentemente mi sono unito a un team di Haskell. Nel mondo Java, se hai un grande progetto, con diversi team che ci lavorano, un approccio comune è quello di utilizzare un server artefatto come Maven per facilitare e accelerare lo sviluppo. Numerosi strumenti di costruzione, come Ant, Maven, Gradle, possono costruire il progetto e caricare un file jar sul server degli artefatti che può essere utilizzato dal resto del team senza problemi. Pertanto, suddividendo il progetto in sottoprogetti più piccoli, il tempo di costruzione viene drasticamente ridotto.

Sul lato Haskell, stiamo usando cabalper costruire il progetto. Il nostro progetto richiede circa 10-15 minuti per essere sviluppato senza ottimizzazione. Ci vogliono alcune ore se l'ottimizzazione del compilatore è attiva, il che è doloroso.

Mi chiedo come possiamo fare la stessa cosa che facciamo qui in Java. Esiste un modo semplice per compilare e caricare il file binario dei pacchetti (librerie) su un server artefatto e utilizzare i file binari predefiniti al momento della compilazione? So che poiché Haskell genera codice macchina (piuttosto che codice byte in Java) potrebbero esserci problemi di compatibilità, ma probabilmente possiamo avere binari diversi per architetture / sistemi operativi diversi memorizzati sul server artefatto.

— Oxy
fonte

Non è una risposta alla tua domanda, ma invochi "cabal build / install" con l'opzione -j?

— Daniel Díaz Carrete,

Sì, ma non vedo molta velocità. L'utilizzo della CPU è di circa il 15% -20% durante la costruzione. Non sono sicuro dove il problema è: cabal, GHC, Test.Frameworko il linker.

— Oxy,

Secondo questa risposta SO stackoverflow.com/questions/27173910/… il motivo principale è la natura nativa degli eseguibili Haskell.

— Daniel Díaz Carrete,

Parlo principalmente di sviluppo. È vero che il binario può causare incompatibilità a causa di diversi sistemi operativi, architetture della CPU e persino versioni del compilatore. Ma perché dovrei perdere così tanto tempo quando sto sviluppando sulla stessa macchina, sullo stesso sistema operativo e sullo stesso compilatore ogni giorno?

— Oxy

Sembra che Halcyon con una cache possa essere utile: halcyon.sh/reference/#private-storage-options

— Lubomír Sedlář

Potresti prendere in considerazione l'uso di Nix , che è un gestore di pacchetti multipiattaforma per tutti gli usi con un supporto decente per Haskell.

Nix ha un linguaggio di programmazione personalizzato per la definizione dei pacchetti (che sembra essere puro, funzionale e pigro). Definire nuovi pacchetti ed estendere quelli esistenti è abbastanza semplice (ad es. Per modificare le dipendenze, ottenere il sorgente da un diverso repository git, ecc.).

I pacchetti sono identificati da hash, che includono dipendenze. Quindi più versioni, o la stessa versione con dipendenze diverse, possono vivere fianco a fianco senza conflitti. Nix può cercare l'hash desiderato su un server "cache binaria", per vedere se quel particolare pacchetto con quelle particolari dipendenze è già stato creato; in tal caso, scaricherà il prodotto build anziché la compilazione.

Attualmente, il repository nixpkgs include la maggior parte / tutto Hackage, diverse versioni di GHC (7.10.1, 7.8.4 e alcuni backend JS) e cabal2nixun'utilità che fa un buon lavoro nel generare pacchetti Nix da file .cabal. C'è anche il server CI "hydra" basato su Nix, che potresti usare per innescare build basate su commit SCM.

— Warbo
fonte