Von NMAKE zu CMAKE

Als ich zum ersten Male mit OpenSSL arbeitete, war ich schwer verärgert, denn die Bibliothek benötigt Perl-Scripts um seine eigenen Header und Makefiles an Compiler anzupassen, um übersetzbar zu werden.

Etwas später kam die libReSSL auf den Markt und ich beschloss, ein eigenes Visual Studio Projekt zu erstellen, in dem ich jede einzelne Quelldatei händisch hinzufügte.

Wie blöd! Denn eigentlich lag eine CMAKE Datei bei, und dieser mühsame Prozess wäre automatisch erledigt worden.

Seit Jahrzehnten bin ich von Visual Studio mit seinen Solutions und Projekten verwöhnt. Jede neue Quelldatei wird einem Projekt hinzugefügt und mehrere Projekte (Bibliotheken + Programme) bilden eine Solution.

Und das beste daran ist, dass mit NMAKE jede Solution per Kommandozeile (und damit automatisierbar) in fertige Binäredateien übersetzt werden kann.

Als ich nach Windows mit Linux zu arbeiten begann, war ich von den dortigen MAKE-Files sprichwörtlich angewidert. “Wieso?” fragte ich mich. “Wieso kann man dort nicht auch ‘einfach’ Dateien einem ‘Projekt’ per GUI hinzufügen und dieses übersetzen.

Aus diesem Grund griff ich zur IDE Code::Blocks. Denn diese IDE bot ähnliche Features wie Visual Studio aber war auch unter Linux einsetzbar. Zusätzlich kann man mit dem Tool cbp2make alle Code::Blocks Projekte oder Workspaces (== Solution) in MAKE Dateien übersetzen.

Doch hier kommt bereits Sand ins Getriebe, denn wer glaubt MAKE Files sind gleich MAKE Files, der irrt leider.
Und so können die mit cbp2make generierten Anweisungen zwar unter Linux problemlos verarbeitet werden, doch scheitern sie unter BSD Umgebungen.

CMakeLists.txt

Wer jedoch in seinem Quellcode-Verzeichnis eine Datei namens CMakeLists.txt anlegt, macht sein Projekt zu einem CMAKE Projekt.
Und das Tool CMAKE erstellt für jede Plattform eigene “native” Projektdateien. Man kann also aus einer CMakeLists.txt Datei:

• eine .vcxproj Projektdatei für Visual Studio
• eine .cbp Projektdatei für Code::Blocks
• oder eine makefile Datei für Unix Compiler wie GCC

anlegen und sie dann vom nativen Toolset übersetzen lassen.

Leider gibt es auch für CMakeLists.txt keinen grafischen Editor, doch ich komme mit dessen Syntax besser zurecht, als mit anderen. Und zu meiner Freude gibt es ein Visual Studio-Plugin, welches bestehende Solutions in CMAKE Dateien übersetzen kann.

Daher möchte ich in Zukunft mehr und mehr zu CMAKE wechseln und dessen großartige Portierungshilfen nutzen.

Wie cool wäre es, wenn das GATE Projekt auf allen Plattformen wie Windows, Linux, BSD, MacOS und Android automatisch übersetzt werden kann?

Und CMAKE ist dafür - nach meinen bisherigen Erfahrungen - recht gut geeignet.
Natürlich fehlt mir hier noch einiges an Detailwissen, doch sobald wie möglich, möchte ich das GATE Projekt von seinen bisherigen Projektdateien entkoppeln und diese per CMAKE generieren lassen.

Der Fall libReSSL

Meine Dummheit bei der libReSSL ärgert mich bis heute sehr. Denn es dauerte einige Stunden, bis ich alle Dateien zusammengesucht und manuell eingetragen hatte, und am Ende fehlten Makros und Variablen, die ich per Debugging schrittweise herausfinden musste.

Alles stand bereits in der beigelegten CMakeLists.txt drinnen und das Erzeugen eines Visual Studio Projektes wäre eine Sache von Minuten gewesen.

… aber Nein, ich Depp sitze stundenlang herum und pflege diese Daten per Hand.

CMAKE rulez!

Die libReSSL Integration ins GATE Projekt war dagegen ein Kinderspiel, denn CMAKE erstellte mir die Projektdateien, die ich nur noch in die richtigen GATE-Verzeichnisse kopieren musste.

Und so arbeitet das GATE Projekt bereits mit CMAKE Resultaten, obwohl das Tool aktuell noch nicht vollständig ins Projekt integriert ist.