xmake: ein Lua-basiertes plattformübergreifendes Build-Werkzeug

xmake als Build-Backend, Projektgenerator und Paketmanager

Abschnitt 1, Absatz 1: Das Repository heißt xmake-io/xmake und wird als ein plattformübergreifendes Build-Werkzeug auf Basis von Lua beschrieben. Das README sagt eingangs, xmake sei leichtgewichtig und habe keine Abhängigkeiten außerhalb der Standardbibliothek, und es verwende eine xmake.lua-Datei, um Projekt-Builds zu pflegen. Laut README kann xmake Quellcode direkt bauen, Projektdateien wie CMake oder Meson erzeugen und C/C++-Abhängigkeiten über ein eingebautes Paketsystem verwalten. Das README fasst das zusammen als Build-Backend plus Projektgenerator plus Paketmanager plus Remote- oder verteilten Build plus Cache, und es vergleicht das Werkzeug mit Make/Ninja, CMake/Meson, Vcpkg/Conan, distcc und ccache/sccache. Dieser Vergleich ist der eigene Rahmen des README, keine unabhängige Bewertung.

Abschnitt 1, Absatz 2: xmake verwendet Lua-Dateien namens xmake.lua, um Ziele, Quellen, Toolchains und Abhängigkeiten zu beschreiben. Ein Projekt kann dadurch Build-Aufgaben und Paketauflösung in einer deklarativen Datei bündeln. Die Syntax ist jedoch Teil des Xmake-Ökosystems; ein vorhandenes Makefile oder CMake-Projekt wird nicht automatisch zu einem identischen Build.

xmake.lua-Projektdatei und Abhängigkeitsdeklarationen

Abschnitt 2, Absatz 1: Das README sagt, die xmake.lua-Syntax sei einfach und lesbar. Ein minimales Beispiel erstellt ein Binärziel namens console und fügt alle .c-Dateien aus src hinzu. Ein weiteres Beispiel deklariert Abhängigkeiten mit add_requires, etwa tbox 1.6.*, zlib und libpng ~1.6. Das README zeigt außerdem Debug- und Release-Profile, ein benutzerdefiniertes after_build-Skript, das etwas ausgibt und einen Befehl ausführt, sowie Beispiele für Qt QuickApp, CUDA, WDK/UMDF-Treiber, Darwin-Anwendungen, Frameworks, OpenMP und Zig. Die Syntax ist Lua, sodass die Projektdatei Funktionen und Bedingungen enthalten kann, aber das README demonstriert nur ein kleines Muster. Es dokumentiert nicht die vollständige API; die steht auf der Dokumentationsseite.

Abschnitt 2, Absatz 2: Der übliche Einstieg führt über die Installation des Xmake-Befehls und anschließend über xmake und xmake run. Mit xmake f lassen sich Konfigurationen wie Plattform, Architektur und Compiler setzen. Für eine belastbare Prüfung sollte dieselbe xmake.lua mit einem klar benannten Toolchain-Profil gebaut und das erzeugte Ziel anschließend separat gestartet werden.

Installation und Ablauf der Befehlszeile

Abschnitt 3, Absatz 1: Das README nennt drei Einzeil-Installationsmethoden: ein curl-Skript, ein wget-Skript und ein PowerShell-Skript. Für andere Methoden verlinkt es auf einen Installationsleitfaden. Die Befehlszeilenreferenz setzt voraus, dass man sich im Projektwurzelverzeichnis befindet. Der Befehl xmake baut das aktuelle Projekt, xmake run console führt ein Ziel aus, xmake run -d console führt es unter einem Debugger aus, xmake test führt Tests aus, xmake f konfiguriert Plattform, Architektur und Modus, und xmake f --menu öffnet ein interaktives Konfigurationsmenü. Das README sagt nicht, welcher Debugger angehängt wird, wie die Installationsskripte die heruntergeladene Datei verifizieren oder was passiert, wenn eine Plattform nicht aufgeführt ist.

Abschnitt 3, Absatz 2: Das README nennt C und C++, weitere Sprachen, zahlreiche Plattformen sowie IDE-Projektgeneratoren. Diese Breite ist nützlich, erhöht aber die Zahl der Kombinationen, die ein Team selbst testen muss. Besonders wichtig sind Compiler-Version, Runtime, Architektur und das Verhalten auf dem Zielbetriebssystem.

Plattformen, Toolchains, Sprachen und Projekttypen

Abschnitt 4, Absatz 1: Das README listet Windows, macOS, Linux, FreeBSD, NetBSD, OpenBSD, DragonflyBSD, Solaris, Android, iOS, WatchOS, AppleTVOS, AppleXROS, MSYS, MinGW, Cygwin, Wasm, Haiku, Harmony und eine generische Cross-Toolchain. Die Toolchain-Liste umfasst Xcode, MSVC, Clang, GCC, Rust, Swift, CUDA, Zig, Intel-Compiler und viele eingebettete und Simulator-Toolchains. Unterstützte Sprachen sind C und C++, Objective-C, Swift, Assembly, Golang, Rust, Dlang, Fortran, Cuda, Zig, Vala, Pascal, Nim, Verilog, mehrere Assembler, Cppfront, Kotlin, C# und Ascend C. Der Abschnitt zu Projekttypen behandelt statische Bibliotheken, gemeinsame Bibliotheken, Konsolenanwendungen, CUDA-Programme, Qt-Anwendungen, WDK-Treiber, WinSDK, MFC, Darwin-Anwendungen, Frameworks, SWIG-Module, LuaRocks-Module, Protobuf-Programme, Lex/Yacc-Programme und Linux-Kernelmodule. Das README beschreibt nicht, wie vollständig oder getestet jede Kombination ist.

