es/catkin/package.xml

Contents

Descripción general
Formato 2 (Recomendado)
Formato 1 (Legacy)

Descripción general

El manifiesto del paquete (package manifest) es un archivo XML llamado 'package.xml' que debe incluirse con la carpeta raíz de cualquier paquete compatible con catkin. Este archivo define propiedades sobre el paquete, como el nombre del paquete, los números de versión, los autores, los mantenedores y las dependencias de otros paquetes catkin. Tenga en cuenta que el concepto es similar al archivo manifest.xml utilizado en el sistema de compilación heredado rosbuild.

Las dependencias del paquete del sistema se declaran en package.xml. Si faltan o son incorrectos, es posible que pueda compilar desde el código fuente y ejecutar pruebas en su propia máquina, pero su paquete no funcionará correctamente cuando se publique en la comunidad ROS. Otros dependen de esta información para instalar el software que necesitan para usar su paquete ( doc orientado a dependencias para catkin en U-Texas).

Formato 2 (Recomendado)

Este es el formato recomendado para paquetes nuevos. También se recomienda que los paquetes de formato 1 más antiguos se migren al formato 2. Para obtener instrucciones sobre cómo migrar del formato 1 al formato 2, consulte Migrating from Format 1 to Format 2 en los documentos de la API catkin.

La documentación completa para el formato 2 se puede encontrar en los documentacion de la API catkin. Tambien puede encontrar más información en especificación del formato de manifiesto dos de paquete.

Estructura Básica

Cada archivo package.xml tiene la etiqueta <package> como etiqueta raíz en el documento.

<package format="2">

</package>

Etiquetas necesarias

Hay un conjunto mínimo de etiquetas que deben anidarse dentro de la etiqueta <package> para completar el manifiesto del paquete.

<name> - El nombre del paquete
<version> - El número de versión del paquete (se requiere que sean tres números enteros separados por puntos)
<description> - Una descripción del contenido del paquete.
<maintainer> - El nombre de la (s) persona (s) que mantiene el paquete
<license> - Las licencias de software (por ejemplo, GPL, BSD, ASL) bajo las cuales se publica el código.

Como ejemplo, aquí está el manifiesto del paquete para un paquete ficticio llamado foo_core .

<package format="2">
  <name>foo_core</name>
  <version>1.2.4</version>
  <description>
  This package provides foo capability.
  </description>
  <maintainer email="ivana@osrf.org">Ivana Bildbotz</maintainer>
  <license>BSD</license>
</package>

Dependencias

El manifiesto del paquete con etiquetas mínimas no especifica ninguna dependencia de otros paquetes. Los paquetes pueden tener seis tipos de dependencias:

'Build Dependencies' especifica qué paquetes son necesarios para construir este paquete. Este es el caso cuando se requiere cualquier archivo de estos paquetes en el momento de la compilación. Esto puede incluir encabezados de estos paquetes en el momento de la compilación, enlazar con las bibliotecas de estos paquetes o requerir cualquier otro recurso en el momento de la compilación (especialmente cuando estos paquetes están find_package()-editados en CMake). En un escenario de compilación cruzada, las dependencias de construcción son para la arquitectura de destino.
Build Export Dependencies especifica qué paquetes son necesarios para construir bibliotecas contra este paquete. Este es el caso cuando incluye transitivamente sus encabezados en encabezados públicos en este paquete (especialmente cuando estos paquetes se declaran como (CATKIN_) DEPENDS en catkin_package () en CMake).
Execution Dependencies (Dependencias de ejecución) especifican qué paquetes son necesarios para ejecutar código en este paquete. Este es el caso cuando depende de bibliotecas compartidas en este paquete (especialmente cuando estos paquetes se declaran como (CATKIN_) DEPENDS en catkin_package () en CMake).
Test Dependencies (Dependencias de prueba) específica solo dependencias adicionales para pruebas unitarias. Nunca deben duplicar las dependencias ya mencionadas como dependencias de compilación o ejecución.
Build Tool Dependencies (Dependencias de herramientas de compilación) específica las herramientas del sistema de compilación que este paquete necesita para compilarse por sí mismo. Normalmente, la única herramienta de construcción necesaria es catkin. En un escenario de compilación cruzada, las dependencias de la herramienta de compilación son para la arquitectura en la que se realiza la compilación.

* Documentation Tool Dependencies (Dependencias de herramientas de documentación) especifican las herramientas de documentación que este paquete necesita para generar documentación.

