AURA Zielplattformen
AURA hat eine native C++-Laufzeit und einen WebAssembly-Port. Oberfläche, Parser, Layouts und Bindungen teilen sich den Code; die Verfügbarkeit von Betriebssystemdiensten hängt von der Zielplattform ab.
Plattformübersicht
| Ziel | Architektur | Stand | Einsatz |
|---|---|---|---|
| Linux | x86_64, ARM64 | Native Referenzplattform; Buildpakete für beide Architekturen vorhanden | Desktop, Touch-Terminal und Kiosk |
| Browser / WebAssembly | Wasm über Emscripten | Vorhandener Port mit Hello, Demo und Playground; eingeschränkte System-APIs | Interaktive Anwendungen und UI-Vorschau im Browser |
| Windows | x64 im vorkonfigurierten Skia-Paket | Grafik-Buildpfade vorbereitet; vollständiger Framework-Port nicht freigegeben | Mögliches natives Portierungsziel |
| macOS | Intel x64, Apple Silicon ARM64 im Skia-Paket | Grafik-Buildpfade vorbereitet; vollständiger Framework-Port nicht freigegeben | Mögliches natives Portierungsziel |
| iOS / iPadOS | Browser / WebAssembly | Im Browser nutzbar; die Web-Runtime benötigt passende Browserfunktionen und Hosting-Header | iPhone und iPad ohne separate native App |
| Android | Browser / WebAssembly | Web-Runtime im Browser; kein eigener nativer Android-Buildpfad dokumentiert | Mobile Browseranwendungen |
„Vorbereitet“ bezeichnet vorhandene Plattformzweige und Abhängigkeiten, nicht einen nachgewiesenen vollständigen Build oder eine getestete Produktfreigabe. Ein funktionierendes Beispiel ersetzt keine Prüfung auf dem konkreten Gerät.
Linux: Desktop und Kiosk
Linux ist die Referenz für die native Entwicklung von AURA. Das vorkonfigurierte Skia-Paket gibt es für x86_64 und ARM64. C++20, CMake und Ninja bilden den Build; die ersten Schritte nennen die Linux-Voraussetzungen.
SDL3 übernimmt Fenster und Eingabe. Je nach SDL-Build und Zielsystem stehen X11, Wayland oder KMS/DRM zur Verfügung. KMS/DRM ist der direkte Anzeigepfad für entsprechend eingerichtete Linux-Kiosksysteme; EGL/GLES werden im Grafik-Build berücksichtigt. Treiber, Eingabegeräte, Zugriffsrechte und tatsächlich verfügbare Backends bleiben Teil der Geräteintegration.
Gerätebeobachtung, SCSI-Medien, Hotplug/usbmuxd und native Systemdaten sind plattformnahe Dienste. Die Systemdaten verwenden unter Linux unter anderem /proc und /sys; diese Funktionen sind keine plattformunabhängigen Browser-APIs.
Browser: die gleiche UI-Laufzeit als Wasm
Der Browser-Port baut den C++-Szenengraph, Skia, SDL3, die Sprache und Bindungen mit Emscripten zu WebAssembly. Die UI wird im Canvas gezeichnet. Es handelt sich nicht um eine Übersetzung der AURA-Elemente in HTML-Widgets.
- Hello und aura-demo zeigen den kompilierten Weg.
- Der Playground lädt bearbeitbare
.aura-Dateien mit dem dynamischen Loader. - Der aktuelle Port verwendet Browser-Threads. HTTPS und Cross-Origin-Isolation mit COOP/COEP sind erforderlich; der Browser-Leitfaden beschreibt Build und Hosting.
- Native Kindprozesse, SCSI/Hotplug, eigene HTTP-/TLS-Server, der Remote-HTTP-Server und CEF-WebView stehen dort nicht zur Verfügung. Für
aura-netfehlt derzeit ein Browser-Clientadapter; HEIF ist in diesem Build deaktiviert.
Auf iOS und iPadOS läuft AURA über den Browser-/WebAssembly-Port. Ein separater nativer App-Store-Build ist davon zu unterscheiden. Tastatur-, IME- und Geräteanforderungen hängen vom jeweiligen Browser und der Anwendung ab. Weitere Grenzen und die Voraussetzungen für SharedArrayBuffer stehen im Browser-Kapitel.
Windows und macOS: Portierungsstand
Die Skia-Konfiguration enthält Downloadpakete, Bibliotheksnamen und Linkeinstellungen für Windows x64 sowie macOS x64/ARM64. SDL3 ist ebenfalls als plattformübergreifende Fenster- und Eingabeschicht eingebunden.
Andere Teile des Frameworks sind noch an Linux beziehungsweise POSIX gebunden. Beispielsweise verwendet der native Prozesscode spawn, poll, pipe2 und POSIX-Header; Gerätefunktionen und der CEF-Integrationspfad haben weitere Plattformannahmen. Vor einer vollständigen Unterstützung sind passende Implementierungen, ein durchgängiger Build und Tests auf der jeweiligen Plattform nötig. Deshalb werden Windows und macOS hier als vorbereitete Portierungsziele geführt.
Module und plattformabhängige Grenzen
| Funktion | Native Linux-Laufzeit | Aktueller Browser-Port |
|---|---|---|
| Widgets, Text, Layout, Bindungen, Zustände, Animation | Native C++-UI | Gemeinsamer C++-Code in Wasm |
Kompilierte und dynamische .aura-Dateien |
Beide Wege | Eigenständige Beispiele und Playground |
| JavaScript-/Lua-Handler | AURA_WITH_SCRIPT |
Gemeinsame Skriptlaufzeit |
| PNG-Rendering ohne Fenster | Native Offscreen-Ausgabe für Vorschau und Tests | Kein Ersatz für den nativen Headless-Workflow |
| HTTP(S), Server und Fernsteuerung | Nach Buildoptionen verfügbar | Native Netzwerkmodule derzeit nicht verfügbar |
| HEIF/HEIC | Optional über libheif und Decoder-Plugins | In diesem Build deaktiviert |
| Chromium-WebView | Optional; CEF-Buildpfad für Linux | Nicht verfügbar |
| Betriebssystem- und Gerätedienste | Linux-/POSIX-abhängig | Nicht verfügbar oder gezielt eingeschränkt |
Headless und Cross-Builds
Die native Laufzeit kann Screenshots und Galerien ohne Fenster als PNG erzeugen. Das ist für visuelle Tests und Vorschauen nützlich und bildet einen anderen Arbeitsablauf als die Canvas-Ausgabe im Browser.
Bei Cross-Builds muss aurac auf dem Build-Rechner laufen können. AURAC_EXECUTABLE erlaubt, einen passenden Host-Compiler für die AURA-Dateien vorzugeben. Ein eigenes Skia-Paket kann über AURA_SKIA_DIR eingebunden werden. Der Browser-Build verwendet einen separaten nativen Host-aurac und eigens für Wasm gebaute Bibliotheken; native Skia-Archive sind dafür nicht verwendbar.
Quellen und Stand
Die Übersicht basiert auf CMakeLists.txt, CMakePresets.json, cmake/SDL3.cmake, cmake/Skia.cmake, cmake/SkiaWasm.cmake, cmake/Cef.cmake, den nativen Core-Implementierungen und tools/web/. Stand: 1. November 2026. Details zu den verwendeten Bibliotheken stehen unter Dependencies & Lizenzen.
CMake platform configuration · tools/web · native core · Markdown herunterladen