À propos du système de construction
Sous tout se trouve le système de construction. En itérant sur catkin
à partir de ROS 1, nous avons créé un ensemble de packages sous le surnom ament
. Certaines des raisons pour changer le nom en ament
sont que nous voulions qu’il n’entre pas en collision avec catkin
(au cas où nous voudrions les mélanger à un moment donné) et pour éviter toute confusion avec catkin
existant Documentation. La principale responsabilité de ament
est de faciliter le développement et la maintenance des noyaux packages de ROS 2. Cependant, cette responsabilité s’étend à tout utilisateur qui souhaite utiliser nos conventions et outils de système de construction. De plus, il devrait faire des packages conventionnel, de sorte que les développeurs devraient être capables de choisir n’importe quel package basé sur ament
et faites des hypothèses sur son fonctionnement, comment l’introspecter et comment le construire ou l’utiliser.
ament
se compose de quelques dépôts importants qui sont tous dans l’organisation ament
GitHub :
Le paquet ament_package
Situé sur GitHub à ament/ament_package, ce référentiel contient un seul ament Python package qui fournit divers utilitaires pour ament packages, par exemple. modèles pour les crochets d’environnement.
Tous les forfaits |ament| doit contenir un seul fichier package.xml à la racine du paquet, quel que soit son système de construction sous-jacent. Le fichier « manifest » package.xml contient les informations requises pour traiter et opérer sur un package. Ce |forfait| Les informations incluent des éléments tels que le nom du package, qui est unique au monde, et les dépendances du package. Le fichier package.xml sert également de fichier marqueur qui indique l’emplacement du package sur le système de fichiers.
L’analyse des fichiers package.xml est fournie par catkin_pkg
(comme dans ROS 1), tandis que la fonctionnalité permettant de localiser packages en recherchant dans le système de fichiers ces fichiers package.xml est fourni par des outils de construction tels que colcon
.
- package.xml
Fichier manifeste de package qui marque la racine d’un package et contient des méta-informations sur le package, notamment son nom, sa version, sa description, son responsable, sa licence, ses dépendances, etc. Le contenu du manifeste est au format XML lisible par machine et le contenu est décrit dans les REPs 127 et 140, avec le possibilité de modifications ultérieures dans les futurs REPs.
Donc, à tout moment, un package est appelé ament package, cela signifie qu’il s’agit d’une seule unité de logiciel (code source, fichiers de construction, tests, documentation et autres ressources) qui est décrite à l’aide d’un :term:`package.xml ` fichier manifeste.
- forfait actuel
Tout |forfait| qui contient un package.xml et suit les directives d’empaquetage de
ament
, quel que soit le système de construction sous-jacent.
Étant donné que le terme paquet d’ament est indépendant du système de construction, il peut y avoir différents types de |paquets d'ament|, par ex. ament CMake package, ament Python package, etc.
Voici une liste des types de packages courants que vous pourriez rencontrer dans cette pile logicielle :
- Paquet CMake
Tout |forfait| contenant un projet CMake simple et un fichier manifeste package.xml.
- ament CMake package
Un paquet CMake qui suit également les directives de conditionnement de
ament
.- Paquet Python
Tout |forfait| contenant un projet Python basé sur setuptools et un fichier manifeste package.xml.
- actuellement package Python
Un paquet Python qui suit également les directives de conditionnement de
ament
.
Le référentiel ament_cmake
Situé sur GitHub à ament/ament_cmake, ce référentiel contient de nombreux packages « ament CMake » et CMake purs qui fournissent l’infrastructure dans CMake nécessaire pour créer packages « ament CMake ». Dans ce contexte, les packages « ament CMake » signifient : les packages ament
construits à l’aide de CMake. Alors les |paquets| dans ce référentiel, fournissez les fonctions/macros CMake nécessaires et les modules CMake pour faciliter la création de plusieurs packages « ament CMake » (ou ament_cmake
). Les packages de ce type sont identifiés par la balise <build_type>ament_cmake</build_type>
dans la balise <export>
du fichier package.xml.
Les |forfaits| dans ce référentiel sont extrêmement modulaires, mais il existe un seul « goulot d’étranglement » package appelé ament_cmake
. N’importe qui peut dépendre du package ament_cmake
pour obtenir toutes les fonctionnalités agrégées des packages dans ce référentiel. Voici une liste des packages dans le référentiel avec une courte description :
``ament_cmake””
agrège tous les autres packages dans ce référentiel, les utilisateurs n’ont qu’à dépendre de ce
ament_cmake_auto
fournit des fonctions CMake pratiques qui gèrent automatiquement une grande partie des parties fastidieuses de l’écriture du fichier
CMakeLists.txt
d’un package
ament_cmake_core
fournit tous les concepts de base intégrés pour
ament
, par ex. crochets d’environnement, indexation des ressources, installation de liens symboliques et autres
ament_cmake_gmock
ajoute des fonctions pratiques pour effectuer des tests unitaires basés sur gmock
``ament_cmake_gtest””
ajoute des fonctions pratiques pour effectuer des tests automatisés basés sur gtest
ament_cmake_nose
ajoute des fonctions pratiques pour effectuer des tests automatisés en python basés sur nosestests
``ament_cmake_python””
fournit des fonctions CMake pour packages contenant du code Python
ament_cmake_test
regroupe différents types de tests, par ex. gtest et nosetests, sous une seule cible en utilisant CTest
Le |paquet| ament_cmake_core
contient une grande partie de l’infrastructure CMake qui permet de transmettre proprement des informations entre packages à l’aide d’interfaces classiques. Cela rend les |paquets| ont des interfaces de construction plus découplées avec d’autres packages, favorisant leur réutilisation et encourageant les conventions dans les systèmes de construction de différents packages. Par exemple, il fournit un moyen standard de transmettre des répertoires d’inclusion, des bibliothèques, des définitions et des dépendances entre packages afin que les consommateurs de ces informations puissent accéder à ces informations de manière conventionnelle.
Le |paquet| ament_cmake_core
fournit également des fonctionnalités du système de construction ament
comme l’installation de liens symboliques, qui vous permet de lier symboliquement des fichiers depuis l’espace source ou l’espace de construction dans l’espace d’installation plutôt que de les copier. Cela vous permet d’installer une fois, puis de modifier les ressources non générées telles que le code Python et les fichiers de configuration sans avoir à réexécuter l’étape d’installation pour qu’elles prennent effet. Cette fonctionnalité remplace essentiellement « l’espace de développement » de catkin
car elle présente la plupart des avantages avec peu de complications ou d’inconvénients.
Une autre fonctionnalité fournie par ament_cmake_core
est le package l’indexation des ressources qui est un moyen pour les packages pour indiquer qu’ils contiennent une ressource d’un certain type. La conception de cette fonctionnalité la rend beaucoup plus efficace pour répondre à des questions simples comme quels packages sont dans ce préfixe (par exemple /usr/local
) car il vous suffit de répertorier les fichiers dans un seul emplacement possible sous ce préfixe. Vous pouvez en savoir plus sur cette fonctionnalité dans les documents de conception pour l’index des ressources.
Comme catkin
, ament_cmake_core
fournit également des fichiers de configuration d’environnement et package crochets d’environnement spécifiques. Les fichiers de configuration de l’environnement, souvent nommés quelque chose comme setup.bash
, sont un emplacement pour package aux développeurs de définir les changements d’environnement nécessaires pour utiliser leur package. Les développeurs peuvent le faire en utilisant un « hook d’environnement » qui est essentiellement un morceau arbitraire de code shell qui peut définir ou modifier des variables d’environnement, définir des fonctions shell, configurer des règles d’auto-complétion, etc. Cette fonctionnalité est comment, pour Par exemple, ROS 1 définit la variable d’environnement ROS_DISTRO
sans que catkin
sache quoi que ce soit sur la distribution ROS.
Le dépôt ``ament_lint””
Situé sur GitHub à ament/ament_lint, ce référentiel fournit plusieurs packages qui fournissent des services de peluchage et de test de manière pratique et cohérente. Actuellement, il y a des packages pour prendre en charge le linting de style C++ en utilisant uncrustify
, les vérifications de code C++ statiques en utilisant cppcheck
, la vérification des droits d’auteur dans le code source, le linting de style Python en utilisant pep8
, et d’autres choses. La liste des packages d’assistance s’allongera probablement à l’avenir.
Construire des outils
Un outil de génération effectue la tâche de créer un espace de travail de packages en même temps avec une seule invocation. Pour les versions ROS 2 jusqu’à Ardent, l’outil de construction fournissant cette fonctionnalité s’appelle ament_tools
. Depuis ROS 2 Bouncy, ament_tools
a été remplacé par colcon
, comme décrit dans the universal build tool article.