INTERLIS leicht gemacht #66 - Ein ♥ für ilic

Frotzelalarm (Grossen Respekt vor Leuten, die einen INTERLIS-Compiler programmieren können. Die Gesamtsituation ist aber schon bissle witzig.): Es gibt ja bekanntlich (oder auch weniger bekanntlich) einen zweiten INTERLIS-Compiler: https://github.com/infogrips/ilic. Es ist wahrscheinlich eine dieser Software, die ausprogrammiert ist. Jedenfalls sieht man sehr wenige Contributions:

Der letzte Commit im ilic-Repo stammt vom 28. September 2021. Danach: gähnende Leere.

Im Repo unter ./docs gibt es unter anderem zwei interessante Powerpoint-Präsentationen im klassischen 4:3-Format. Eine sehr technische, die andere für Normalsterbliche. Sie macht Aussagen zu den Projektzielen und der eingesetzten Werkzeuge:

Es gibt jedoch nicht wirklich sowas wie eine Lizenz, was ich nicht als sonderlich gelungen bezeichnen möchte. Wahrscheinlich hängt das damit zusammen, dass man Open Source mit keiner Lizenz gleichsetzt. Die Rechte am Quellcode werden an KOGIS abgetreten. Ob die von ihrem Glück wissen? Eingesetzt wird der Microsoft C/C++ Compiler, was natürlich vor allem Linux- und macOS-Entwickler freut…​

Warum ist ilic überhaupt entstanden? Ich denke, man hatte als Herstellefirma einfach den Wunsch zur Laufzeit nicht mehr von Java abhängig zu sein. Aber so richtig viel mehr Gründe sehe ich nicht und man müsste sie selber fragen. Kurzer Blick zurück: Zu dieser Zeit herrschte eine richtige Goldgräberstimmung. Man konnte bei Swisstopo einen Antrag einreichen, um GIS-Projekte finanzieren zu lassen. «Zweckgebundene NGDI-Mittel» hiess (heisst?) das. Anträge konnten meines Wissens aber nicht direkt Firmen stellen, sondern es musste ein Partner aus der öffentlichen Hand ins Boot geholt werden. Im vorliegenden Fall würde ich sagen, dass sich da jemand vor den Karren spannen hat lassen. Ich gehe nicht davon aus, dass der Kanton das wirklich wollte/brauchte. Aber who cares? Im Antrag sind übrigens noch äh mutige Gründe warum es genau zu diesem Zeitpunkt einen weiteren INTERLIS-Compiler brauchte. Lustig, dass die Lizenzsituation von ili2c ins Feld geführt wurde, dann aber selber keine klare Situation geschaffen wird.

Gekostet hat der Spass Fr. 86'160. Was hat man dafür bekommen? Nun, so circa das, was auf der Folie stand. Über den fehlenden sauberen macOS- und Linux-Support der Build-Chain und über die fehlenden Binary-Releases kann man sich streiten, was mich wirklich schlimm dünkt: Man hat sich nicht überlegt, wie die Software «leben» soll. Fire and forget. Auftrag machen und Prinzip Hoffnung. Think positiv, Stefan, aber ich denke nicht, dass es heute viel besser ist (looking at you, neuer INTERLIS-UML-Editor). Trotz verschiedenster Arbeitsgrüppli etc. SwissGIS, einfach zu viel Geld vorhanden.

Warum interessiert mich ilic jetzt? Es ist im Prinzip immer gut eine Basis-Software in einem anderen Stack zu haben. Aber es bringt nichts, wenn sie nicht vorhanden ist und wenn man nicht weiss, wie gut sie im Vergleich zur anderen Software oder zum Referenzhandbuch ist.

