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-<profil>/
im Wurzelverzeichnis.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

.gitignore

@@ -1,6 +1,11 @@
 # Build trees: build/<preset>/ for every preset.
 /build/
 
+# CLion legt seine Build-Verzeichnisse per Default NICHT unter build/ an,
+# sondern als cmake-build-<profil>/ im Projektwurzelverzeichnis. Ohne diese
+# Zeile landet ein kompletter Build-Baum im Commit.
+/cmake-build-*/
+
 # clangd's per-project index and cache.
 /.cache/
 

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