add package types entry points

[dirk-thomas]

This patch adds entry points for package types. In contrast to the build type which determines how a package is being processed the package type identifies a folder as a package and determines how the necessary meta information about a package is provided. The relevant information for processing packages with ament consist of the package name as well as the package dependencies.

Until now only package.xml files have been considered. With this change ament looks additionally for the following files:

• CMakeLists.txt
• setup.py

For CMakeLists.txt files the name is extracted from the project(..) call. The dependencies are collected from all find_package(..) calls. Both happens without considering any CMake variable evaluation.

For setup.py files the name is extracted from the keyword argument name to the setup() call. The dependencies are collected from the keyword argument install_requires.

[jacquelinekay]

I did some testing with this branch by modifying the entry points for a few packages.

In cmake packages such as rclcpp_examples, the package does not build if the package.xml is removed outright (error from ament_cmake_core about missing package.xml). But if all of the dependencies in the package.xml are removed, the package builds (because ament_tools extracts the dependencies from CMakeLists.txt).

In python packages, if the package.xml is removed, the package builds.

This behavior makes sense because the setup.py files capture the same metadata as the package.xml, while the CMakeLists.txt does not provide fields like license, author, maintainer, etc.

Are there future plans to allow cmake packages without a package.xml and provide hooks in ament_cmake for setting those missing fields?

[dirk-thomas]

The build process does not needs any of the additional meta information (license, author, maintainer). Therefore I don't think ament_tools / ament_cmake need to care about them.

The information only becomes necessary when releasing a package with bloom. I would think we don't need to allow releasing of packages without a manifest.

[jacquelinekay]

I agree; I should ideally be able to build an ament_cmake package without a package.xml, since CMakeLists provides all the necessary information for building and installing the package.

+1

[dirk-thomas]

The entry points have no deterministic order by default. Therefore package types need to declare their "dependencies" on other package types to ensure checking them in reasonable order (ament before python before cmake). See ddc52bc

[wjwwood]

I should ideally be able to build an ament_cmake package without a package.xml, since CMakeLists provides all the necessary information for building and installing the package.

It does sometimes. However, it's perfectly possible that you can implicitly depend on something that isn't called with find_package() in cmake. I think this approach would be pretty fragile since it would be pretty easy to accidentally write a CMakeLists.txt that it cannot parse correctly. Also it won't work with ament_cmake_auto which relies on the package.xml. So I think having a package without a package.xml should be the exception not the rule.

I'd also say -0 to spending time a feature like this unless we have an immediate need for it. It's good to think about how we can do it and even prototype it, I just don't think we should spend a lot of effort improving ament_tools. It would be better to unify the build tools first so that catkin_tools could benefit from it as well, because as far as I can tell nothing about this approach wouldn't work for catkin workspaces as well.

[dirk-thomas]

The immediate use case is building the eProsima packages which don't have any manifest file but only a CMakeLists.txt. For those the current approach works ok: http://ci.ros2.org/job/ros2_batch_ci_linux/329/

I don't think we should skip doing any improvements for ament_tools because of the potential unification with catkin_tools. We have talked about that for a while and haven't found time to do anything about it. Therefore it should not stop us from improving ament_tools where useful / necessary.

[wjwwood]

Like I said if we have a use case that's fine (it was not mentioned in the description of the pr), though I'd say this is still only a "nice to have", as we could have just dropped package.xml's in during the build. But for things like making the build parallel, I think reconciling the tools before spending a lot of effort on ament_tools is the best strategy long term.