Wie werden zwei verschiedene Compiler für verschiedene Ziele in einer CABAL-Datei verwendet?

Question

Wenn ich cabal build ausführen, verwendet es einige Haskell-Compiler, um die ausführbaren Dateien und/oder Testsuiten in meiner CABAL-Datei zu erstellen.

Kann ich steuern, welcher Compiler für die verschiedenen Ziele verwendet wird? Idealerweise hätte ich gerne separate Build-Ziele, die ghc und ghcjs in derselben .cabal Datei verwenden. Es scheint mir, dass jemand ghc und Umarmungen oder zwei Versionen von ghc im selben Projekt verwenden möchte. Ist das derzeit möglich?

Wie entscheidet cabal auch, welchen Compiler zu verwenden, wenn cabal build ausgeführt wird? Ich sah, dass es eine Compiler-Option in meiner ~/.cabal/config Datei gibt, aber es von ghc zu ghcjs zu ändern und es auskommentieren, schien nicht zu ändern, was cabal build tut.

Answer 1

Der zu verwendende Compiler wird während des Konfigurationsschritts (oder während des impliziten Konfigurationsschritts eines Installationsschritts, der die Konfigurationsoptionen nicht mit einem vorherigen Konfigurationsschritt teilt) ermittelt. Es wird auch von der Entität festgelegt, die das Paket erstellt, und kann nicht von der Person, die das Paket schreibt, beeinflusst werden. Wahrscheinlich ist dir passiert, dass ein vorheriger Cabal-Build implizit den configure-Schritt aufgerufen und einen Compiler gewählt hat; Zukünftige Builds behalten eine vorherige Auswahl des Compilers über einen, der in Ihrer globalen Konfigurationsdatei steckt. Sie können dies rückgängig machen, indem Sie einfach erneut manuell ausführen.

Es ist möglich, einen Build mit der falschen Implementierung fehlzuschlagen, z.

library 
    if impl(ghc) 
     buildable: False 

wird verhindern, dass Cabal versucht, das Paket mit GHC zu bauen. Dies ist jedoch nicht wirklich nützlich, um separate Teile eines Pakets mit separaten Compilern zu erstellen, da cabal die Installation eines Pakets ablehnen wird, es sei denn, es kann das Ganze mit einem einzigen Compiler erstellen.

Wahrscheinlich ist der beste Weg vorwärts, separate Pakete für Dinge zu machen, die von separaten Compilern erstellt werden sollten.