SW-Module

Übersicht der eigenen Software-Module und -Bibliotheken (C).

• rbs – Rule Based System (Regel-Engine) – deterministische Regel-Engine mit Schritt-Semantik; Kern des Zustandsautomaten
• sm – minimal threaded State Machine – Handler-Schleife im eigenen Thread; Laufzeitgerüst für rbs
• threading – Thread- und Synchronisations-Helfer – POSIX-Wrapper: Threads, kritische Sektionen, Semaphore
• string – String-, Pfad- und Terminal-Helfer – gebundene Strings, Pfade, ANSI-Farben
• api – C++-ähnliche Lesbarkeit in C – Sichtbarkeits-Makros (private/protected) und überschreibbare callbacks
• logging – Zeitstempel-Logging – thread-sichere Meldungen mit Nanosekunden-Stempel
• vector – 3D-Vektor-Mathematik – long double, Kartesisch + astronomische Koordinaten
• gui – GTK-Widget-Bibliothek mit App-Hooks – Skelett + überschreibbare Weak-Callbacks (aus api)
• ocl – OpenCL-Wrapper – Plattform-/Kernel-Setup, fachliche Kernels (IWT, MATVEC, SD-Attention)
• physics – Astronomische Konstanten & Weber-Mechanik – Sonnensystem-Daten + Weber-Kraft-Dynamik, baut auf vector/GSL
• socket – TCP/UDP-Socket-Helfer – TCP-Client/Server, Ping, eigene IP, UDP-Broadcast mit Antwort
• skywatcher – Sky-Watcher Montierungs-Steuerung – GoTo-Montierung über das Sky-Watcher-Protokoll, auto-Discovery per UDP-Broadcast

Modul ↔ Repo ↔ Wiki

Jedes Modul ist ein GitHub-Repo (public, Apache-2.0) und hat genau einen Wiki-Artikel; die Repo-README verlinkt zurück auf ihren Artikel. Apps (iwt, rbs_demo) haben ebenfalls einen Artikel.

Bibliotheks-Closure: string, threading, api (Basis); gui → logging, threading, string, api; ocl → logging, threading, api; vector (keine Abhängigkeiten); physics → vector, string, logging (+ GSL extern); socket → string, threading; skywatcher → socket, physics, threading, string, api, logging. Kernkette: rbs → sm → threading → api (rbs ist eine Bibliothek unter libraries/, nicht mehr App-Source).

Referenzprojekte: iwt – die Modul-Architektur in einer realen App (nutzt gui-Hooks, ocl-Kernel, vector, string) und rbs_demo – Beispiel-App für das rbs-Regelsystem (zeigt rbs/sm-Router + Lebenszyklus).

Konventionen (gewollte Patterns)

Die folgenden Muster sind bewusste Entscheidungen (kein „Befund”, keine Vereinheitlichung von außen):

Sprache

• Produktivcode ausschließlich C. Python wird nur unterstützend eingesetzt (z. B. Auswertung, Messdaten, Tests) – nie für Bibliotheken oder Produktivmodule.

Typedefs

• X_t ist immer der Pointer auf das Struct: typedef struct rbs *rbs_t;. Auch Enums folgen dem Muster (typedef enum operation *operation_t;).
• Ausnahme string_t: Array-typedef (char[STRING_MAXLEN]) als Stack-Puffer – ebenfalls bewusst so gewählt.
• Strukturen behalten den Basisnamen (struct rbs), der Handle heißt dann rbs_t.

API-Stil

• Pointer sind das Ziel: Daten fließen über Pointer/Out-Parameter, Handles sind Pointer (X_t); nichts wird (unnötig) per Wert kopiert.
• bool als Rückgabe bevorzugt, wenn die Antwort „ja/nein” ist (z. B. rbs_compare, string_filepath_exist, threading_semaphore_wait). Zahlen nur, wo ein Wert natürlich ist (Copy-Längen, Substring-Index).

CMakeLists.txt

• Header werden PUBLIC exportiert (target_include_directories(... PUBLIC ${CMAKE_CURRENT_SOURCE_DIR})) → Einbindung immer mit spitzen Klammern: <string/string.h>.
• Abhängigkeiten per add_subdirectory(../libraries/<dep> ${CMAKE_BINARY_DIR}/<dep>_from_<elter>) eingebunden und transitiv verlinkt (target_link_libraries(... PUBLIC <dep>)).
• Mehrfach einbindbare Bibliotheken schützen sich mit include_guard(GLOBAL) (derzeit string, threading).
• Jedes Modul ist eigenständig baubar: cmake -S . -B build im Modulverzeichnis löst die komplette Abhängigkeitskette automatisch auf (jede Bibliothek zieht ihre Abhängigkeiten selbst per add_subdirectory), inklusive Tests – nichts muss von außen vorgegeben werden.
• Ausgaben nach ${CMAKE_BINARY_DIR}/lib und ${CMAKE_BINARY_DIR}/bin.
• POSIX-Source-Level: add_compile_definitions(_POSIX_C_SOURCE=200809L).
• Tests: je Test eine eigene Binary (Testdatei + Modul-Quellen direkt), enable_testing() + add_test(NAME … COMMAND …).

Verwandte Artikel

• rbs & sm – Regel-Engine als Zustandsautomat – das Gesamtkonzept (Schritt-Semantik, geschlossene Welt, bewachte Diffs)