Ich habe hier ein Paar kleine Anmerkungen zu dem Artikel:
Benutzung: "... Denoch gibt es immer Situationen, wo man eingreifen muss.". Das hört sich so an als ob man nach einem CMake-Lauf nachträglich an der Make-Datei was verändern muss. Dies ist in keinem Fall notwendig noch ratsam.
Grundlagen: "...CMake akzeptiert dabei sowohl relative Pfade als auch absolute". Das tut zwar CMake, aber bei größeren Projekten kommt man mit relativen Pfaden in Teufel's Küche. Bei einem CMake-Lauf ruft sich CMake, unsichtbar für den Benutzer, mehrmals sich selbst auf. Dabei verändert sich der Ursprung auf dem der relative Pfad beruht, was zu unvorhersehbaren Ergebnissen führen kann. Stattdessen sollte man immer mit absoluten Pfaden arbeiten. Die Variablen CMAKE_CURRENT_SOURCE_DIR/CMAKE_SOURCE_DIR oder CMAKE_CURRENT_BINARY_DIR/CMAKE_BINARY_DIR, die absolute Pfade enthalten, können hier enorm helfen.
"cmake .." funktioniert nur wenn das übergeordnete Verzeichnis eine CMakeLists.txt-Datei enthält.
Optionen einstellen: Finger weg von der Datei CMakeCache.txt. Wie der Name schon sagt, hier handelt es sich um eine Cache-Datei von CMake. Ein jedes "Delete Cache" löscht diese Datei. Es gibt praktisch keinen Fall der hier Manipulationen rechtfertigen würde.
CMake-Dateien Wurzelverzeichnis
ADD_SUBDIRECTORY(lib) sollte vor ADD_SUBDIRECTORY(src) damit auch dem Leser die Abhängigkeiten klar sind (CMake kann das automatisch). "lib" muss fertig sein bevor mit src angefangen wird. Dies ist vor allem wichtig, wenn man mehr als einen Prozessor in seinem Rechner hat.
INSTALL(FILES img/icon.png DESTINATION img) Man sollte dem Leser vielleicht sagen wohin die Datei jetzt installiert wird. ${CMAKE_INSTALL_PREFIX}
Verzeichnis src SET(CMAKE_INCLUDE_CURRENT_DIR ON) ist überflüssig.
