colcon extension for meson

[christianrauch]

I created a colcon extension for meson packages: https://github.com/christianrauch/colcon-meson and would like to have this moved inside the @colcon organisation for continued maintenance and releases to the Python Package Index.

This currently implements the bare minimum to identify, build and install meson packages.

To test it, build the libcamera and simple-cam packages.

# download colcon-meson and meson examples
mkdir -p ~/cam_ws/src
cd ~/cam_ws/src
git clone https://github.com/christianrauch/colcon-meson.git
git clone https://git.libcamera.org/libcamera/libcamera.git
git clone https://git.libcamera.org/libcamera/simple-cam.git
cd ~/cam_ws

# build colcon-meson
colcon build

# list packages
source install/setup.bash
colcon list
# should list:
#   colcon-meson	colcon-meson	(python)
#   libcamera	libcamera	(meson)
#   simple-cam	simple-cam	(meson)

# build 'libcamera' and 'simple-cam'
colcon build

# source workspace again and run the camera example
source install/setup.bash
qcam

@nuclearsandwich FYI. We had a quick chat about adding meson support a while ago. This should get this started.

[nuclearsandwich]

Thanks for the ping.

I've created a team within the colcon organization and added you to it. I'm not positive, but once you accept the invitation you should be able to transfer colcon-meson into the colcon org.

If not, let me know and I'll dig in further.

[christianrauch]

Thanks. This worked. The repo is now at https://github.com/colcon/colcon-meson.

Can you let me know what is required to integrate this into the colcon-common-extensions package and how to get it released on PyPI such that a pip install -U colcon-common-extensions will install it alongside the other colcon extensions?

[nuclearsandwich]

The technical requirements are surmountable and I'll start documenting them as a follow-up step, the biggest blocker will be getting you permissions to push to the colcon apt repository on packagecloud but that's an admin thing not something that needs your action on at the moment.

Really though, I think that the editorial / policy question of whether colcon-meson needs to be added to colcon-common-extensions and if it does, what would appropriate maturity expectations be?

There is not, to my knowledge, an explicit list of criteria but it's not meant to include every colcon extension, just the ones in common usage. Hence the name.

Below is a personal list of criteria that I'll formalize with other maintainers as a PR in the coming days. I should also make it clear that I don't actually think that proposed criteria would represent minimum expectations. Not every package which meets every requirement would necessarily be added and I'm sure that we'll run into situations with current packages and future ones that prove exceptions to whatever criteria are proposed and accepted but having some to set expectations (and to force us to think about them a little) is still going to be beneficial.

Ultimately, decisions about which packages are included in colcon-common-extensions will be made by the active maintainers, of which I am but a single member.

• Packages added should only be added if considered necessary for a baseline colcon installation. Phrased another way: A package should only be considered for addition if most colcon users would consider a colcon installation incomplete without that package.
• Adding a package to colcon-common-extensions must not break ROS 2 CI builds or Ignition CI as ROS 2 and the ROS and Gazebo community represent a significant portion of colcon's users.
• Packages added should depend on a minimal number of modules outside the standard library and justify the usage of any package which provides features available using the standard library.

[christianrauch]

I see. I guess adding this to the common extensions is actually not required at this time.

However, it would be very convenient to have this package released to some extent, so that other (meson) packages can depend on it as build tool via something like

  <export>
    <build_type>meson</build_type>
  </export>

and it will then download colcon-meson (as dep or pip) via rosdep.

[jacobperron]

I agree with your points regarding adding packages to colcon-common-extensions, @nuclearsandwich.

Regarding releasing colon-meson for convenience, could you not just release colcon-meson to PyPI (like any other Python package)? Then users can install it via pip. E.g. I did exactly that with colcon-gradle.

Then, you could add a rosdep pip rule colcon-meson, I suppose 🤷

[christianrauch]

Ok, I see now that all the colcon packages on PyPI are maintained by individual people and not an organisation. I was somehow under the impression that all of colcon would be released by the @colcon organisation, e.g. to sync API changes. In this case, I will just look into releasing this to PyPI myself.

May I also ask, how to add a rosdep rule for colcon extensions? Searching for colcon in all of rosdistro, I can only find a reference to python3-colcon-common-extensions, which would install colcon-cmake. However, I don't see how this is resolved by the <build_type>cmake</build_type>.

How do I have to format rosdep/python.yaml such that a <build_type>meson</build_type> (or <buildtool_depend>meson</buildtool_depend> ?) will install colcon-meson (and not only meson) via pip?

[jacobperron]

Releasing to PyPI yourself (as the maintainer) makes sense to me.

I don't think rosdep is typically used to install colcon packages. Someone can correct me if I'm wrong, but I don't think we rely on colcon on the ROS buildfarm (though this may change in the future). colcon is mainly used as a convenient tool for developers. So, I don't think it makes sense to have rosdep install colcon-meson for the a declaration like <build_type>meson</build_type>. It makes more sense to me to be explicit about depending on colcon-meson with something like <buildtool_depend>colcon-meson-pip</buildtool_depend> where colcon-meson-pip is a rosdep rule pointing to the released pip package. But this might be controversial, I'm interested in what others think.

[christianrauch]

Sorry for going a bit off-topic here, but I want to make sure that the colcon extension is set up properly to build (pure) meson packages.

If the build tool is determined by <buildtool_depend>, what is <build_type> used for?

As far as I can tell, a colcon extension scans every package for matching build definitions. E.g. colcon-cmake searches for CMakeLists.txt and colcon-meson searches for meson.build. If installing the colcon extension via buildtool_depend is sufficient for building the package, then specifying build_type is redundant.

[tfoote]

The build_type is an explicit way to set the build type in the package.xml avoiding the requirement of scanning the code for various marker files. This is not necessary if you're actively building with colcon (It even works without a package.xml at all if you've setup your workspace right) and have the necessary tools preinstalled. But for other tools like bloom the build tools aren't necessarily available when scanning to be able to detect and report their marker files. This avoids a dependency on the build tools to detect what the build type is for things like packaging and indexing.

[christianrauch]

The initial version has been released on PyPI: https://pypi.org/project/colcon-meson/

As expected, you can install it now via:

pip install colcon-meson

Since we do not need to release this as part of colcon-common-extensions, I am going to close this issue. If there are issues releasing a Debian package version of it, just open an issue in the colcon-meson repo.