In addition, I don't think that it is possible to convert all ros packages to catkin. Catkin is all about building but what about the packages that don't contain code? There are a lot of packages out there that contain only launch files and dependencies to build everything that is necessary to start these launch files. The most prominent examples would be pr2_bringup or pr2_gazebo. I don't really see how that is possible in a catkinized world. Lorenz On Wed, Jul 25, 2012 at 7:31 AM, Jonathan Bohren wrote: > On Wed, Jul 25, 2012 at 6:07 AM, Jack O'Quin wrote: >> >> On Tue, Jul 24, 2012 at 7:01 PM, Dirk Thomas >> wrote: >> > On 24.07.2012 15:38, Jack O'Quin wrote: >> >> >> >> On Tue, Jul 24, 2012 at 5:15 PM, Dirk Thomas >> >> wrote: >> >> >> >>> For the dry world all artifacts are deployed under the package name. >> >>> In a wet-only world I would expect that all artifacts of a stack >> >>> should >> >>> reside under a folder named after the stack. >> >> >> >> Why do you want to change that? >> >> > It comes down to the question if the future catkin-only world will have >> > anything like a package (and manifest.xml files). >> > If argued yes: >> > - what is it used for? >> > - why is it needed (besides stacks)? >> >> In ROS, stacks are the unit of release and installation, very >> important in the build system. Packages are the unit of interface >> definition and inter-component dependencies. Moving a package from one >> ROS stack to another is trivially easy. Moving an interface to a >> different package affects *every* other program that depends on it. >> >> For example, ROS programs that depend on sensor_msgs/LaserScan do it like >> this: >> >> * #include >> * from sensor_msgs.msg import LaserScan >> >> Every launch script executes nodes relative to their containing >> packages. Messages frequently contain other messages defined by other >> packages. >> >> There are about 4000 ROS packages listed on the wiki under "Browse >> Software"; many more that are not indexed. Every one of them provides >> interfaces relative to the package name and depends on core ROS >> package interfaces. That includes the "wet" stacks and packages that >> have already been ported to catkin. >> >> Your proposal implies that every single program must be modified in >> Groovy to use common_msgs/LaserScan, instead. Surely that is not your >> intent. > > > Yeah, I'm really concerned about this too. I can understand re-writing build > files, but as is clear from the last long ros-users thread, the community as > a whole just doesn't have time for such a complete re-working of the ROS > dependency semantics of every single package. > >> >> > (Obviously my opinion is that packages a on-standard way - so for a >> > CMake >> > based buildsystem like catkin I would vote for not having a notion of >> > packages for wet-only) >> > >> > If no, shouldn't the deployment folder than be renamed to be the stack >> > name? >> > >> > Please think about how a catkin-only world should look like and reply >> > your >> > opinions - I am looking forward for any feedback! >> >> Catkin is not the world. The ROS repository federation is the world. >> Catkin is a build system. > > > Well put, Jack. > >> >> I was assuming the catkin conversion would only affect build files. >> You are proposing that every existing ROS source interface be changed. >> Who would do all that work? And, why? > > > I think the "why" is an important question. I understand Catkin calls CMake > only once. But if you ask me, the number of times CMake gets invoked is > really just about the lowest thing on my list of concerns when it comes to > developing robotics software. > > Additionally, I just noticed this on the catkin migration guide > (http://ros.org/doc/fuerte/api/catkin/html/rosbuild_migration.html): >> >> as a result: rosbuild implicitly adds compile and link flags based on >> package dependency information; catkin requires you to add them explicitly > > > I can't emphasize enough that I do not like the idea of this at all. One of > the things that I _love_ about the rosbuild-manifest system is that I don't > need to deal with compile and link flags of each dependency in the > CMakeLists.txt of a given package. What's wrong with the implicit flags > given by dependency info and the tags? > > -j > > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users > -- Lorenz Mösenlechner | moesenle@in.tum.de Technische Universität München | Karlstraße 45 80335 München | Germany http://ias.cs.tum.edu/ | Tel: +49 (89) 289-26910