Abschnitt 4, Absatz 2: Die Paketverwaltung bindet Abhängigkeiten über Xmake-Paketbeschreibungen und Drittanbieter-Repositories ein. Ein Build mit externen Paketen sollte deshalb den Cache und die verwendeten Versionen sichtbar machen. Nicht jede im Katalog genannte Bibliothek hat dieselbe Pflege oder dieselben Binärpakete für jede Plattform.

Paketverwaltung und Drittanbieter-Repositories

Abschnitt 5, Absatz 1: Der eingebaute Paketmanager kann Abhängigkeiten automatisch abrufen und installieren. Das README nennt das offizielle xmake-repo-Paketrepository, den Xrepo-Befehl, benutzerdefinierte Repositories und Drittanbieterquellen wie Conan, Conda, Vcpkg, Homebrew, Pacman, Apt, Clib, Dub, Portage, Nimble, Cargo, Zypper und NuGet. Es sagt, das offizielle Repository biete fast 500+ Pakete, unterstütze kreuzkompilierte abhängige Pakete, biete eine Paket-Virtual-Umgebung über xrepo env shell, habe eine vorkompilierte Paketbeschleunigung für Windows NT und könne Remote-Toolchains ziehen. Es unterstützt auch die Sperrung von Abhängigkeitsversionen. Das README definiert die genaue Paketanzahl nicht und listet nicht, welche Drittanbieter-Repositories vom xmake-Projekt gepflegt werden.

Abschnitt 5, Absatz 2: Remote Build, verteilte Kompilierung und Cache-Funktionen können Wartezeiten verändern, bringen aber zusätzliche Server-, Netzwerk- und Identitätsannahmen mit. Ein lokaler Build ist der bessere erste Kontrollpunkt. Danach kann ein kleiner, reproduzierbarer Ziel-Build gegen den Remote-Weg verglichen werden.

Verteilte Builds, Remote-Builds, Cache und Benchmark-Tabelle

Abschnitt 6, Absatz 1: Ein Abschnitt zur verteilten Kompilierung im README listet plattformübergreifende Unterstützung, Unterstützung für MSVC, Clang, GCC und andere Toolchains, Unterstützung für Android-, Linux-, Windows-NT- und Darwin-Hosts, keine Abhängigkeiten außer der Kompilierungs-Toolchain, Lastverteilung auf Build-Servern, Echtzeit-lz4-komprimierte Übertragung großer Dateien und keine Anforderung an ein gemeinsames Dateisystem. Remote-Kompilierung und lokaler oder Remote-Build-Cache werden durch Links zu separaten Dokumentationsseiten abgedeckt. Das README enthält einen Benchmark am xmake-core-Projekt mit Tabellen für Termux und macOS. In der Tabelle für parallele Kompilierung braucht xmake auf Termux 24,890 Sekunden und auf macOS 12,264 Sekunden, während ninja 25,682 und 11,327 Sekunden braucht. Das README sagt, xmake sei auf Augenhöhe mit Ninja, beschreibt aber nicht die Hardware, das Aufwärmen oder die Messmethode.

Abschnitt 6, Absatz 2: Plugins, IDE-Integration und CI-Anbindung erweitern die Einsatzmöglichkeiten. Die Lizenzbedingungen sind im Repository zu prüfen; sie regeln Nutzungsrechte und Haftung, nicht die Qualität von Drittanbieterpaketen. Xmake passt zu Teams, die Lua-Konfiguration und ein einheitliches CLI akzeptieren; wer zwingend die Produktionsumgebung mit einem anderen Generator spiegeln muss, sollte die Unterschiede messen.

Plugins, IDE-Integration, CI und Lizenz

Abschnitt 7, Absatz 1: Der Plugin-Abschnitt zeigt Projektgeneratoren für Visual Studio, CMake, Ninja und compile_commands.json sowie ein Lua-Skript-Plugin, das eine Datei, einen Befehl oder eine REPL ausführen kann. Das README verlinkt Editor-Integrationen für VS Code, Sublime, IntelliJ, Zed, Vim, Visual Studio und Qt Creator sowie ein Gradle-Plugin für JNI-Builds. Für CI erwähnt es ein GitHub-Action-Setup-Plugin. Das Repository ist unter Apache-2.0 lizenziert. Der Lizenzauszug gewährt eine Urheberrechtslizenz und eine Patentlizenz und legt Bedingungen für die Weiterverteilung fest. Er enthält keine Aussage zu Garantie, Support oder Sicherheit. Das README verweist außerdem auf eine Seite mit Projekten, die xmake verwenden, aber der Inhalt dieser Seite ist nicht im Repository.

Redaktionelles Fazit

Das README stellt xmake als eigenständiges Build-Werkzeug mit Paketverwaltung und Remote-Build-Funktionen dar. Außerhalb des Repositories müssen die genaue Paketanzahl, die Benchmark-Methodik und der Vollständigkeitsgrad der Unterstützung für jede Plattform, Toolchain und Sprache überprüft werden.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository
4. Release notes