1
$\begingroup$

Rosanswers logo

During our recent work on the ROS Visual Studio Code plugin (https://github.com/ajshort/vscode-ros, we're still working on a fork), we have noticed that the plugin is assuming the workspace to have been built with catkin_make instead of catkin_make_isolated since devel is being searched instead of devel_isolated.

Is there a preferred choice between catkin_make and catkin_make_isolated?

The only official documentation does not seem to imply any preference and it seems quite a few people are still using catkin_make over catkin_make_isolated. Some differences I have noticed:

  • catkin_make_isolated generates a .catkin_workspace file while catkin_make does not
  • catkin_make_isolated has --install enabled by default
  • catkin_make_isolated allows building non-catkin packages? (not sure if there is any actual example of this)

Thanks!

Originally posted by kejxu on ROS Answers with karma: 71 on 2019-04-08

Post score: 7

Improve this question
$\endgroup$

2 Answers 2

Reset to default
2
$\begingroup$

Rosanswers logo

For a "normal" developer I would describe the options like this:

  • catkin_make was the first script around to build catkin workspace and is therefore used in many tutorials. It has several down sides (requiring non-standard logic in packages to declared cross-package target dependencies) and limitation (can't process plain CMake packages, requires all targets across all packages in a workspace to be unique). Therefore I wouldn't recommend to use it.
  • catkin_make_isolated is the script which was developed next which addresses all these shortcomings. It comes at the cost of being slower since it processes all packages sequentially. It is being used on build.ros.org in the devel and PR jobs. I would recommend using this if you want the most reliable solution (exclusively for ROS 1).
  • catkin_tools (called catkin build above) is similar to catkin_make_isolated but addresses the performance limitation by processing packages in parallel where possible. It also has a lot of usability features which makes it much easier to use and configure. On the downside this tool is not being actively maintained for the past years so I wouldn't recommend it either.
  • colcon is the new build tool developed for ROS 2 and works similar to catkin_tools with less usability features at the moment but being able to build any kind of packages (catkin, ament, CMake, Python setuptools, gradle, bazel, cargo, ...) on all major platforms (Linux, macOS, Windows). While developed for ROS 2 it in principle also works for ROS 1. If you are willing to use something more bleeding edge (which might come with quirks which haven't been resolved / polished yet) this might be an option. The big advantage is that the tool is very modular and actively developed and extended by multiple parties.

Since you are writing an extension for VSCode I would argue that colcon would be the best option - why?

  • It is the only tool actively being maintained. And if you want to contribute your patches will likely be reviewed, merged and released in a timely manner.
  • It is highly module and configurable which will allow you to provide various options difficult to implement with the other tools.
  • Your extension would support ROS 1 as well as ROS 2.

Originally posted by Dirk Thomas with karma: 16276 on 2019-04-09

This answer was NOT ACCEPTED on the original site

Post score: 17

Original comments

Comment by kejxu on 2019-04-09:
very informative, good to know! I would need to take a look at colcon first in this case, thanks =)

Comment by boxer911 on 2020-02-26:
When you use 'catkin_make_isolated' should you continue you doing so from that point? Do you still build packages from source in src folder and cd back to catkin_ws then run 'catkin_make_isolated'?

Improve this answer
$\endgroup$
0
$\begingroup$

Rosanswers logo

I prefer catkin_make unless I'm in a workspace that requires catking_make_isolated (yes, because it can build plain-cmake packages).

  • catkin_make treats the entire workspace as a single cmake project, and builds it with a single invocation of cmake. Since catkin_make treats the entire workspace as a single package, it's faster for incremental builds that only change code, but slower when you need to regenerate the build files, and more sensitive to dependency issues between packages.
  • catkin_make_isolated treats each package as a separate cmake project, and builds and installs each separately, in dependency order. This is why it's able to build plain cmake packages.
  • The catkin tools project (catkin build) also treats each package as a separate cmake project and builds each one separately (I'm not sure if it does the install step or not). It's an evolution of catkin_make_isolated, but with more features and a more thoughtful design. catkin build isn't as sensitive to dependency issues as catkin_make, so it's become quite popular in the past few years. I think it's about as fast as catkin_make but I don't use it enough to compare.

I'm not sure how all of those will mesh with VSCode, but hopefully that gives your a better idea of what they're doing and why.

Originally posted by ahendrix with karma: 47576 on 2019-04-08

This answer was NOT ACCEPTED on the original site

Post score: 3

Original comments

Comment by kejxu on 2019-04-08:
Thanks Austin! As of today, our plan for integration would only go as far as using VSCode just like a normal command prompt.

I have recently just started working a bit with catkin_make, and have never heard about/tried catkin build. Thanks for pointing those out, I will go take a look =)

Comment by gvdhoorn on 2019-04-09:
@ahendrix wrote:

catkin build isn't as sensitive to dependency issues as catkin_make

interesting observation. I would actually think it'd be the opposite (because catkin_make coalesces all projects into one big one, it works with slightly incorrect CMakeLists.txt, whereas those will fail with catkin_tools).

Improve this answer
$\endgroup$