5 ms·
> 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 softwa
by protomikron 8y ago
> 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`?
- oarfish 8y agoIt's not even really supported outside specific Ubuntu releases I think, so for anything else you're on your own mostly.
- ragebol 8y agoI 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.
- dimatura 8y agoCMake 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.
- takluyver 8y agoThe 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.
- xaedes 8y agoYou 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.
- wjwwood 8y agoIt'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 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.
- rmattes 8y agoROS runs on Mac, and ROS 2 adds Windows support.
- akoumis 8y agoHaving 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
- jschwartzi 8y agoThe 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.
- akoumis 8y agoMy 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.