Ninja-Build für VSCode

Ohne die explizite Angabe eines “Generators” wählt CMake das nächst beste auf der Plattform. Doch wenn man ein Projekt auf mehreren Plattformen entwickelt und nicht immer mehrere Konfigurationen haben will, dann kann Ninja-Build die Lösung sein.

Und sau-schnell ist das Tool noch obendrein.

Ich finde es grundsätzlich gut, dass CMake das Standard-Buildsystem der Umgebung benutzt. Das wäre MSBUILD auf Windows und Unix Makefiles auf Linux oder BSD.

Wenn man aber in Tests oder Debugsitzungen Pfade benötigt (also Workingdirectory oder Pfad zur EXE oder Projektunterverzeichnisse mit Daten), dann gibt es einen gravierenden Unterschied zwischen MSBUILD und den meisten anderen Systemen:
MSBUILD erzeugt immer Debug und Release Konfigurationen inklusive deren Unterverzeichnisse. Ein Ausgabeverzeichnis für Builds wäre unter Linux
build/out/ und unter Windows
build/out/Debug oder build/out/Release.

Diese “Kleinigkeit” kann sehr schnell lästig werden, wenn man etwa für Tests oder das Kopieren von Bibliotheken immer ein
if(WIN32) ... else() benötigt.

Lösung: Ninja

Konfiguriert man CMake für Ninja, entsteht im Build-Verzeichnis immer eine build.ninja Datei mit allen Instruktionen und das Tool ninja startet dann Compiler und Linker ohne MSBUILD oder make.
Hier gibt es dann auch keine Debug und Release Ordnern womit die Builds auf allen Plattformen das gleich Layout bekommen.

Unter Linux ist ninja meist als ninja-build im Paketsystem.

apt-get install ninja-build

und Windows stellt es per winget bereit

winget install --id=Ninja-build.Ninja

Allerdings kann man auch auf die Webseite ninja-build.org gehen und die EXE manuell herunterladen, in ein beliebiges Verzeichnis packen und dann dieses Verzeichnis in den PATH aufnehmen.

VSCode Ninja Konfiguration

Auf der Konsole würde ein cmake -G Ninja .... reichen, um vom Standard-Build zu Ninja zu wechseln.
In VSCode kann man den Ninja-Zwang per .vscode/settings.json bewirken:

 /// .vscode/settings.json
 {
   "cmake.configureOnOpen": false,
   "cmake.configureOnEdit": false,
   "cmake.generator": "Ninja",
   "cmake.buildDirectory": "${workspaceFolder}/build/ninja",
   "cmake.sourceDirectory": "${workspaceFolder}",
   "cmake.configureSettings": {
     "MY_CMAKE_OPTION": true
  }
}

Die Einstellung cmake.generator erzwingt nun bei jedem Aufruf ninja als Generator. Zusätzlich kann man das cmake.buildDirectory auf einen eigenen Wert setzen, wenn einem der Standard ${workspaceFolder}/build nicht gefällt.

Ich benutze und teste ja unterschiedliche Buildsysteme und lasse daher für jede Variante in build/ noch ein zusätzliches Unterverzeichnis anlegen.

Fazit

Ninja ist nicht nur plattformunabhängig sondern auch schnell. Ich würde zwar nicht sagen, dass die Builds doppelt so schnell sind, aber etwas Ersparnis gegenüber MSBUILD und make scheint drinnen zu sein.

Ninja ist daher in meinen VSCode-Debugging-Sessions immer mit dabei.

Einzig, wenn man Spezialanforderungen hat, (etwa C++/CLI) oder andere Systeme wie Conan, dann ziehe ich den OS-Standard einem Ninja-Build vor, nur um sicher zu stellen, dass wir garantiert das richtige Ergebnis bekommen.