Środowisko budowania i artefaktów Haskell podobne do Maven

Przez długi czas byłem programistą Java, ale ostatnio dołączyłem do zespołu Haskell. W świecie Java, jeśli masz duży projekt, w którym pracuje kilka zespołów, powszechnym podejściem jest użycie serwera artefaktów, takiego jak Maven, w celu ułatwienia i przyspieszenia rozwoju. Liczne narzędzia do budowania, takie jak Ant, Maven, Gradle, mogą zbudować projekt i przesłać plik jar na serwer artefaktów, z którego reszta zespołu może korzystać bez bólu. Dlatego, dzieląc projekt na mniejsze podprojekty, czas kompilacji jest również znacznie skrócony.

Po stronie Haskell używamy cabaldo budowy projektu. Budowa naszego projektu zajmuje około 10-15 minut bez optymalizacji. Włączenie optymalizacji kompilatora zajmuje kilka godzin, co jest bolesne.

Zastanawiam się, jak możemy zrobić to samo, co tutaj w Javie. Czy istnieje prosty sposób na kompilację i przesłanie pliku binarnego pakietów (bibliotek) na serwer artefaktów i korzystanie z gotowych plików binarnych w czasie kompilacji? Wiem, że ponieważ Haskell generuje kod maszynowy (zamiast kodu bajtowego w Javie), mogą występować problemy ze zgodnością, ale prawdopodobnie możemy mieć różne pliki binarne dla różnych architektur / systemów operacyjnych przechowywane na serwerze artefaktów.

— Oxy
źródło

Nie jest to odpowiedź na twoje pytanie, ale czy przywołujesz „kompilację / instalację cabal” z opcją -j?

— Daniel Díaz Carrete

Tak, ale nie widzę większego przyspieszenia. Zużycie procesora wynosi około 15% -20% podczas budowania. Nie jestem pewien, gdzie jest problem: cabal, GHC, Test.Frameworklub łącznik.

— Oxy

Zgodnie z tą SO odpowiedzią stackoverflow.com/questions/27173910/… głównym powodem jest natywna natura plików wykonywalnych Haskell.

— Daniel Díaz Carrete,

Mówię głównie o rozwoju. Prawdą jest, że pliki binarne mogą powodować niezgodność z powodu różnych systemów operacyjnych, architektur procesorów, a nawet wersji kompilatora. Ale dlaczego miałbym marnować tyle czasu każdego dnia, gdy programuję na tym samym komputerze, w tym samym systemie operacyjnym i tym samym kompilatorze?

— Oxy

Wygląda na to, że Halcyon z pamięcią podręczną może się przydać: halcyon.sh/reference/#private-storage-options

— Lubomír Sedlář

Możesz rozważyć użycie Nix , który jest uniwersalnym, wieloplatformowym menedżerem pakietów z przyzwoitą obsługą Haskell.

Nix ma niestandardowy język programowania do definiowania pakietów (tak się składa, że jest czysty, funkcjonalny i leniwy). Definiowanie nowych pakietów i rozszerzanie istniejących jest dość łatwe (np. Do zmiany zależności, uzyskania źródła z innego repozytorium git itp.).

Pakiety są identyfikowane za pomocą skrótów, które obejmują zależności. Stąd wiele wersji lub ta sama wersja z różnymi zależnościami może żyć obok siebie bez konfliktu. Nix może wyszukać żądany skrót na serwerze „binarnej pamięci podręcznej”, aby sprawdzić, czy ten konkretny pakiet z tymi konkretnymi zależnościami został już zbudowany; jeśli tak, to pobierze kompilację zamiast kompilacji.

Obecnie repozytorium nixpkgs zawiera większość / całość Hackage, kilka wersji GHC (7.10.1, 7.8.4 i niektóre backendy JS) oraz cabal2nixnarzędzie, które wykonuje całkiem dobrą robotę, generując pakiety Nix z plików .cabal. Istnieje również oparty na Nix serwer CI „hydra”, którego można użyć do uruchamiania kompilacji opartych na zatwierdzeniach SCM.

— Warbo
źródło