Timeline for catkin_simple release?

[Mike Purvis]

Seems to be quite stable and usable:

https://github.com/catkin/catkin_simple

Are there any major blockers on releasing Hydro and Groovy debs for it?

Mike

[William Woodall]

Sorry Mike,

I am traveling, so a little unresponsive.

There is no established timeline at this time. My hope was that we would take it 80% of the way by implementing it and that people who were asking for it would take it the rest of the way. What's left to do, in my opinion:

- Automatically handle Actions, similar to how Messages and Services are currently automatically processed

- Perhaps some sort of better support for Dynamic Reconfigure, might not be needed

- Refactor the code into separate files and document each of the functions in more detail

- Write documentation on the wiki

- Consider changing the name

- Testing

I think the name is bad, it really is something more like "rosbuild", but that's confusing because it already exists, perhaps something like "ros_catkin" or "catkin_ros". The latter names are commonly used to imply "ROS/thing integration", so this implies to me "better ROS/catkin integration". I'm somewhat dispassionate about the name, but I think "catkin_simple" isn't great.

Testing, we recently used catkin_simple in a non-ROS project and it worked pretty well, but we found a bug here and there, which we back ported most fixes (some are still waiting on me to have free time to properly merge upstream). I am confident that there are probably other bugs still in there. It is important to note that this project was not at all concerned about releasing/distributing code and just wanted to minimize CMake code and streamline the development environment, so catkin_simple worked well. I think that catkin_simple does not work well once you want to start distributing code efficiently and correctly, but that should be the trade-off which is made obvious to end-users.

I think the biggest road block is that the current maintainers (dirk and I), have no free time to tackle this. I'm glad to help were possible, but I only have so much bandwidth.

--

--
You received this message because you are subscribed to the Google Groups "ROS Buildsystem Special Interest Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-buildsy...@googlegroups.com.
To post to this group, send email to ros-sig-b...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ros-sig-buildsystem/CACsJT9PB1ULNAsvtvt5xbt5mknsi2MLyqU6vVrXLPMYXYnFEEw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
William Woodall

ROS Development Team

wil...@osrfoundation.org

http://williamjwoodall.com/

[Mike Purvis]

I think the name is bad, it really is something more like "rosbuild", but that's confusing because it already exists, perhaps something like "ros_catkin" or "catkin_ros". The latter names are commonly used to imply "ROS/thing integration", so this implies to me "better ROS/catkin integration". I'm somewhat dispassionate about the name, but I think "catkin_simple" isn't great.

Some other possibilities:

catkin_helper

catkin_helpers

catkin_ros_macros

catkin_ros_helpers

catkin_package_helpers

With the name catkin_ros_helpers, the macros could then be prefixed with catkin_ros, eg:

catkin_ros_init()

catkin_ros_library()

catkin_ros_executable()

catkin_ros_install()

catkin_ros_done()

I don't think the explicit target_link_libraries should necessary—any libraries created in a package should be linked against any executables, as part of the footer/finish/done/export macro.

I think that catkin_simple does not work well once you want to start distributing code efficiently and correctly, but that should be the trade-off which is made obvious to end-users.

It seems like it'd be a great fit for non-library packages, like messages, hardware drivers, etc. That was part of the reason to have asked—a file like this CMakeLists.txt from grizzly_motion seems to be a pretty clear place where the catkin_simple macros would serve well to make things less silly.

Mike

[Jonathan Bohren]

On Tue, Nov 26, 2013 at 6:54 PM, William Woodall <wil...@osrfoundation.org> wrote:

I think the name is bad, it really is something more like "rosbuild", but that's confusing because it already exists, perhaps something like "ros_catkin" or "catkin_ros". The latter names are commonly used to imply "ROS/thing integration", so this implies to me "better ROS/catkin integration". I'm somewhat dispassionate about the name, but I think "catkin_simple" isn't great.

What about "autocatkin"?

--
Jonathan Bohren
Laboratory for Computational Sensing and Robotics
http://dscl.lcsr.jhu.edu/People/JonathanBohren

[Jack O'Quin]

On Fri, Dec 6, 2013 at 11:11 AM, Jonathan Bohren <jonatha...@gmail.com> wrote:

On Tue, Nov 26, 2013 at 6:54 PM, William Woodall <wil...@osrfoundation.org> wrote:

I think the name is bad, it really is something more like "rosbuild", but that's confusing because it already exists, perhaps something like "ros_catkin" or "catkin_ros". The latter names are commonly used to imply "ROS/thing integration", so this implies to me "better ROS/catkin integration". I'm somewhat dispassionate about the name, but I think "catkin_simple" isn't great.

What about "autocatkin"?

Without someone working on this, the name does not matter.

Whoever volunteers to maintain it gets to pick the name (with input suggestions of course). 

--
 joq