Great work!

[kejxu]

Hi Sebastian,

Hope this finds you well! Not sure if this is the best way to reach out, but we have found this extension while looking into the catkin_tools commands lately. Just wanna say, great work =)

Earlier this year we have been working to port the VS Code extension for ROS to Windows, and now it is hosted in https://github.com/ms-iot/vscode-ros. This extension has a really simple wrapper for catkin build tasks, and personally I think the build experience is something we would try to improve on sooner or later.

Would love to know how you think of that extension, and also your road map for this extension =)

Stay in touch!

Best regards, James

[betwo]

Hi James,

thank you for getting in touch!

At the time of the creation of this extension, the ROS extension had no support for catkin_tools workspaces and other ROS functionality was not required for us. Instead of upstreaming the required changes, we opted for a standalone extension that focuses on the build functionality and no other ROS support.

On the road map for this extension I basically only see maintenance and bug fixing. At some point we would like to also support colcon and ament, but I would have created separate extensions for that to keep everything as modular as possible.

I'll take a look at your version of the ROS extension soon, maybe we can migrate some of our functionality there?

Cheers, Sebastian

[kejxu]

At the time of the creation of this extension, the ROS extension had no support for catkin_tools workspaces and other ROS functionality was not required for us.

Quick question: just curious, are the rest of the functionalities not required? or are they not wanted? Just asking because one of the things we have always tried to understand is how much should/should not be put into the extension.

On the road map for this extension I basically only see maintenance and bug fixing. I'll take a look at your version of the ROS extension soon, maybe we can migrate some of our functionality there?

That's perfect news! If this extension is already in stable state, then it would be much easier in terms of potential merging. Please definitely take your time, no hurry to take a look at the ROS extension =) We had only hoped that doing so would help boost visibility for the functionality provided by the components here!

At some point we would like to also support colcon and ament, but I would have created separate extensions for that to keep everything as modular as possible.

From what I've learnt, catkin being the build tool for ROS 1 would still maintain important for a while, and colcon would be the next major build tool for any future work (ament would be an underlying layer that ideally most users would not need to interact with)

also this goes back to the first question, just curious and trying to understand, is there certain rationale/philosophy for keeping these as separate extensions (instead of different modules inside 1 extension)?

[betwo]

Sorry for the delay, I was on vacation for the last weeks.

Quick question: just curious, are the rest of the functionalities not required? or are they not wanted?

In the beginning, there was only one feature that was actually not wanted, which was the hard coded clang-format rules of the ROS community, which made it impossible to use a custom .clang-format files.

I'm not sure if this is still the case, or if this can be disabled now, I'll look into that soon.

is there certain rationale/philosophy for keeping these as separate extensions (instead of different modules inside 1 extension)?

I guess this is mostly personal preference. I personally prefer modular systems with clean responsibilities, when I can imagine that different uses might only be interested in subsets of features.

Related to the issue with clang format above: I think that having a large set of orthogonal features in a single extension is fine, as long as individual features can be disabled.

However, I would personally prefer enabling/disabling individual extensions to disabling features in the config file. For example, I think the ROS extension could be split into

1. ROS core control and rosrun / roslaunch features
2. Language extension for .msg
3. Language extension for .urdf
4. Language extension for .xacro
5. Clang format configuration

And then having the ROS package be a "meta package" that installs all of those package.

However, I also see that this make the development process way more complicated.

Anyway, that was the original motivation for creating a separate extension instead of contributing to the origin ROS extension.