La descripción de package.xml proporcionada por el sitio web oficial de ROS es probablemente la más completa.

La descripción de package.xml proporcionada por el sitio web oficial de ROS es probablemente la más completa.

Obtenido de: http://wiki.ros.org/catkin/package.xml

 

• pendiente
• paquete.xml

Wiki

• Distribuciones
• ROS / Instalación
• ROS / Tutoriales
• Cambios recientes
• catkin / package.xml

Página web

• Página de solo lectura
• información
• anexo

• Más operaciones:

•  

usuario

• iniciar sesión

 

Tabla de contenido

1. Visión general
2. Formato 2 (recomendado)
   1. Estructura basica
   2. Etiquetas requeridas
   3. Dependencias
   4. Metapaquetes
   5. Etiquetas adicionales
3. Formato 1 (heredado)
   1. Estructura basica
   2. Etiquetas requeridas
   3. Construir, ejecutar y probar dependencias
   4. Metapaquetes
   5. Etiquetas adicionales

 

 

 

Visión general

El manifiesto del paquete 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 rosbuild heredado .

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 (excepto el documento orientado a tareas 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 Migración del formato 1 al formato 2 en los documentos de API catkin.

La documentación completa para el formato 2 se puede encontrar en los documentos de la API catkin . Se puede encontrar más información en REP 140 - Especificación del formato dos de manifiesto de paquete .

 

Estructura basica

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

<package format = "2"> 

</package>

 

Etiquetas requeridas

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

• <nombre>: el nombre del paquete

• <versión>: 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 format = "2"> 
  <name> foo_core </name> 
  <version> 1.2.4 </version> 
  <description> 
  Este paquete proporciona la capacidad foo. 
  </description> 
  <mantenedor email = "[email protected]"> 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:

• Las dependencias de compilación especifican qué paquetes se necesitan para compilar 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 se encuentran en el formato find_package () en CMake). En un escenario de compilación cruzada, las dependencias de construcción son para la arquitectura de destino.

• Las dependencias de exportación de compilación especifican qué paquetes se necesitan para compilar bibliotecas con 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).

• Las dependencias de ejecución especifican qué paquetes se necesitan 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).

• Las dependencias de prueba especifican solo dependencias adicionales para las pruebas unitarias. Nunca deben duplicar las dependencias ya mencionadas como dependencias de compilación o ejecución.

• Las dependencias de herramientas de compilación especifican las herramientas del sistema de compilación que este paquete necesita para compilarse. 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.

• Las 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> 
    Este paquete proporciona la capacidad foo. 
  </description> 
  <mantenedor email = "[email protected]"> 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> 
    Este paquete proporciona la capacidad foo. 
  </description> 
  <mantenedor email = "[email protected]"> Ivana Bildbotz </maintainer> 
  <license> BSD </license> 

  <url> http://ros.org/wiki/foo_core </url> 
  <autor > 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>


</paquete>

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

 

Metapaquetes

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

 

<export> 
   <metapackage /> 
 </export>

Aparte de una dependencia <buildtool_depends> requerida 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) 
proyecto (<PACKAGE_NAME>) 
find_package (catkin 
REQUIRIDO ) catkin_metapackage ()

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

 

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 (heredado)

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

El formato de package.xml es sencillo.

 

Estructura basica

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

<paquete> 

</paquete>

 

Etiquetas requeridas

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

• <nombre>: el nombre del paquete

• <versión>: 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> 
  Este paquete proporciona la capacidad foo. 
  </description> 
  <mantenedor email = "[email protected]"> 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:

• Las dependencias de herramientas de compilación especifican las herramientas del sistema de compilación que este paquete necesita para compilarse. 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.

• Las dependencias de compilación especifican qué paquetes se necesitan para compilar 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 se encuentran en el formato find_package () en CMake). En un escenario de compilación cruzada, las dependencias de construcción son para la arquitectura de destino.

• Las dependencias de ejecución especifican qué paquetes son necesarios para ejecutar el código en este paquete o compilar bibliotecas con 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).

• Las dependencias de prueba especifican solo dependencias adicionales para las 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> 
    Este paquete proporciona la capacidad foo. 
  </description> 
  <mantenedor email = "[email protected]"> 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> 
    Este paquete proporciona la capacidad foo. 
  </description> 
  <mantenedor email = "[email protected]"> Ivana Bildbotz </maintainer> 
  <license> BSD </license> 

  <url> http://ros.org/wiki/foo_core </url> 
  <autor > 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> std_msgs </run_depend> 

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

Puede encontrar más detalles sobre las dependencias aquí .

 

Metapaquetes

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

 

<export> 
   <metapackage /> 
 </export>

Aparte de una dependencia <buildtool_depends> requerida 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) 
proyecto (<PACKAGE_NAME>) 
find_package (catkin 
REQUIRIDO ) catkin_metapackage ()

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

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

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 obtener más información, consulte http://ros.org/reps/rep-0127.html