mikeliner.blogg.se - Cmake vs waf

#Cmake vs waf software#
#Cmake vs waf code#
#Cmake vs waf windows#

High-efficiency: template-based C++ provides a way to write algorithms in a very abstract way with zero or almost zero overhead (abstraction without the cost!).

#Cmake vs waf code#

Sferes2): we want to focus on the ‘real code’, and avoid writing interface code as much as possible

Easy interface with high-performance libraries (Intel MKL, multi-core parallelization, MPI, etc.), with hardware (robots, ROS, etc.), and with our existing code (e.g.

We have specific needs that mainly revolve around high-performance, minimzing boilerplate code, and easy interface with hardware and existing libraries: For instance, Pebble, the smart watches, or Samba, the Windows-compatible file sharing system for Unix. Last, a few high profile projects chose waf. In robotics, ROS heavily relies on Cmake, but one could wonder if Catkin would have been faster/nicer/better if it had been based on waf or scons.

Also, keep in mind that QT needs a build system that works very well on MS Windows, while we do not care (we have no Windows-based clusters and no Windows-based robots…).

For instance, I remember that no build system was perfect for QT and someone even made a waf-based version of QT.

#Cmake vs waf software#

Overall, it seems that cmake won the “war” in the free software world, mainly because a few high-profile projects chose it instead of Scons or Waf – the most prominent (and “contagious”) project is most probably QT. See Using Limbo as an environment for scientific experiments. More importantly, using python also allows us to easily add services that is not typically part of a build system, for instance, to submit jobs to a cluster (we have to parse a JSON file, etc., which is trivial in python, but not in Cmake!). It is based on Python, it has a nice modern feel, it is fast, and it parallelizes the builds by default. Waf has all the advantages of Scons but the learning curve was less steep. In addition, Scons does not generate makefiles, which makes it faster and more adapted to parallel builds. It makes it easy to build complex build frameworks, but simple things can be not-that-simple to do (at least, in 2007, it probably improved since then). Scons is nice because it is based on Python, a nice, general purpose language that almost everybody know.

an ARM-based Raspberry Pi or a robot) was very hard with the first versions of Cmake (whereas it was easy with Autoconf / Automake!). On the contrary, cross-compiling for embedded platforms (e.g.

#Cmake vs waf windows#

Compiling on both Unix and MS Windows is easy, but Windows is not our target platform. Generating makefiles is nice, but (1) it is slow (because generating files is slow), (2) it is a 40 year old syntax (which does the job, OK), and (3) it is not designed for parallel build (whereas all our computers are now multi-core).

Waf, which was a bit like “a simpler scons”Ĭmake uses a custom language that is not especially well designed in our opinion (it looks like a language from the 70s and it ignores most of the research in computer languages of the last 30 years).

Scons, which can be seen as a set of high level python functions / objects to build software.

Cmake, which generates makefiles (like Autoconf / Automake), uses a custom language, and emphasizes Windows/Unix portability.

When we started Sferes2, around 2007, the free software community was starting to be tired of Automake/Autoconf (the de facto standard at that time) and it was looking for more modern alternatives. Short answer: because we used it in Sferes2 and we liked it!