2017-09-30 18 views
1

Ich habe eine Testsuite und eine Benchmark-Suite, die die GHC-API verwendet, um Module zu Core zu kompilieren, so dass ich Core 'by hand' nicht schreiben muss.Zugriff auf GHC-Paketdatenbank in Test- und Benchmark-Suite

Ich verwende an dieser Stelle meistens stack, wo ich einfach auf die Umgebungsvariable GHC_PACKAGE_PATH in der Testsuite (stack test) zugreifen konnte, um eine Paketdatenbank zu finden, mit der ich die GHC API füttern kann. Beachten Sie, dass es nicht so sehr darum geht, dass ich irgendeine bestimmte db betrachte, ich möchte nur Module von z. base verfügbar, kompiliert mit einer kompatiblen Version von GHC (z. B. GHC.Paths.ghc).

Alles funktioniert soweit, Tests sind grün. Nun, wenn ich das gleiche für die Benchmark-Suite (stack bench) mache, scheint GHC_PACKAGE_PATH überhaupt nicht vorhanden zu sein.

Lange Rede, kurzer Sinn, was ist eine zuverlässige Methode, um den Pfad zur GHC-Paketdatenbank zu erfassen, mit der das Programm erstellt wurde? Ich stelle mir vor, dass etwas Unsinn mit Setup.hs mich dahin bringen könnte, wo ich sein möchte.


Edit: Hier ist etwas zu spielen, um: https://github.com/sgraf812/ghc-package-path

stack test druckt den Wert von GHC_PACKAGE_PATH, während stack bench nicht der Fall ist. Eine Antwort auf diese Frage sollte dazu führen, dass in beiden Fällen ein Pfad zu einer geeigneten Paketdatenbank ausgedruckt wird.

+1

Vielen Dank für den Bericht, ich habe dieses Problem geöffnet: https://github.com/commercialhaskell/stack/issues/3462 – mgsloan

+0

@mgsloan Vielen Dank für die Behebung dieses Problems! Nichtsdestotrotz bin ich an einer Lösung interessiert, die auch für Cabal-Installation funktioniert. Wenn ich mir den Code von ghc-mod anschaue, gibt es wahrscheinlich nicht wirklich eine Lösung, denke ich, aber ich denke, diese Situation ist wirklich nervig und es sollte eine Art Paket dafür geben (wie 'ghc-paths') kein Standard im Ökosystem. –

+0

@mgsloan Also, was wäre die beste Problemumgehung? Ich durchforstete den 'stack'-Quellcode und schaute mir an, wie' mkGhcPackagePath' aufgerufen wurde. Es scheint, als müsste ich eine 'EnvConfig' in die Hand nehmen, um' packageDatabaseLocal' zu nennen. Was wäre der einfachste Weg? –

Antwort

0

Die richtige Lösung erscheint eine benutzerdefinierte Setup.hs anhalten das withPackageDB Feld des LocalBuildInfo nach configure zu verwenden zu sein.

Lucky me gefunden cabal-toolkit, von denen ich Version 0.0.3 geändert, um auch mit Cabal 1.24 (und GHC 8.0.2) to be found here zu arbeiten, bis es verschmolzen ist.

Das Erhalten der packageDBFlags/extraPkgConf ist nur eine Frage des Anrufs getGHCPackageFlags $(localBuildInfoQ).

Verwandte Themen