Build-Organisation

Führe make aus dem Repository-Stammverzeichnis aus. Das Stamm-Makefile definiert das Standardziel und bindet diese Dateien in dieser Reihenfolge ein:

Datei	Zuständigkeit
config.mk	Compiler-Flags, Build-Verzeichnisse, Quelllisten für Lint, Plattform-Standardwerte
native.mk	Explizite native Link-Abhängigkeiten, Kompilierung, Abhängigkeiten generierter Header
workflows.mk	Produktstart, Evidence-Fixtures, lokale Dienste, Brave-Integrationsbefehle
quality.mk	Build-Regressionsprüfung, Linter, Sanitizer, Bereinigung

Bestehende Befehlsnamen und ausführbare Pfade bleiben die öffentliche Schnittstelle. Implementierungsobjekte spiegeln Quellpfade innerhalb von BUILD_DIR wider; vom Compiler generierte .d-Dateien verfolgen direkte und transitive Projekt-Header. Nur die Decoder-Executable fügt zlib zu ihrem Link-Befehl hinzu. make native-probe-compile kompiliert die verfolgte Browser-Queue ohne eine separate Testquelle.

make bootstrap-dev-tools installiert dieselben gepinnten clang-format- und Ruff- Versionen, die von CI verwendet werden, in ~/.local/share/reb-tools, und installiert fehlende shellcheck- und actionlint-Formulae mit Homebrew. Make bevorzugt diese gepinnten lokalen Tools automatisch. make deob-benchmark baut den Rust-Worker und führt das begrenzte semantische Korpus mit Timing-, Speicher-, Transformations- und Nachweisen zur Abdeckung geänderter Quellen aus.

make lint prüft Formatierung und Clippy-Warnungen für beide Rust-Manifeste. Der Deobfuskierungs-Worker umfasst alle Targets, sodass sein Regressionstest-Code zusammen mit der Produktions-Executable geprüft wird.

Verwende ein separates Build-Verzeichnis für einen anderen Compiler oder eine andere Flag-Kombination:

make BUILD_DIR=build/debug OPT_CXXFLAGS='-O0 -g' all

Make erkennt keine Änderungen an Werten von Kommandozeilen-Flags in einem bestehenden Build- Verzeichnis. Änderungen an den nativen Regeln oder Compiler-Konfigurationsdateien invalidieren jedoch native Objekte. make sanitize verwendet sein eigenes sauberes Build-Verzeichnis.

make native-build-test führt scripts/check-native-build.sh aus, das zwei unabhängige Executables in einem temporären Verzeichnis baut und ausführt, prüft, dass ein wiederholter Build keine Arbeit verrichtet, und verifiziert, dass eine Änderung an einem Artefakt-Header seinen Konsumenten invalidiert, ohne die Event-Demo neu zu bauen. make check umfasst diese Regressionsprüfung, den semantischen Deobfuskierungs-Benchmark sowie die Rust-Testsuiten des Backends und des Deobfuskator-Workers. Es führt außerdem den HTTP/CLI-Integrationstest für Source-Facts gegen den gebauten Rust/Oxc-Worker aus; CARGO_TARGET_DIR wird beim Auffinden dieses Helfers berücksichtigt.

make native-proxy-policy-check kompiliert und führt die native Proxy/Container-Policy-Suite aus, die nur der Vorbereitung dient, ohne Chromium, Cargo, Sockets oder einen Browser. Sie ist in make check und make sanitize enthalten; sie etabliert keine echte Browser-Routing- oder Isolationsfunktion. Siehe den versionierten nativen Proxy-Container-Vertrag.

origin-trace-backend baut den Rust-HTTP-Dienst, den VM-Analyzer und die API-CLI. ui startet diesen Dienst nach der deterministischen Evidence-Generierung. backend-e2e verwendet ein wegwerfbares Chromium-kompatibles Profil und synthetische Localhost-Fixtures; setze ORIGIN_TRACE_TEST_BROWSER für eine nicht standardmäßige Browser-Executable. App-Builds bündeln Rust-Executables und statische UI-Assets, ohne Abhängigkeit von einer Python-Laufzeitumgebung.