Hacker News Reader

Comment by protomikron | Hacker News Reader

> The build system is mostly macros on top of cmake.

That makes it even worse. So it's crap on top of crap. CMake is mostly used to build cross-platform software, but I don't think anybody uses ROS on a system other than Linux, so why not just use established tools like simple `make`?

View on HN

Having written plenty of makefiles and cmakelists I would much rather write the latter for a CPP project. The idioms are easier to remember so I don’t have to search through SO to do little things. Let’s say I want to include a version of OpenCV of at least version 3.0, this is a super simple cmake command, make equivalent is probably not standardized and is some some strange syntax I will have to include in every makefile where I need the same functionality

The Make equivalent is just the set of commands you would use to generate OpenCV plus a target and dependencies. If you can shell script you can write a Makefile.

My point is that "find_package(OpenCV 3.0 REQUIRED)" is a whole lot simpler to remember than whatever the equivalent shell commands are to enforce the minimum version of a library. What you are suggesting is to build the exact version for use with this specific project, different from "Developer I checked your environment and your version is too low". I'm just speaking from my experience, if you are very experienced with shell and can reproduce this type of behavior more quickly then more power to you. This is a similar debate to "why rewrite standard libraries in every project", for example, to count items in a list in python I can loop through and modify counts in a dict or I can use "collections.Counter(list_)" and it does it for me. Cmake provides ample standardized methods for C++ builds that I don't have to rewrite over and over again for every project.

I think CMake is quite established. I don't like these kind of holy wars (I like vim too :-)) but to get stuff done. ROS lets me do that.

I've seen several times that companies write their message passing stuff on top of ZeroMQ, mttq and what-have-you, while they could have spent all that time doing something novel as well. At the cost of using less than perfect tools made by someone else that a lot of people are also using.

It's not even really supported outside specific Ubuntu releases I think, so for anything else you're on your own mostly.

CMake is pretty established. You don't have to use CMake and if you don't want to, you don't have to use it - you can just compile your code however you like and manually put all your package files where ROS expects them to be, or use symlinks or some other hack. Doesn't seem to be worth it just to avoid CMake.

The build system is effectively almost required, though, because the documentation telling you how to do anything in ROS assumes you're using Catkin. I wouldn't know how to arrange files for ROS to use without going through the build system.

You actually can just cmake and that is all you need!

  [in any folder out of source]
  mkdir build
  cd build
  cmake [source folder]
  make
  source devel/setup.bash
  roslaunch your_fancy_package demonstrator_nodelet_or_whatever.launch

That works, but you can't mix it with catkin_make or other build tools (rosbuild). I.e. you can't just invoke catkin_make there, this won't work afaik.

The source folder must contain a main CMakeLists.txt symlink which points to `/opt/ros/[distribution e.g. kinetic]/share/catkin/cmake/toplevel.cmake`. This symlink will be created when calling "catkin_init_workspace". You can also just put a copy of that file there to commit it in git. I do this and even modify it to include my own cmake modules and debugging stuff.

You can now layout your folders any way you want. That means the packages don't need to all be in the same folder, but can be grouped as necessary.

Example project layout:

  project
  ├── cmake
  |   └── FindSomePackage.cmake
  ├── doc
  |   └── index.md
  ├── project_msgs
  |   ├── msg
  |   |   ├── Foo.msg
  |   |   └── Bar.msg
  |   ├── CMakeLists.txt
  |   └── package.xml
  ├── project_utils
  |   ├── include
  |   |   └── project_utils
  |   |       └── foo.h
  |   ├── launch
  |   |   └── ...
  |   ├── scripts
  |   |   └── do_stuff.py
  |   ├── src
  |   |   └── foo.cpp
  |   ├── CMakeLists.txt
  |   └── package.xml
  ├── components
  |   ├── heisenberg_compensator
  |   |   ├── include
  |   |   |   └── ...
  |   |   ├── src
  |   |   |   └── ...
  |   |   ├── CMakeLists.txt
  |   |   └── package.xml
  |   ├── warp_controller
  |   |   ├── include
  |   |   |   └── ...
  |   |   ├── src
  |   |   |   └── ...
  |   |   ├── CMakeLists.txt
  |   |   └── package.xml
  |   ├── ...
  |
  ├── .gitignore
  ├── readme.md
  └── CMakeLists.txt -> /opt/ros/[distribution e.g. kinetic]/share/catkin/cmake/toplevel.cmake
        should contain set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} ${CMAKE_CURRENT_SOURCE_DIR}/cmake)

You can put software components/packages in folders that are structured similar to project_utils / project_msg on any sublevel, I don't know what happens when you directly nest them though.. I wouldn't do that.

It's not required if you know CMake and know what you're doing. There's even resources, if you search for them, e.g.:

https://github.com/gerkey/ros1_external_use

But if you're looking for good documentation and tutorials, then yes catkin is basically required, but I don't think that's unreasonable.

ROS runs on Mac, and ROS 2 adds Windows support.

Reply on news.ycombinator.com