XMake, das LUA-CMake

Die CMake Syntax mag zwar zweckdienlich sein, aber schön ist sie nicht. Es ist keine richtige Programmiersprache, auch wenn es versucht, wie eine auszusehen.

Doch nun kommt XMake … ein CMake Ersatz auf Basis der Scriptsprache Lua.

Problem: Scriptsprachen

Scriptsprachen zur Build-Prozess-Steuerung sind so eine Sache.
Conan setzt auf einem komplizierten Python-Modul auf und braucht je nach Projekt Zusatzbibliotheken um ausgeführt werden zu können.
Das stört sich dann oft auf älteren Systemen mit Python-2 Scripts des OS.

Unix-Shell-Scripts sind wiederum nicht portabel, angefangen bei /bin/sh vs. /bin/bash bis zu den BSD-Shells, und Windows-Batch-Dateien und die verkrüppelte Powershell stellen auch eine andere Gattung dar.

Verdammt! Ich will EINE einfache, portable und systemunabhängige Script-Sprache haben!

Diese Sprache heißt Lua … aber das nur nebenbei.

XMake Einführung

Ich bin eher zufällig über XMake gestoßen, und erfuhr, dass sich jemand die Mühe gemacht hat, Lua für Buildscripts einzusetzen.

Meine Assoziation war: Also ein CMake mit Lua-Syntax.
Das ist nicht ganz richtig, aber auch nicht ganz falsch.

Wer in XMake sein Buildsystem aufsetzen will, platziert in jedem Projektverzeichnis eine Datei namens xmake.lua (ganz genau so wie CMakeLists.txt für CMake) und ruft darin XMake Funktionen auf, die die Statemachine des XMake-Prozesses konfigurieren.

 target("my_lib")
   set_kind("static")
   add_files("my_lib.c")
 target_end()
 
 target("my_prog")
   set_kind("binary")
   add_files("my_prog.c")
   add_deps("my_lib")
  add_links("my_lib")
target_end()

Es hat sich eingebürgert, dass über Einrückungen zusammengehörende Blöcke optisch sichtbar gemacht werden (wie im Beispiel zwischen target() und target_end()). Notwendig wäre das aber nicht.

Ruft man nun in dem Projektverzeichnis xmake auf, wird eine statische Bibliothek my_lib erstellt und danach das Programm my_prog, welches gegen my_lib linkt.

Jetzt braucht man eigentlich nur noch wissen, dass add_files() auch Wildcards anbietet und dass man aus einer xmake.lua Unterverzeichnisse mit anderen xmake.lua Dateien einbinden kann.

--root/xmake.lua
includes("src/lib/lib1")
includes("src/lib/lib2")
includes("src/bin/my_project")

--root/src/bin/my_project
target("my_project")
  set_kind("binary")
  add_files("*.c")
  add_files("*.cpp")

So kann man nämlich schon viele übliche Projekte mit XMake bauen lassen.

Plattformen und Toolsets

Interessant wird es dann, wann man bei Plattformen ankommt und wenn es um Cross-Compiling geht.

Hierfür stehen dem xmake Tool Parameter zur Verfügung, um z.B. Plattform und Architektur zu setzen, die man in xmake.lua Scripts wieder interpretieren kann:

 target("my_target")
   set_kind("static")
   add_files("generic/*.c")
   if is_plat("windows") then
     add_files("windows/*.c")
     if is_arch("x64") then
       add_files("windows/x64/*.c")
     else
       add_files("windows/x86/*.c")
    end
  elseif is_plat("linux") then
    add_files("linux/*.c")
  end
target_end()

An der Konsole kann dann per
xmake config -plat=windows -arch=x64 konfiguriert werden, welche Einstellung der folgende Aufruf von
xmake am Ende bauen soll.

Fazit

XMake ist eine neue spannende Welt für mich und ich fange gerade erst an, an der Oberfläche zu kratzen. Es gibt noch viele offene Fragen, wie man “Options”, also Schalter für spezielle Einstellungen gut integrieren kann.
Ein anderer Punkt sind Paketabhängigkeiten, denn XMake kann neben eigenen Repos auch Conan Remotes abrufen und Bibliotheken herunterladen und in den Build Prozess integrieren.

Im GATE Projekt konnte ich bereits einige Standard-Builds mit XMake durchführen und das Ergebnis gefällt mir, weil z.B. für Windows kein msbuild eingesetzt wird, sondern direkt der Compiler und Linker aufgerufen werden.

XMake führt die Builds auch wesentlich schneller aus als CMake, was sich in langsamen Docker-Containern positiv auswirkt.

Ich glaube aber nicht, dass XMake bei mir CMake auf die Schnelle ersetzen wird. Denn wenn es um den Support älterer Hardware oder Compiler geht (z.B.: Watcom), ist CMake dem noch jungen XMake eben 15 Jahre voraus.

Trotzdem liegt in diesem schlanken Projekt natürlich ein großes Potential besonders für neue Projekte.