Jaki jest oficjalny sposób instalacji Haskell Platform 2014, od źródła, na Red Hat?

Question

Próbuję zainstalować Haskell Platform 2014.2.0.0 ze źródła na Red Hat Enterprise Linux 6.5. Mam funkcjonalną instalację Haskell Platform 2012.4.0.0 i GHC 7.4.2 sprzed dwóch lat, a także niedawno zainstalowaną Haskell Platform 2013.2.0.0 i GHC 7.6.3 z JustHub.

Zbudowałem GHC 7.8.3 ze źródła, ale wciąż pojawia się siedem błędów w pakiecie testowym. Nie mam pojęcia, czy te niepowodzenia testu są nieszkodliwe, czy nie. (Błędy testowe nie są istotne dla mojego pytania, ale mogą później stać się znaczące).

Rozpakowuję archiwum źródłowe 2014.2.0.0, przeczytaj README. Mówi, że droga do zbudowania tego iteracji Haskell jest ze skryptu powłoki, która jest wywołana

./platform.sh $ PATH_TO_GHC_BINDIST_TARBALL

ja nie mam GHC dystrybucji binarnej archiwum. O ile jestem w stanie powiedzieć, nie ma żadnego archiwum dystrybucyjnego binarnego GHC 7.8.3 dla dowolnej wersji Red Hat Enterprise Linux. Mam zbudowany GHC 7.8.3. Jak mam powiedzieć platform.sh - lub cokolwiek jest pod nim - że nie ma tarballa i powinien on po prostu użyć tego, co jest w $ PATH? Alternatywnie, w jaki sposób mogę spakować istniejącą instalację GHC 7.8.3, aby platform.sh ją zaakceptował?

Zbudowany GHC nie ma polecenia "kabała", więc komendy cab w platform.sh spadają do zmiennej $ PATH, którą mogę skonfigurować jako jedną z pozostałych zainstalowanych wersji (2013.2/7.6.3 lub 2012.4/7.4.2). Wydaje się, że nie robi to różnicy: żaden nie rozpoznaje "cabal -sandbox". Oba skutkują skargami, że powinienem uruchomić "cd hptool; cabal install --only-dependencies ', które wielokrotnie robiłem. platform.sh nigdy nie przechodzi przez ten punkt.

Jeśli uruchamiam polecenia w platform.sh ręcznie, otrzymuję polecenie "cd hptool; cabal build ', którego błędy są poza: "cabal-1.16.0.2: Najpierw uruchom polecenie" configure ".". Ale nie ma polecenia "configure" dostępnego w katalogu hptool.

Utknąłem. Jak zbudować platformę Haskell 2014 na RHEL 6?

Answer 1

Musisz użyć swoich źródeł GHC, aby stworzyć własną "bindistę". Wskazówki pod adresem https://ghc.haskell.org/trac/ghc/wiki/MakingReleases

Answer 2

Udało mi się zainstalować i funkcjonować platformę Haskell. Skończyło się porzucenie platformy .sh i ręczne zainstalowanie wszystkich pakietów w archiwum platformy Haskell - i ich zależności - za pomocą ręcznych poleceń cabal. Wraz ze zepsutą platformą.sh napotkałem wiele problemów po drodze.

Te, które pamiętam:

• platform.sh nigdy nie uda, jeśli masz akcji Haskell Platform 2013 lub poprzedniego zainstalowany. Chce cabal, który rozpoznaje opcję "--sandbox", a Cabal 1.18 nie zna tej opcji. Musisz mieć zainstalowaną nowszą kabałę od Haskell Platform 2013. (Wydaje się, że GHC 7.4 lub 7.6 jest w porządku.)

• Posiadałem istniejący katalog .cabal i .ghc, który zawiera niekompatybilne kompilacje i/lub wersje różnych pakietów. Podczas testowania rzeczy wielokrotnie kasowałem oba katalogi.

• Instalacja cabal --global zachowuje się zupełnie inaczej niż domyślna instalacja cab - user. .cabal zawierało coś pożytecznego po tym, jak zrobiłem "cabal install cabal-install". Zajęło to dwie lub trzy próby ustalenia, gdzie znalazła się nowa binarna kabina.

• ghc i cabal podnoszą nowe biblioteki w plikach .ghc i .cabal, ale nie nowych plików binarnych.

• Ani GHC ani cabal nie instalują domyślnie opcji --enable-shared, chyba że coś jej chce. Musiałem przebudować wszystko wcześniej - wracając do samego GHC 7.8.3 - z opcją --enable-shared, kiedy to się stało.

• łupacz jest niedorzecznie ściśle związany z wersją GHC, z której została zbudowana. Musiałem go przebudować, aby uzyskać możliwą do zainstalowania dokumentację do wszystkiego, co zostało zbudowane przy pomocy GHC 7.8.3.

• Pakiety testowe i pakiet tekstowy są tak ściśle zintegrowane, że mają okrężne zależności, jeśli próbujesz zrobić "tekst instalacji kablowo-testowej". Nawet po zainstalowaniu najnowszej wersji tekstu i pakietów testowych, cabal nadal nie uruchomił pakietu testów tekstowych, więc zrezygnowałem i zainstalowałem tekst bez testowania go.

• Moje domyślne środowisko obejmuje "LC_ALL = C". Wywołuje to znany błąd w cabal - najwyraźniej we wszystkich wersjach - który łamie niektóre kompilacje pakietów. Aby obejść to, musiałem przenieść go do "LC_ALL = en_US.utf8". Nie mam pojęcia, czy pakiety dotknięte będzie działać, jeśli masz LC_ALL lub którykolwiek z pozostałych zmiennych locale takich jak LANG lub LC_ < cokolwiek innego >, zestaw do C

• Cabal zainstalować --global jest strasznie niespójne o gdzie pakiety są przechowywane. Rozdzieliliśmy poszczególne pakiety na ich własne podkatalogi, a następnie zbudowaliśmy drzewo dowiązań symbolicznych w znanym miejscu poza tymi wszystkimi podkatalogami. Więc ghc znajduje się w jego własnym podkatalogu /usr/sup/ghc-7.8.3; Platforma Haskell znajduje się w innym podkatalogu, /usr/sup/haskell-platform-2014.2.0.0. Konsekwentnie używałem --prefix =/usr/sup/haskell-platform-2014.2.0.0 na każdej komendzie "cabal install", ale nawet wtedy niektóre biblioteki kończyły się na /usr/sup/ghc-7.8.3.

• Zarówno platforma GHC, jak i Haskell mają słownik tego, co jest zbudowane i gdzie jest - być może jako obejście dla niespójności lokalizacji instalacji - w /usr/sup/ghc-7.8.3/lib/ghc-7.8 .3/package.conf.d/package.cache. Jeśli ten słownik pakietu nie jest czytelny dla świata, ghc się zepsuje. Co należy zrobić, to sprawdzić rzeczywistą strukturę plików, aby znaleźć rzeczy. Biorąc pod uwagę, że ghc ulegnie uszkodzeniu, jeśli słownik nie będzie dostępny, plik nie powinien być nazywany "pamięcią podręczną", ponieważ brak pamięci podręcznej nie powinien powodować katastrofy. Być może zmień nazwę na "pakiet-obowiązkowy-słownik"?

Ostatecznie wszystko zostało zainstalowane, ale muszę się zastanowić, jakie szkody wyrządziłem od uderzania głową w ścianę.