Now we can see it has different cases in the ros2 packages which are cloned with the repo file:
One case, it has a top CMakeLists.txt e.g example_interfaces and I think it should be built normally for various building environment and OS
The other case, the project doesn’t contain any root CMakeLists.txt but separate CMakeLists.txt in each sub-folder (or say sub-projects/sub-packages) e.g RCL and ament_cmake, This is very common in the ROS with the concept of meta package and I know that it works well to build with ament/colcon, but why it works is because the ament/colcon manually add codes to handle the kind of projects. but it’s not the same for all the build environment and it will results in build failure when it doesn’t find a top CMakeLists.txt
with a top CMakeLists.txt, it works for all, because it is the standard behaviour to CMake, so why not to add a top CMakeLists.txt to organize and propagate the whole building with the subsidiary packages or projects to make it standard ? or once the “No CMakeLists.txt” error found, there are so many packages to handle for this kind of ROS2 packages.(actually, now I met this kind of error when I try to enable ROS2 with another environment which merely supports to pass source tarball of a project (e.g rcl) to build the package (e.g) as RPM package)
PS: I know that it also works to wrap the corresponding build environment just like ament/colcon to bypass that kind of “No CMakeLists.txt” issue, but I’m try to discuss why not make it as the standard way of working for CMake directly, thanks !
Repositories such as rcl are not a single CMake project. They are a collection of related packages and they do not necessarily need or want to be built as a single CMake project. They are designed to be build individually but in the correct order. The build order may be non-trivial, for example, or you might ant to only build one package from a large repository. This is why although you can clone the repository to get all the packages at once, you need to use a tool like colcon to build them. colcon will sort out things like the build order automatically based on information in the package.xml file, which often contains information not found in the CMakeLists.txt file. Furthermore, some repositories may have a mix of C/C++ and Python (or other language) packages. It wouldn’t be feasible to insist that these all have a top level CMakeLists.txt file.
Thanks for the feedback, so… if we want to build those ros2 packages as RPM package, we need to wrap a copy of the implementation as what the ament_cmake and ament_package implements for rpmbuild in order to enable normal building the source tarball of those ros2 packages given the right run-time environment /dependencies of cmake building process ? @dirk-thomas
Is there some possibility to simplify this work or reduce the effort while porting what ament_* packages are doing for rpmbuild ?
The RPM spec file generation doesn’t yet support the build types needed for ROS 2. It was refactored to allow for support to be contributed and I’ll make every effort to review pull requests and provide guidance in that direction. I’m not familiar enough with the RPM generation to estimate how much change is required from the catkin build types.
ok. thanks. what needs to contain in binary package installation of debian/RPM is the content under the install folder of the corresponding package, am I right ? If it’s right, does it work with the following process for RPM creation for quick prototype/verification? as follow:
For RPM %build part: invoke the colcon to build a package normally as the way to build with source code
For RPM %install and %files part: manually add the content of the corresponding package underneath the install folder of the workspace (that’s to say you have already know the details of the install folder with the way of source building)
finally, rpmbuild with the above rules of spec file to create the RPM package
I know that it’s not feasible to manually create spec and RPM for many package in this way, and it also requires a great deal of effort to maintain, just try to verify one project before further code development.
Packages built with bloom templates use the default build tool for their build type, cmake for cmake, catkin, and ament_cmake, and python setuptools for python packages respectively rather than using the recommended build tool for working with source workspaces.