Der erste Schritt war also klar: Ich musste das Teil unter macOS zum Laufen bringen. Der ursprüngliche Build von ilic war stark auf Windows und die Visual-Studio-Werkzeugkette zugeschnitten. Er basierte auf einem manuell gepflegten Visual-Studio-Projekt, verwendete das ClangCL-Toolset und griff auf bereits kompilierte Windows-Bibliotheken zurück. Auf macOS liess sich das Projekt deshalb nicht ohne Weiteres übersetzen: Es fehlte eine plattformunabhängige Beschreibung der Quellen, Abhängigkeiten und Build-Schritte.

Als ersten Schritt habe ich den Build daher auf CMake umgestellt. CMake erzeugt die passende Build-Umgebung für die jeweilige Plattform und ermöglicht es, ilic unter macOS mit Apple Clang zu kompilieren. Gleichzeitig wird die mitgelieferte ANTLR-C++-Runtime nun direkt aus ihren Quellen als statische Bibliothek gebaut, statt eine für Windows vorkompilierte Bibliothek zu verwenden. Damit entstand erstmals ein reproduzierbarer nativer Build für macOS, der sich anschliessend auch auf Linux und Windows übertragen liess.

Mit dem Resultat konnte ich auf macOS endlich eine INTERLIS-Modelldatei kompilieren. Dabei musste ich feststellen, dass es keinen richtigen Repository-Support gibt. D.h. die importierten Modelle mussten lokal vorliegen. Gott sei Dank hatte man ein sauberes Lastenheft als Vertragsgegenstand…​ Als nächstes habe ich diesen Support umsetzen lassen (wobei ich nicht sicher bin, ob ich mit der Implementierung wirklich zufrieden bin).

Beim Rumspielen habe ich festgestellt, dass ilic einige (korrekte) Modelle nicht kompilieren konnte. Und jetzt? Einfach darauf los Bugs fixen lassen? Nein. Wir brauchen sowas wie eine Vergleichssuite wie bei den INTERLIS-Validatoren. Oh, ich sehe gerade, dass der letzte Commit vor vier Jahren war. Das war es wohl mit INTERLIS 2.4 Support in der Test-Suite. Oh #2, ein Ticket hatte ich bereits vor zwei Jahren gemacht. Auch wieder so ein gut gepflegtes INTERLIS-Tool. Warum kommt mir jetzt irgendwie Trapattoni in den Sinn?

Egal, machen wir die Compiler-Conformance-Suite: https://codeberg.org/edigonzales/interlis-compiler-conformance. Die müsste jetzt wirklich wirklich wirklich manuell gereviewt werden. Denn sie ist sowas wie die Wahrheit gegen die wir ilic prüfen werden. Ich habe es mir einfach gemacht (resp. dem LLM einfach gemacht): Ili2c hat enorm viele Tests und wir haben diese Tests als Wahrheit definiert. In einem ersten Schritt prüfen wir nur, ob ein von ili2c als korrekt eingestuftes Modell auch von ilic ohne Fehler kompiliert wird und umgekehrt. Das reicht natürlich noch nicht, denn z.B. unterstützt ilic INTERLIS 2.2 nicht und scheitert also schon dort und nicht erst bei einem Syntaxfehler im Modell. Aber fürs Erste dürfte das reichen. Wir lassen uns einen Report generieren:

Der Report meldet, dass sich von 571 Tests nur 268 konform verhalten, wobei wir vielleicht besser sagen «binär-identisch» zu ilic. Eine Analyse der Widersprüche zeigt, dass sich einige Fehlercluster finden lassen, z.B. betrifft vieles "TRANSLATION OF". Sind die Fehler in ilic gefixed, sieht der Report schon viel besser aus:

So, das ist die Basis, mit der man arbeiten kann und mit der ich einige spannende Ideen umsetzen will. Es gibt aber noch viel zu tun. Vielleicht liebe geostandards.ch:

Links:

Native Binaries sind natürlich immer bissle tricky zu builden und zu testen und ich wollte unbedingt ein möglichst statisches Binary. Hoffentlich funktionieren sie. Auf macOS muss man xattr -dr com.apple.quarantine ilic (nach dem Entzippen) ausführen.