Estos seis tipos de dependencias se especifican mediante las siguientes etiquetas respectivas:

<depend> especifica que una dependencia es una dependencia de construcción, exportación y ejecución. Esta es la etiqueta de dependencia más utilizada.
<build_depend>
<build_export_depend>
<exec_depend>
<test_depend>
<buildtool_depend>
<doc_depend>

Todos los paquetes tienen al menos una dependencia, una dependencia de la herramienta de compilación en catkin, como muestra el siguiente ejemplo.

<package format="2">
  <name>foo_core</name>
  <version>1.2.4</version>
  <description>
    This package provides foo capability.
  </description>
  <maintainer email="ivana@osrf.org">Ivana Bildbotz</maintainer>
  <license>BSD</license>

  <buildtool_depend>catkin</buildtool_depend>
</package>

Un ejemplo más realista que especifica las dependencias de compilación, ejecución, prueba y documentación podría verse de la siguiente manera.

<package format="2">
  <name>foo_core</name>
  <version>1.2.4</version>
  <description>
    This package provides foo capability.
  </description>
  <maintainer email="ivana@willowgarage.com">Ivana Bildbotz</maintainer>
  <license>BSD</license>

  <url>http://ros.org/wiki/foo_core</url>
  <author>Ivana Bildbotz</author>

  <buildtool_depend>catkin</buildtool_depend>

  <depend>roscpp</depend>
  <depend>std_msgs</depend>

  <build_depend>message_generation</build_depend>

  <exec_depend>message_runtime</exec_depend>
  <exec_depend>rospy</exec_depend>

  <test_depend>python-mock</test_depend>

  <doc_depend>doxygen</doc_depend>
</package>

Se pueden encontrar más detalles sobre las dependencias en los documentos de la API catkinaquí.

Metapaquetes

A menudo es conveniente agrupar varios paquetes como un único paquete lógico. Esto se puede lograr a través de metapaquetes (Metapackages). Un metapaquete es un paquete normal con la siguiente etiqueta de exportación en package.xml:

 <export>
   <metapackage />
 </export>

Aparte de una dependencia requerida de <buildtool_depends> en catkin, los metapaquetes solo pueden tener dependencias de ejecución en los paquetes que agrupan.

Además, un metapaquete tiene un archivo CMakeLists.txt repetitivo requerido:

cmake_minimum_required(VERSION 2.8.3)
project(<PACKAGE_NAME>)
find_package(catkin REQUIRED)
catkin_metapackage()

Nota: reemplace <PACKAGE_NAME> con el nombre del metapaquete (metapackage).

Etiquetas adicionales

<url> - Una URL para obtener información sobre el paquete, normalmente una página wiki en ros.org.
<author> - El (los) autor (es) del paquete

Formato 1 (Legacy)

Los paquetes de catkin más antiguos usan el formato 1. Si la etiqueta <package> no tiene el atributo format, es un paquete de formato 1. Utilice el formato 2 para paquetes nuevos.

El formato de package.xml es sencillo.

Estructura básica

Cada archivo package.xml tiene la etiqueta <package> como etiqueta raíz en el documento.

<package>

</package>

Etiquetas requeridas

Hay un conjunto mínimo de etiquetas que deben anidarse dentro de la etiqueta <package> para completar el manifiesto del paquete.

* <name>: el nombre del paquete * <version>: el número de versión del paquete (se requiere que sean tres números enteros separados por puntos) * <description>: una descripción del contenido del paquete * <maintainer>: el nombre de las personas que mantienen el paquete * <licencia>: las licencias de software (por ejemplo, GPL, BSD, ASL) bajo las cuales se publica el código.

Como ejemplo, aquí está el manifiesto del paquete para un paquete ficticio llamado foo_core .

<package>
  <name>foo_core</name>
  <version>1.2.4</version>
  <description>
  This package provides foo capability.
  </description>
  <maintainer email="ivana@willowgarage.com">Ivana Bildbotz</maintainer>
  <license>BSD</license>
</package>

Construir, ejecutar y probar dependencias

El manifiesto del paquete con etiquetas mínimas no especifica ninguna dependencia de otros paquetes. Los paquetes pueden tener cuatro tipos de dependencias:

