ccws
1.0.0
| CI -Status |
|---|
CCWS ist eine Entwicklungsumgebung für ROS, die die Funktionalität herkömmlicher catkin Arbeitsbereiche und CI-Pipelines integriert, um (Kreuz-) Zusammenstellung, Testen, Linie, Dokumentation und Binärpaket zu erleichtern. Es soll sowohl als CI/CD -Rückgrat als auch als Arbeitsumgebung für Entwickler verwendet werden. Beachten Sie, dass CCWS keine vollständige Lösung sein soll, sondern eine Grundlage für die Entwicklung eines herstellerspezifischen Workflows.
CCWS ist ROS -Version Agnostisch und sollte in den meisten Fällen sowohl für ROS1 als auch für ROS2 funktionieren.
Build -Profile - Konfigurationssätze für den Build -Prozess, z. B. CMake Toolchain, Colcon -Konfiguration, Umgebungsvariablen usw. Profile in Konflikt nicht miteinander und können parallel verwendet werden, ohne separate Klone des Arbeitsbereichs und der Pakete zu verwenden.
Ausführungsprofile - einfache Shell -Mixins, die zur Änderung der Laufzeitumgebung, z. B. Knoten in valgrind , Änderung der Knoten -Crash -Handhabung usw. vorgesehen sind, usw.
Eine Reihe von Funktionen, die über Build -Profile implementiert werden:
Überschreitung auf mehrere gemeinsame Plattformen.
Dokumentationsgenerierung für den gesamten Arbeitsbereich oder ausgewählten Paketen mit doxygen , ähnlich wie https://github.com/mikepurvis/catkin_tools_document.
LINTING MIT clang-tidy UND scan_build .
Insbesondere in https://github.com/sscpac/statick, insbesondere in https://github.com/sscpac/Statick:
cppcheckcatkin_lint https://github.com/fkie/catkin_lintyamllintshellcheckBinärer Debian -Paketgenerierung.
Paketvorlage, die demonstriert, wie einige Funktionen verwendet werden.
Die Anzahl der parallelen Jobs kann basierend auf verfügbaren RAM anstelle von CPU -Kernen ausgewählt werden, da RAM wahrscheinlich der begrenzende Faktor ist.
Basiert ausschließlich auf make und Shell -Skripten. Alle Skripte und Konfigurationen werden im Arbeitsbereich aufbewahrt und einfach auf bestimmte Anforderungen eingestellt.
Profilkonfigurationen befinden sich in ccws/profiles/build . common Unterverzeichnis enthält Standardparameter, die durch bestimmte Profile überschrieben werden können:
reldebug - Standard Compiler, CMake Build -Typ ist RelWithDebInfoscan_build -Statische Überprüfungen mit scan_build und clang-tidy . clang-tidy -Parameter werden in CMake Toolchain definiert und müssen in Paketen aktiviert werden, wie in Paketvorlagen CMakeLists gezeigt. Dieses Profil verwendet auch clang Compiler.thread_sanitizer - Kompilierung mit Thread Desinfektionsmittel.addr_undef_sanitizers - Zusammenstellung mit Adress- und undefinierten Verhaltensdeckisatoren.static_checks - Statische Prüfer und deren Konfiguration.doxygen - Doxygen und seine Konfiguration.cross_raspberry_pi -Cross-Compilation für Raspberry Pi.cross_jetson_xavier -Cross-Compilation für Jetson Xavier.cross_jetson_nano -Cross-Compilation für Jetson Nano.clangd - Sammelt Kompilierungsbefehle für eine bestimmte BASE_BUILD_PROFILE und generiert eine Clangd -Konfigurationsdatei im Arbeitsbereich.deb - Debian Package Generation (siehe unten). Ausführungsprofile setzen Umgebungsvariablen, die in Startskripten verwendet werden können, um das Laufzeitverhalten zu ändern, wie in ccws/pkg_template/catkin/launch/bringup.launch gezeigt werden, derzeit verfügbare Profile sind:
common - Eine Reihe gemeinsamer ROS -Parameter, z. B. ROS_HOME , ist automatisch in Binärpaketen enthalten.test - Legt CCWS_NODE_CRASH_ACTION -Variable fest, so dass Knoten, die es respektieren, required , dh die Beendigung solcher Knoten würde zum Absturz von Testskripten führen und somit leicht zu erkennen sein können.valgrind - Legt CCWS_NODE_LAUNCH_PREFIX auf valgrind und einige Variablen fest, die das Verhalten von valgrind steuern.core_pattern - Legt das Kernmuster fest, um Kerndateien im Artefaktverzeichnis zu speichern.address_sanitizer - Helfer für addr_undef_sanitizers -Profil. Ausführungsprofile haben keinen Einfluss auf den Build -Prozess und werden in *test* Zielen oder Debian -Paketen berücksichtigt. test wird immer in Tests verwendet, und zusätzliche Profile können mit EXEC_PROFILE="<profile1> <profile2>" bereitgestellt werden. Diese Ziele laden Profile mithilfe von setup.bash -Skript im Stammordner von CCWS , das auch manuell verwendet werden kann, z. B. source setup.bash [<build_profile> [<exec_profile1> ...]] . Beachten Sie, dass das Setup -Skript immer ein common Profil enthält und test verwendet, wenn keine anderen Ausführungsprofile angegeben sind.
Die Abhängigkeiten können mithilfe von make bp_install_build BUILD_PROFILE=<profile> installiert werden. Dies wird die folgenden Tools und profilspezifischen Abhängigkeiten installieren:
colconyq - https://github.com/asherikov/wshandler Abhängigkeitcmakeccache - kann in CMake -Toolchains deaktiviert werdenwget Siehe .ccws/test_main.mk für Befehlsnutzungshinweise.
make/config.mk hinzufügen, verfügbare Parameter finden Sie im oberen Abschnitt von Makefile .make bp_install_build BUILD_PROFILE=<profile> Ziele, Kreuzkompilierungsprofile würden einige zusätzliche Schritte erfordern, wie unten beschrieben. In einigen minimalistischen Umgebungen müssen Sie möglicherweise ausführen ./ccws/scripts/bootstrap.sh bevor Sie bp_install_build Ziel verwenden, um make und andere Utils zu installieren.src -Unterverzeichnis oder neu erstellen, indem Sie make new PKG=<pkg> . make build PKG="<pkg>" wobei <pkg> ein oder mehrere Speicherplätze für Paketnamen ist.make <pkg> - eine Abkürzung für make build , aber <pkg> kann ein Unterstrich des Paketnamens sein. Alle Pakete, die dem angegebenen Substring entsprechen, werden erstellt.JOBS=X Parameter überschrieben werden.make build PKG=<pkg> BUILD_PROFILE=scan_build überschreiben das Standardprofil. setup.bash <profile> Um Pakete zu verwenden. Von colcon generierte Einstellungsskripte können auch direkt verwendet werden, z. B. install/<profile>/local_setup.sh , in diesem Fall sind jedoch einige der CCWS -Funktionalität nicht verfügbar. make test PKG=<pkg> Test mit colcon oder make wstest , um alle zu testen.make ctest PKG=<pkg> Colcon Bypass colcon und führen Sie ctest direkt aus oder make wsctest , um alle zu testen. make BUILD_PROFILE=doxygen , firefox artifacts/doxygen/index.html CCWS verfolgt einen etwas ungewöhnlichen Ansatz für die binäre Paketgenerierung, ein Mittelweg zwischen herkömmlichem ROS (1 Paket = 1 Deb) und Docker -Containern: Alle im Arbeitsbereich gebauten Pakete werden zu einem einzigen Debian -Superpackage zusammengepackt. Im Gegensatz zu bloom erzeugt CCWS Binärpakete direkt, anstatt zuerst Quellpakete zu generieren.
Die Binärpaketgenerierung wird als Build -Profil -Mixin implementiert, das über ein willkürliches Build -Profil überlagert werden kann: make <pkg> BUILD_PROFILE=deb BASE_BUILD_PROFILE=reldebug .
CCWS -Ansatz hat eine Reihe von Vorteilen:
Binärkompatibilitätsprobleme werden im Vergleich zum herkömmlichen ROS -Ansatz minimiert:
Sie müssen sich keine Sorgen um Kompatibilitäten zwischen mehreren eigenständigen Binärpaketen machen und ABI -Überprüfungen durchführen.
Wenn Basis -ROS -Pakete enthalten sind, ist es auch möglich, binäre Inkompatibilitäten zwischen den Synchronisierungen derselben ROS -Freisetzung zu vermeiden (die tatsächlich passieren).
Das Paket -Repository -Management kann als ROS im Vergleich zu ROS bei Tags, Versionen, Git -Submodulen usw., z. B. nicht erforderlich, keine Release -Repos für alle Pakete beibehalten.
Debian 'Superpackages' sind leichter zu handhaben als eigenständige Pakete und Docker -Container, z. B. können sie von Entwicklern aus ihren Arbeitszweigen generiert und einfach auf dem Ziel kopiert und installiert werden.
Debian -Pakete haben einige Vorteile gegenüber Docker -Containern im Allgemeinen:
Null Overhead während der Ausführung.
Einfacher Zugriff auf Hardware.
Einfache Installation von Systemdiensten, Udev -Regeln, Konfigurationen usw.
Verschiedene Versionen von Binärpaketen können gleichzeitig installiert werden, wenn sie unter Verwendung verschiedener VERSION erstellt werden.
Im Allgemeinen ist es erforderlich, Pakete im Dateisystem während der Kompilierung zu installieren, um alle Pfade direkt in catkin cmake -Dateien zu erhalten und Systemdateien ordnungsgemäß zu installieren. CCWS vermeidet dies mit proot ähnlich wie mit Querkompilierungsprofilen.
Hier <profile> steht für cross_raspberry_pi , cross_jetson_xavier , cross_jetson_nano . Cross-Compilation Make-Ziele finden Sie in ccws/make/cross.mk und ccws/profiles/<profile>/targets.mk
Hinweis zu cross_jetson_xavier und cross_jetson_nano : Diese Profile erfordern Ubuntu 18.04 / ROS melodisch und installieren Sie nvcc . Möglicherweise möchten Sie dies in einem Container tun.
Der allgemeine Workflow ist nachstehend dokumentiert. Weitere technische Details finden Sie ccws/doc/cross-compilation.md und CCWS -CI-Test in .ccws/test_cross.mk :
make bp_install_build BUILD_PROFILE=<profile>cross_raspberry_pi - bp_install_build Ziel lädt automatisch das Standardbild herunter;cross_jetson_xavier , cross_jetson_nano - CCWS erhält ccws/profiles/cross_jetson_xavier/system.img Bilder nicht automatisch.make wsinit REPOS="https://github.com/asherikov/staticoma.git"make dep_to_repolist PKG=<pkg> ROS_DISTRO=melodic den Arbeitsbereich ROS -Abhängigkeiten aller Ihrer Pakete make dep_to_repolist ROS_DISTRO=melodic .make wsupdate .make cross_install PKG=staticoma BUILD_PROFILE=<profile> ROS_DISTRO=<distro>make cross_mount BUILD_PROFILE=<profile>make staticoma BUILD_PROFILE=<profile> oder erstellen und generieren Deb -Paket make deb PKG=staticoma BUILD_PROFILE=<profile>make cross_umount BUILD_PROFILE=<profile> ausgeführt werdenCCWS Docker Für das Testen steht ein Docker -Bild mit vorinstallierten CCWS und Abhängigkeiten zur Verfügung. Es wird jedoch empfohlen, ein maßgeschneidertes Bild mit ccws/examples/Dockerfile als Beispiel zu erstellen.
Das Bild kann auf folgende Weise verwendet werden:
docker pull asherikov/ccwsmkdir tmp_ws # Quellen, erstellen, installieren, Cache wird hier gehendocker run --rm -ti -v ./tmp_ws:/ccws/workspace asherikov/ccws bashmake wsinit REPOS="https://github.com/asherikov/qpmad.git"...CCWS erweitern CCWS -Funktionalität kann auf verschiedene Weise erweitert werden:
make bp_new BUILD_PROFILE=vendor_static_checks BASE_BUILD_PROFILE=static_checks vendor werden alle Profile von Git ignoriert.make können hinzugefügt werden, indem eine ccws/profiles/build/vendor/<filename>.mk -Datei erstellt werden.ccws/profiles/build/vendor/toolchain_suffix.cmake kann zu einem gemeinsamen cmake Toolchain -Suffix zugefügt werden. Segmentierungsfehler während der Cross-Compilation- oder Debian-Paketgenerierung Indside Docker-Container (beide erfordern proot ): Vermutlich aufgrund der seccomp Linux-Funktion, die mit dem Parameter --security-opt seccomp:unconfined deaktiviert werden kann. Deaktivieren von seccomp für proot mit PROOT_NO_SECCOMP=1 scheint unnötig zu sein.
Programme, die mit Desinfektionsmittel ( addr_undef_sanitizers oder thread_sanitizer Build -Profile) kompiliert wurden, Ausgabe 2: AddressSanitizer:DEADLYSIGNAL oder FATAL: ThreadSanitizer: unexpected memory mapping Bei Ausführung: Der Grund ist festgezogene Speichersicherheit mit ASLR (Adresse Space Layout) in modernen Linux -Kerneln, siehe Google/Sanitier#1614. Das Problem kann gelindert werden, indem sudo sysctl vm.mmap_rnd_bits=28 festgelegt wird.
Einige von ROS2 -Kernpaketen können aufgrund von CMAKE -Missbrauch, z. B. Ament/Google_Benchmark_Vendor#17, nicht mit CCWS erstellt werden.
proot Segfault beim Bau auf ARM64 in Ubuntu 22, z. B. beim Bau von Debian -Paketen. Eine neuere Version von proot muss verwendet werden, siehe Proot-Me/Proot#312.
github , die einige der CCWS Funktionalität abdeckt.ccache durch https://github.com/mbitsnbites/buildcache.clang-tidy -Ausführungen zu untersuchen.scan_build https://github.com/ericsson/codechecker mit zusätzlichen Schecks und Caching.dpkg-deb .catkin_make Build-Umgebungen haben.guestfs ist zu langsam, um praktisch zu sein.valgrind hinzu. gcc unterstützt es derzeit nicht.valgrind Ausführungsprofil-Ein Overkill im allgemeinen Fall.CodeQL -Profil hinzu (https://github.com/github/codeql).
