ROS only simpler

[dirk-thomas]

@Eric_Schumann

That project already has its own build environment, and porting that entire project to use colcon would be prohibitive at best, and would most likely make the change a non-starter.

You mixing two completely separate parts of the process: the build system (CMake, Python setuptools, etc.) and the build tool (colcon) [see A universal build tool]:

• The build system is in charge of processing a single package. In the case of CMake that usually boils down to using it as cmake / make / make install. The fact that ROS packages use CMake helper functions provided by ament_cmake are actually not relevant for this since they are an implementation detail when you look at how to invoke the build system. You can achieve the same with plain CMake - it will just take you more lines of CMake code.
• The build tool colcon only determines in which order a set of packages needs to be built and what build system a package uses in order to decide how to build that package. colcon is very modular, if you want to use a build system which isn’t supported atm you can easily write an extension to teach colcon how to invoke that build system. E.g. CMake support is just an extension for colcon which implements the invocation logic mentioned above.

And as usually you can always mix-and-match: build some packages with colcon, then some manually (however you like), and then another set using colcon.

@Eric_Schumann

Due to the nature of cross compilation, it is almost always easier to have a standalone build system for the cross-compiled parts.

I don’t think this statement is true. When you want to cross compile any project which consists of more than a single monolithic piece you are facing the exact same challenges as for a native build. Therefore the benefits of a build tool apply just the same. Coincidentally just yesterday a tool to make cross compiling was announced here on which internally uses colcon for that very reason.

@actinium226

because the build system enforces this federated model

See my comment above which clarifies that the build system only has knowledge about a single package. So by definition can’t have anything to do with the federated model which means dealing with multiple packages.

And by design the build tool is optional to use. You are able to build all the packages of a ROS distribution just fine without a build tool. You “just” have to manually figure out in which order packages need to be build and how to build each individual package. So I hardly see where we enforce the build tool anywhere (except that doing that kind of work manually sounds like a huge amount of wasted time to me since it can be easily automated).

@actinium226

I think Python/pip could provide a good model for how to do ROS packages

I think this comparison isn’t actually applicable. Afaik there is no way in Python to build and install a set of packages where you have the source code in a local directory - and especially do that by honoring their inter-dependencies.