Build Tool Dependencies (Dependencias de herramientas de compilación) específica las herramientas del sistema de compilación que este paquete necesita para compilarse por sí mismo. Normalmente, la única herramienta de construcción necesaria es catkin. En un escenario de compilación cruzada, las dependencias de la herramienta de compilación son para la arquitectura en la que se realiza la compilación.
Build Dependencies (Dependencias de compilación) especifica qué paquetes son necesarios para construir este paquete. Este es el caso cuando se requiere cualquier archivo de estos paquetes en el momento de la compilación. Esto puede incluir encabezados de estos paquetes en el momento de la compilación, enlazar con las bibliotecas de estos paquetes o requerir cualquier otro recurso en el momento de la compilación (especialmente cuando estos paquetes están "find_package ()" - editados en CMake). En un escenario de compilación cruzada, las dependencias de construcción son para la arquitectura de destino.
Run Dependencies(Dependencias de ejecución) especifica qué paquetes son necesarios para ejecutar código en este paquete, o construir bibliotecas contra este paquete. Este es el caso cuando depende de bibliotecas compartidas o incluye transitivamente sus encabezados en encabezados públicos en este paquete (especialmente cuando estos paquetes se declaran como (CATKIN_) DEPENDS en catkin_package () en CMake).
Test Dependencies (Dependencias de prueba) especifica solo dependencias adicionales para pruebas unitarias. Nunca deben duplicar las dependencias ya mencionadas como dependencias de compilación o ejecución.

Estos cuatro tipos de dependencias se especifican mediante las siguientes etiquetas respectivas:

<buildtool_depend>
<build_depend>
<run_depend>
<test_depend>

Todos los paquetes tienen al menos una dependencia, una dependencia de la herramienta de compilación en catkin, como muestra el siguiente ejemplo.

<package>
  <name>foo_core</name>
  <version>1.2.4</version>
  <description>
    This package provides foo capability.
  </description>
  <maintainer email="ivana@willowgarage.com">Ivana Bildbotz</maintainer>
  <license>BSD</license>

  <buildtool_depend>catkin</buildtool_depend>
</package>

Un ejemplo más realista que especifica las dependencias de compilación, tiempo de ejecución y prueba podría tener el siguiente aspecto.

<package>
  <name>foo_core</name>
  <version>1.2.4</version>
  <description>
    This package provides foo capability.
  </description>
  <maintainer email="ivana@willowgarage.com">Ivana Bildbotz</maintainer>
  <license>BSD</license>

  <url>http://ros.org/wiki/foo_core</url>
  <author>Ivana Bildbotz</author>

  <buildtool_depend>catkin</buildtool_depend>

  <build_depend>message_generation</build_depend>
  <build_depend>roscpp</build_depend>
  <build_depend>std_msgs</build_depend>

  <run_depend>message_runtime</run_depend>
  <run_depend>roscpp</run_depend>
  <run_depend>rospy</run_depend>
  <run_depend>std_msgs</run_depend>

  <test_depend>python-mock</test_depend>
</package>

Se pueden encontrar más detalles sobre las dependencias aquí.

Metapaquetes

A menudo es conveniente agrupar varios paquetes como un único paquete lógico. Esto se puede lograr a través de 'metapaquetes' . Un metapaquete (Metapackages) es un paquete normal con la siguiente etiqueta de exportación en package.xml:

 <export>
   <metapackage />
 </export>

Aparte de una dependencia requerida de <buildtool_depends> en catkin, los metapaquetes solo pueden tener dependencias de ejecución en los paquetes que agrupan.

Además, un metapaquete tiene un archivo CMakeLists.txt repetitivo requerido:

cmake_minimum_required(VERSION 2.8.3)
project(<PACKAGE_NAME>)
find_package(catkin REQUIRED)
catkin_metapackage()

Nota: reemplace <PACKAGE_NAME> por el nombre del metapaquete (metapackage).

El metapaquete ahora tiene archivos CMakeLists.txt después de una discusión sobre la instalación de los archivos package.xml en:

https://groups.google.com/forum/#!msg/ros-sig-buildsystem/mn-VCkl2OHk/dUsHBBjyK30J

Así que ahora los archivos package.xml para los metapaquetes están instalados, pero el requisito de que otros paquetes no dependan de los metapaquetes aún se aplica al requerir que los usuarios no se desvíen del código repetitivo CMakeLists.txt sugerido.

Etiquetas Adicionales

<url> - Una URL para obtener información sobre el paquete, normalmente una página wiki en ros.org.
<author> - El (los) autor (es) del paquete

Para mas información vea http://ros.org/reps/rep-0127.html