From 2c21df4be0ee2e97bef1750e6947dcc4e7eb7531 Mon Sep 17 00:00:00 2001 From: paulhorn Date: Sun, 30 Aug 2026 18:22:19 +0200 Subject: [PATCH] docs: CLion-Abschnitt in CMAKE.md, cmake-build-* ignorieren Die Meldung 'This file does not belong to any project target' kommt nicht vom CMakeLists.txt: die File API ordnet calculator.hpp korrekt dem Target pda zu (LIBPDA_HEADERS geht an add_library). CLion hatte nur kein Modell. Dokumentiert dazu die Falle, dass eine aus dem Dock gestartete GUI die PATH aus .zprofile nicht erbt -- 'CMAKE_C_COMPILER: clang' loest dort auf Apple clang auf, im Terminal auf Homebrew-LLVM. Da binaryDir in beiden Faellen build/debug ist, gewinnt lautlos, wer zuerst konfiguriert. .gitignore deckte /build/ ab, aber nicht CLions Default cmake-build-/ im Wurzelverzeichnis. Co-Authored-By: Claude Opus 5 --- .gitignore | 5 +++++ docs/CMAKE.md | 49 ++++++++++++++++++++++++++++++++++++++++++++++++- 2 files changed, 53 insertions(+), 1 deletion(-) diff --git a/.gitignore b/.gitignore index 1af2b88..74128d3 100644 --- a/.gitignore +++ b/.gitignore @@ -1,6 +1,11 @@ # Build trees: build// for every preset. /build/ +# CLion legt seine Build-Verzeichnisse per Default NICHT unter build/ an, +# sondern als cmake-build-/ im Projektwurzelverzeichnis. Ohne diese +# Zeile landet ein kompletter Build-Baum im Commit. +/cmake-build-*/ + # clangd's per-project index and cache. /.cache/ diff --git a/docs/CMAKE.md b/docs/CMAKE.md index 7a45a19..dcab068 100644 --- a/docs/CMAKE.md +++ b/docs/CMAKE.md @@ -487,7 +487,54 @@ Die ersten beiden sind beim Bau *dieses* Projekts tatsächlich aufgetreten. --- -## 13. Werkzeuge zum Nachsehen +## 13. CLion + +CLion liest **dieselbe** CMake File API wie jedes andere Werkzeug — es hat +keine eigene Projektdatei. Die Meldung + +> This file does not belong to any project target + +heisst deshalb fast nie, dass mit dem `CMakeLists.txt` etwas nicht stimmt. Sie +heisst: *CLion hat (noch) kein CMake-Modell.* Nachsehen kann man das selbst: + +```sh +mkdir -p build/debug/.cmake/api/v1/query +touch build/debug/.cmake/api/v1/query/codemodel-v2 +cmake --preset debug +python3 -c " +import json,glob +d=json.load(open(glob.glob('build/debug/.cmake/api/v1/reply/target-pda-*')[0])) +print(*[s['path'] for s in d['sources']], sep='\n')" +``` + +Stehen die Header dort — und sie stehen dort, weil `LIBPDA_HEADERS` an +`add_library()` geht — dann ist das Modell korrekt und CLion muss nur neu +laden: **File → Reload CMake Project**. + +### Die Falle: zwei Compiler, ein Build-Verzeichnis + +Der Preset `debug` setzt `"CMAKE_C_COMPILER": "clang"`. Das wird über `PATH` +aufgelöst — und eine aus dem Dock gestartete GUI-Anwendung erbt die `PATH` aus +`.zprofile` **nicht**. In CLion löst `clang` deshalb auf `/usr/bin/clang` +(Apple clang) auf, im Terminal auf `/opt/homebrew/opt/llvm/bin/clang`. + +Weil `binaryDir` in beiden Fällen `build/debug` ist, gewinnt schlicht, wer +zuerst konfiguriert — CMake speichert den **vollen Pfad** im Cache und löst +`clang` danach nie wieder auf. Es gibt keine Fehlermeldung, nur einen anderen +Compiler als gedacht. + +Zwei saubere Auswege: + +1. **CLion ein eigenes Build-Verzeichnis geben** (Default `cmake-build-debug`, + in `.gitignore` eingetragen). Terminal und IDE kommen sich nie in die Quere. +2. **Denselben Compiler erzwingen:** in CLion unter *Settings → Build, + Execution, Deployment → Toolchains* C/C++-Compiler auf + `/opt/homebrew/opt/llvm/bin/clang` bzw. `clang++` setzen. + +Weg 1 ist der bequemere, Weg 2 der ehrlichere -- dann sieht clangd in CLion +dieselben Diagnosen wie im Terminal. + +## 14. Werkzeuge zum Nachsehen ```sh cmake --build build/debug --target help # alle Targets