I'm surprised that nobody has stated simply that catkin allows us to have our packages build on Windows and Mac OSX, with the obvious advantage of getting way more users/developers. Remember that rosmake/rosbuild has a lot of UNIX specific hacks (bash scripts, make, symlink ...). Regards, Vincent On Wed, Jul 25, 2012 at 7:56 AM, Daniel Stonier wrote: > > Interesting thread! > > I just browsed through its entirety. There seems to be a fair bit of > anxiety around catkin. I've been using catkin (formerly rosbuild2) for over > a year now - for cross compiling with arm compilers and development with > window's msvc. It's definitely a sea change in the way we build things in > RoS, but I believe the potential for doing things with catkin is enormous. > It really does free us from alot of constraints. > > With regards to what we've come to value from the old system... > > I think rather than trying to hang on to what was there, a better way to > approach the problem is to identify what we valued and proceed to work out > how to retain that value in catkin. Catkin can handle most (all?) of the > issues discussed above and for some issues there are several ways to do it. > To actually envisage how without a really good understanding of how the > cmake-python brew works is difficult. Let's throw in the items we feel are > important from the old build system, and let the catkin devs explain in > more detail or find a way to make things happen. > > Re the stack/package differences. I can understand where Dirk is coming > from. Mechanically, the idea of a package is starting to become entirely > redundant within the build system. Package based namespacing - it would be > very easy to informally construct the same level of namespacing yourself, > or write some catkin logic to enforce some structure formally. > For dependencies - actually cmake does a far more efficient job of > chaining compiles via tracking of individual targets. It will only compile > that which you need and no more. Packages will tend to do alot more than > what you actually need. For non-code packages, I'm already finding ways to > do things the catkin way, yet achieve the same purpose. I could go on...but > the point is there - is the last vestige of the ros package just a human > concept? > > Negatives about catkin...the only one that I can think of is that people > will have to know more cmake than they had to previously. Which doesn't > actually bother me greatly ;) > > Daniel. > > On 25 July 2012 20:18, Lorenz Mösenlechner wrote: > >> On Wed, Jul 25, 2012 at 1:00 PM, Jack O'Quin >> wrote: >> > On Wed, Jul 25, 2012 at 4:03 AM, Lorenz Mösenlechner < >> moesenle@in.tum.de> wrote: >> >> 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. >> > >> > Those packages will have to be converted, too, because the launch >> > scripts will need to be installed somewhere. In that sense, XML files >> > *are* code. >> >> That is true. But it's not about installing launch files but about >> managing dependencies and building everything that is necessary. >> >> At the moment, I guess most people have a lot of packages in a >> repository, not necessarily organized in stacks and possibly with some >> packages being broken. In particular, some of the packages are there >> only for specifying dependencies that are required to run something, >> e.g. for bringing up the robot. With rosmake, getting everything built >> that is required for running the robot is easy. With catkin, I would >> either need to build everything in that repo which might not work due >> to broken packages or I would need to create something like a build >> workspace that symlinks only the packages I want to build. Both >> solutions would require some manual work. >> >> I think one reason for the great success of ros was that it made it >> really easy to use other people's code and get the dependencies >> resolved with just one call to rosmake. With catkin, the user needs to >> be more organized and building something just requires more knowledge >> and more work. >> >> Lorenz >> >> >> >> -- >> 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 >> _______________________________________________ >> ros-users mailing list >> ros-users@code.ros.org >> https://code.ros.org/mailman/listinfo/ros-users >> > > > > -- > Phone : +82-10-5400-3296 (010-5400-3296) > Home: http://snorriheim.dnsdojo.com/ > Yujin R&D: http://rnd.yujinrobot.com/ > > > > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users > >