CMake project oder project C

Es ist zum Durchdrehen.

Mit project(xyz) laufen Standard-Builds (Windows, Linux) aber der Tiny C Compiler (TCC) streikt, weil CMake hier C++ Code-Tests exekutiert.

Mit project(xyz C) streikt wieder Watcom, weil der dann C++ gar nicht mehr nutzen kann.

Fangen wir am Anfang an: Es ist ein philosophisches Problem.

C und C++ sind historisch in fast allen Betriebssystemen stark mit einander verbunden. Und ich sehe das GATE Projekt als eine Brücke zwischen den beiden Sprachen.
Doch in Wahrheit sprechen wir von zwei Sprachen, die wie zwei Länder zwei getrennte Rechtsräume, Gesetzgebung und Kultur beinhalten.
Auch Bjarne Stroustrup hat schon mehrfach verkündet:

Es gibt kein C/C++.

Soll heißen:

Es gibt entweder C oder C++.

TCC ist nur C

Der Tiny-C-Compiler ist im Gegensatz zu “den großen Brüdern” ein reiner C Compiler, während MSVC, GCC, CLANG und WATCOM beide Welten abdecken.

Wer also sein CMake Projekt mit

project(myproject)

einleitet, lässt CMake nach einem C und einem C++ Compiler suchen, wobei zweiteres mit dem TCC fehlschlägt und CMake abbricht.

Die Lösung lautet:

project(myproject C)

und alles ist wieder gut.

Optionaler C++ Support

Da im GATE Projekt jedoch C und C++ Targets vorkommen, hätte ich bereits eine NO_CPP Option eingeführt, die C++ Targets nur dann einschließt, wenn die NO_CPP Option NICHT gesetzt ist.
Das funktioniert auch mit MSVC und GCC, doch nun fängt OpenWatcom an zu spinnen.

Ist dort ein Top-Level-Projekt an die Sprache C gebunden, können keine C++ Unterprojekte mehr angefügt werden.

Als “schnelle” Lösung fiel mir am Ende nur folgende Lösung ein:

option(GATE_NO_CPP "Build C files only, no C++ support" OFF)

if(GATE_NO_CPP)
  project(gate C)
else()
  project(gate)
endif()

Im Toplevel CMakeLists.txt wird die NO_CPP Option definiert und abhängig davon wird ein reines C oder allgemeines Projekt angelegt.
Die Option wird nur für den TCC of ON geschaltet und im Nachgang können weitere C und optional auch C++ angelegt werden.

Fazit

Auf Details kommt es an.

Ich liebe CMake für seine unglaublichen vielen Anbindungen an unterschiedliche Compiler. Doch hier habe ich einmal ein Problem identifiziert, das CMake nicht selbst löst und mir etwas Nacharbeit beschert.

Toplevel-Projekte sind rein technisch auch gar nicht notwendig, doch sie helfen in IDEs bei der Schaffung einer überordneten Instanz wie “Solutions” bei Visual Studio.
Dass deren (sonst wirkungslose) Konfiguration Arbeitsläufe negativ beeinflussen kann, war mir bisher nicht aufgefallen.

However … wieder was gelernt.