Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

The workflow you describe is common for autotools and only applies to build and install a single package.

ROS packages are using CMake and the standard workflow for CMake packages is:

cmake .
make
make install

Actually with CMake you should always do an out-of-source build but that is another topics.

But the additional steps in the ROS-from-source instruction perform additional steps which are not covered by a per-package build.

rosinstall_generator creates a list of repositories which you need to clone based on a set of packages you want to build. The information where these repositories are and what dependencies they need is specific to ROS. I don't think that this functionality is cover by any other tool (except apt-*). Usually you would collect this information manually by reading instructions.

wstool then clones all repositories. Again this is not something you usually do when building a single package. And for multiple packages you would clone them one-by-one by hand.

rosdep then makes sure that you install all dependencies. Commonly you would read the install instructions and then manually install the deps e.g. using apt-get install.

The last step you did not mention catkin_make_isolated then determines the topological order of all your source packages which it does based on the package dependencies declared in their manifests. Then it invokes the stand cmake / make / make install steps for each package.

As you can see each step has a very good reason and for most of them nothing similar exists as a standard. Most of this automation is provided because ROS makes it easy for you to build hundreds of packages at once. You could still perform every task manually as you might be used to from other projects but it would take you hours to clone, install deps, build and install a bigger workspace like ROS desktop. These commands provide the automation to perform it in minutes (excluding the compilation time).

The workflow you describe is common for autotools and only applies to build and install a single package.

ROS packages are using CMake and the standard workflow for CMake packages is:

cmake .
make
make install

Actually with CMake you should always do an out-of-source build but that is another topics.

But the additional steps in the ROS-from-source instruction perform additional steps which are not covered by a per-package build.

rosinstall_generator creates a list of repositories which you need to clone based on a set of packages you want to build. The information where these repositories are and what dependencies they need is specific to ROS. I don't think that this functionality is cover by any other tool (except apt-*). Usually you would collect this information manually by reading instructions.

wstool then clones all repositories. Again this is not something you usually do when building a single package. And for multiple packages you would clone them one-by-one by hand.

rosdep then makes sure that you install all dependencies. Commonly you would read the install instructions and then manually install the deps e.g. using apt-get install.

The last step you did not mention catkin_make_isolated then determines the topological order of all your source packages which it does based on the package dependencies declared in their manifests. Then it invokes the stand cmake / make / make install steps for each package.

As you can see each step has a very good reason and for most of them nothing similar exists as a standard. Most of this automation is provided because ROS makes it easy for you to build hundreds of packages at once. You could still perform every task manually as you might be used to from other projects but it would take you hours to clone, install deps, build and install a bigger workspace like ROS desktop. These commands provide the automation to perform it in minutes (excluding the compilation time).

Update:

As every Linux distribution ROS has to choose a specific version of every package. For ROS Indigo that is Gazebo 2 - simply because nothing else was available when ROS Indigo was released almost a year ago.

rosdep makes the common task to install the default dependencies easy. Therefore it tries to pull in Gazebo 2. But it is perfectly valid for you to not use Gazebo 2 but Gazebo 5 instead. Most packages in ROS will compile fine against the newer version as well. Just use for similar question on this platform to find user doing exactly that.

The same for your embedded setup. You can install any Gazebo version from the source you want, e.g. build a custom version from source if you like. And then build the ROS packages on-top. If some packages don't work well with different versions of their dependencies (which is sometimes the case) the maintainers are usually happy to take contributions to make it more flexible.

All the scripts and packages you refer to are documentation in the ros wiki. The wiki pages also point to their repositories on GitHub where you will find all the source code. Since most of the tools are Python you could actually read all of the sources on your local machine already.