This is not necessarily ROS version specific I believe.
With bloom I know I can release ROS2 packages into the ROS2 build farm and CI. My question is where is it defined what is available in the build beyond what's specified in the CMakeLists.txt
and package.xml
?
Afaik nothing can be expected to "be available".
All builds (in ROS 2) start from a clean ubuntu:focal
(or debian:buster
, debian:stretch
, etc) Docker image which contains no build tools, no CMake, no compilers, etc (ROS 1 builds start from whichever Docker image contains the clean OS which they target). This is to make sure builds are not contaminated by anything which might happen to have been installed "before" -- as would be the case on your development machine for instance. This is similar to how Debian/Ubuntu builds its packages: in a clean environment with the absolute minimum of packages present.
Build-depending on catkin
, or ament_cmake
or similar packages will pull in the required dependencies: dependencies for Catkin and dependencies for ament_cmake.
Is it expected to build with colcon
?
Well, yes and no.
In the case of CMake, the package is expected to build successfully when following the regular cmake
workflow for builds (ie: mkdir build && cd build && cmake .. -DSOME_CMAKE_OPTION .. -DSOME_OTHER_OPTION
or the more modern equivalent cmake --build ..
).
In the case of a plain Python setup.py
(ie: setuptools
), it should just build as you'd normally build a Python package (ie: with python setup.py install
(or more modern equivalent)).
In the case of "build system X", it should build successfully with "build system X".
So: yes: your package should build successfully, but no, not necessarily "with colcon
". It should build, period. The fact the buildfarm may use Colcon to drive the build should not really matter -- as long as Colcon can drive your build.
Colcon is essentially (sorry @Dirk Thomas ) "nothing more" than a tool which invokes cmake
in the right order in the right places with the right flags. Or Bazel, or plain setup.py
, or build system X
. This is valuable with workspaces, as they contain potentially many packages which need to be built in a specific order and with specific flags. That's what Colcon automates.
The buildfarm does not actually use Colcon to build the binary .deb
packages (in the case of release jobs for Debian/Ubuntu): it uses a regular dpkg-buildpackage
pipeline, which for CMake-based projects will call plain CMake with the appropriate flags. All packages on which a job depends should already be available as .deb
s themselves, so there is no workspace, and Colcon is not needed to drive a build.
Where are the other available dependencies for the build specified like gcc
, cmake
, make
, clang
, pip installed python packages, etc?
There is nothing "available" by default. You need to declare all build and run (and test) dependencies explicitly in your package's manifest.
How can I add or modify those additional dependencies for the build?
By adding ... (more)