Cross-Kompilieren von Scala in einem Gradle-Projekt

In Scala-Projekten werden häufig binäre Artefakte bereitgestellt, die für mehrere Versionen des Scala-Compilers kompiliert wurden. In der Regel ist es zum Erstellen mehrerer Versionen eines Artefakts in einer Community üblich, SBT zu verwenden, wobei diese Funktion sofort einsatzbereit ist und in mehreren Zeilen konfiguriert wird. Aber was ist, wenn wir verwirrt werden und einen Build für die Cross-Kompilierung erstellen möchten, ohne SBT zu verwenden?

Für eines meiner Java-Projekte habe ich beschlossen, eine Scala-Fassade zu erstellen. In der Vergangenheit wurde das gesamte Projekt mit Gradle zusammengesetzt, und es wurde beschlossen, die Fassade demselben Projekt als Submodul hinzuzufügen. Gradle als Ganzes kann Scala-Module mit der Einschränkung kompilieren, dass keine Cross-Compiling-Unterstützung deklariert wurde. Es gibt ein offenes Ticket für 2017 und einige Plugins ( 1 , 2 ), die versprechen, diese Funktion zu Ihrem Projekt hinzuzufügen, aber es gibt Probleme mit ihnen, die normalerweise mit der Veröffentlichung von Artefakten verbunden sind. Und allgemein gibt es nichts mehr. Ich habe mich entschlossen zu prüfen, wie schwierig es ist, den Build für die Cross-Kompilierung ohne spezielle Plugins und SMS zu konfigurieren.

Zunächst beschreiben wir das gewünschte Ergebnis. Ich möchte, dass derselbe Satz von Quellen von drei Versionen des Scala-Compilers kompiliert wird: 2.11, 2.12 und 2.13 (zu diesem Zeitpunkt der aktuellste 2.13.0-RC2). Und da Scala 2.13 eine Reihe von rückwärts inkompatiblen Änderungen in Sammlungen aufweist, möchte ich zusätzliche Quellensätze für Code hinzufügen können, der für jeden der Compiler spezifisch ist. Auch in SBT wird dies alles zu einigen Konfigurationszeilen hinzugefügt. Mal sehen, was in Gradle gemacht werden kann.

Die erste Schwierigkeit, der Sie sich stellen müssen, besteht darin, dass die Compilerversion aus der Version der deklarierten Abhängigkeit von der Scala-Bibliothek berechnet wird. Außerdem müssen alle Abhängigkeiten geändert werden, die ein Präfix für die Scala-Version des Compilers haben. Das heißt, Für jede Version des Compilers sollte die Abhängigkeitsliste unterschiedlich sein. Darüber hinaus ist der Satz von Flags für verschiedene Versionen des Compilers tatsächlich unterschiedlich. Einige Flags wurden zwischen den Versionen umbenannt, während andere einfach als veraltet markiert oder ganz entfernt wurden. Ich entschied, dass der Versuch, alle Nuancen verschiedener Compiler in einer Build-Datei zu erfassen, eine zu schwierige Aufgabe zu sein scheint und ihre weitere Unterstützung noch schwieriger ist. Aus diesem Grund habe ich mich entschlossen, nach anderen Möglichkeiten zu suchen, um dieses Problem zu lösen. Was aber, wenn wir mehrere Build-Builds für dieselbe Projektverzeichnisstruktur erstellen?

In der Deklaration für die Aufnahme von Submodulen in das Gradle-Projekt können Sie das Verzeichnis angeben, in dem sich das Stammverzeichnis des Submoduls und der Name der für seine Konfiguration verantwortlichen Datei befinden. Geben Sie dasselbe Verzeichnis für mehrere Importe an und erstellen Sie für jede Version des Compilers mehrere Kopien des Build-Skripts.

rootProject.name = 'test' include 'java-library' include 'scala-facade_2.11' project(':scala-facade_2.11').with { projectDir = file('scala-facade') buildFileName = 'build-2.11.gradle' } include 'scala-facade_2.12' project(':scala-facade_2.12').with { projectDir = file('scala-facade') buildFileName = 'build-2.12.gradle' } include 'scala-facade_2.13' project(':scala-facade_2.13').with { projectDir = file('scala-facade') buildFileName = 'build-2.13.gradle' } 

Nicht schlecht, aber von Zeit zu Zeit können seltsame Kompilierungsfehler auftreten, die darauf zurückzuführen sind, dass alle drei Build-Skripte dasselbe Build-Verzeichnis verwenden. Wir können dies beheben, indem wir sie für jeden Build festlegen:

 plugins { id 'scala' } buildDir = 'build-2.12' clean { delete 'build-2.12' } // ... 

Jetzt ist es sehr schön. Mit nur einem Problem wird ein solcher Build Ihre Lieblings-IDE verrückt machen, und höchstwahrscheinlich muss die weitere Bearbeitung Ihres Projekts mithilfe von Instrumenten erfolgen. Ich dachte, dass dies kein großes Problem ist, weil Sie können die überschüssigen Importe von Submodulen jederzeit einfach auskommentieren und den Cross-Build in einen regulären Build verwandeln, mit dem Ihre IDE höchstwahrscheinlich arbeiten kann.

Was ist mit zusätzlichen Quellensätzen? Auch bei separaten Dateien stellte sich heraus, dass dies recht einfach ist. Erstellen Sie ein neues Verzeichnis und konfigurieren Sie es als Quellensatz.

 // ... sourceSets { compat { scala { srcDir 'src/main/scala-2.12-' } } main { scala { compileClasspath += compat.output } } test { scala { compileClasspath += compat.output runtimeClasspath += compat.output } } } // ... 

 // ... sourceSets { compat { scala { srcDir 'src/main/scala-2.13+' } } main { scala { compileClasspath += compat.output } } test { scala { compileClasspath += compat.output runtimeClasspath += compat.output } } } // ... 

Die endgültige Struktur des Projekts sieht folgendermaßen aus:

Hier können Sie auch einzelne gemeinsame Teile in externe Konfigurationsdateien trennen und in den Build importieren, um die Anzahl der Wiederholungen zu verringern. Aber für mich hat es sich als ziemlich gut herausgestellt, deklarativ, isoliert und kompatibel mit allen möglichen Gradle-Plugins.

Insgesamt wurde das Problem gelöst, Gradles Flexibilität reichte aus, um ein nicht triviales Setup recht elegant auszudrücken, und Scala-Crossbuild ist nicht nur mit SBT möglich. Wenn Sie aus dem einen oder anderen Grund Gradle zum Erstellen eines Scala-Projekts verwenden, ist Cross-Compilation eine Gelegenheit für Sie auch erhältlich. Ich hoffe jemand dieser Beitrag wird nützlich sein. Vielen Dank für Ihre Aufmerksamkeit.