À 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””

  • 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.