An example of a gnuradio project using cmake

Hey list,

I would like to share my experiences with CMake.

I started using CMake because I needed a cross-platform build system for
making UHD and I stumbled upon CMake. After learning CMake and building
UHD on-top of it, I can conclude that CMake is indeed awesome.


– OK, what is it?

CMake is a cross platform build system. In short, it translates a
description of your projects build rules and files and generates a
platform specific build system. This means that it not only generates
Makefiles (like autotools), but can also generate eclipse project files,
xcode projects, MSVC projects, and more.


– How does it compare to autotools?

  1. Project description:

In autotools there is there *.m4/Makefile.am/configure.ac/bash
dichotomy. With CMake, the project description goes into one type of
file, written in one scripting language. Now the language is CMake’s own
invention. I don’t know why they reinvented the wheel, but its dead
simple and very powerful.

This way, a projects configuration, sanity checks, library setup, target
setup, etc, can occur all in the same environment and only at the scope
or level that it needs to be introduced.

http://www.vtk.org/Wiki/CMake/Language_Syntax

  1. CMake is fast:

Ever watch the paint dry after changing something in an m4 file? With
CMake, it just knows what “going on”. Change something and type make,
and only the smallest delta to meet the dependencies will be affected.
In addition, there is only 1 level of generation (CMake just generates
the Makefiles).

  1. CMake makes packages:

It generates debs, rpms, windows exes, mac packages…
http://www.vtk.org/Wiki/CMake:CPackPackageGenerators

  1. Configuration gui:

You could enable components and set paths with command line switches,
but CMake has a gui for this as well (even one in ncurses). Suppose you
want to enable a component during configuration, its as simple as
checking a box.

http://www.google.com/images?hl=en&safe=off&q=cmake+gui&um=1&ie=UTF-8&source=og&sa=N&tab=wi&biw=1366&bih=518

  1. No convenience libraries:

I miss them, it would be convenient to have, but its more than possible
to do without them.

http://www.cmake.org/Wiki/CMake_FAQ#Does_CMake_support_.22convenience.22_libraries.3F


– Example of a stand-alone gnuradio project with CMake

I put together a CMake build system for a gnuradio project. So, I
CMake’d up gr-uhd in the style of how-to-write-a-block. It handles
library, headers, swig, grc, and some generation. The CMakeLists.txt
files are sitting along side the Makefile.ams on this branch:

http://gnuradio.org/cgit/jblum.git/diff/?h=cmake_example

The CMakeLists.txt may seem quite wordy, but keep in mind that most of
this business could be moved out into a set of cmake includes with
common configuration setup and macros/functions.

Compare gr-uhd/swig/CMakeLists.txt to gr-uhd/swig/Makefile.swig.gen +
Makefile.am and you will see what I mean.

Here is the verbose from the build process:


– Knocking on autotools:

I tried not to bash autotools too hard. But seriously, the gnuradio
gurus have put in a massive amount of effort to work around the
limitations of autotools. Maybe some share my sentiments.

KDE thought switching its build system to CMake was a good idea:

Going forward, when the gnuradio source gets the much needed
reorganization, I hope that the gurus will consider CMake for all the
reasons above.

Thanks,
-Josh

Hi Josh,
The original makers of CMake kitware initially built it
for the visualization tool kit library (VTK). Its pretty good at
generating cross platform build configurations, plus IDE based
configurations for Xcode, Visual Studio, etc.

Elvis D.

Josh,

First off, many thanks for share your experience with the list.

Studying the cmake a little, I found that it is remarkably simpler than
Autotools, at least for my
small projects.

However I would like to stress a point about the source packages.
The Autotools suite produces source packages from which every user can
compile the code without
having to install Autotools itself.
Essentially when one download the sources tarball, the configure script
needs only the shell to
produce the Makefile(s).

It seems to me that a cmake-generated source base instead would require
cmake to produce a suitable
Makefile and do the build.
Really, the cmake sources contains a quite large bootstrap script just
in case the system doesn’t
have a working cmake around.
Now, whilst this could be probably is a minor point on modern
distributions, because I hope cmake is
available as binary package, do you think that this could weaken the GR
build system ?

     *am*

It seems to me that a cmake-generated source base instead would require
cmake to produce a suitable Makefile and do the build.
Really, the cmake sources contains a quite large bootstrap script just
in case the system doesn’t have a working cmake around.
Now, whilst this could be probably is a minor point on modern
distributions, because I hope cmake is available as binary package, do
you think that this could weaken the GR build system ?

Well, really its just another dependency that can be easily installed
(apt, yum, mac ports, dmg, or even windows exe (if we ever get there)).
So I would never really need to worry about it.

But since you asked, I think that not making distribution tarballs
(regardless of the build system) in favor of tar.gz’ing the source tree
would actually make things robust.

  1. autotools manifests itself into the distribution tarball anyway, and
    this can be a source of build problems. I believe that we had an issue
    with an out of date ltmain.sh in a tarball that was causing build
    problems on newer machines.

http://www.mail-archive.com/[email protected]/msg24879.html

  1. A build from git source would be the same as a build from a release
    tarball (because we just tar.gz’d up the source tree itself). So in a
    sense, it provides a build uniformity.

The advantage with CMake here, is that it does not allow you to shoot
yourself in the foot in this particular way. :slight_smile:

-Josh

On 12/13/2010 01:51 AM, Josh B. wrote:

  1. A build from git source would be the same as a build from a release
    tarball (because we just tar.gz’d up the source tree itself). So in a
    sense, it provides a build uniformity.

This is a good point.
Ok, back to the books again, I will give it a try on some small project
:slight_smile:

*am*

know exactly how to handle it in autotools and we have the benefit of

Alright, I accept your challenge. Upon near completion of the rewrite I
will take on the burden of proof. -Josh

On Dec 13, 2010, at 7:33 PM, Tom R. wrote:

The biggest problem that I see with cmake is that the burden of proof
lies with cmake.

I’m 100% confident that CMake, or QMake for that matter (and, I’m sure,
BJam and other build tools), could handle the GNU Radio build system
robustly if someone were willing to put the time and effort into those
changes. All of these build systems are roughly equivalent in the way
they go about accomplishing their task – except, I think, in one
important way: GNU Autotools allows the user to insert shell script that
is directly executed during configure, while CMake and QMake build
scripts are entirely interpreted and hence rely upon the interpreter and
documentation of its behavior being correct. Someone please correct me
if I’m wrong. Yes, I know that “shell script” is interpreted, but here
I make the distinction between interpreted by the shell many of us use
on a daily basis for many tasks versus interpreted just for the purposes
of, and by, this particular build system – does that make sense?

Either way: Each build tool has benefits and drawbacks; none is perfect
for all projects. I’m quite sure that for GNU Radio, any build tool
will have to include local “hacks” (or “tricks” or whatever) to get the
various dependencies found and in-place. I’ve worked with all 3 build
systems enough to know that I like each in different ways, and that all
end up with difficult-to-read scripts with any project of reasonable
complexity in dependencies and building.

So, if Josh wants to go off and prove that CMake will do the trick, I
say the more power to him. If Tom wants to keep using GNU Autotools,
I’m good with that too. I have no desire to rewrite everything to use
QMake or BJam, but I could probably do so without too much difficulty.
Specifically for GNU Radio, I don’t see any one of these build tools
being “better” than any other in any significant way.

My US$0.02 worth, at most :wink: - MLD

On Sat, Dec 11, 2010 at 1:55 PM, Josh B. [email protected] wrote:


CMake is a cross platform build system. In short, it translates a
description of your projects build rules and files and generates a
platform specific build system. This means that it not only generates
Makefiles (like autotools), but can also generate eclipse project files,
xcode projects, MSVC projects, and more.


– How does it compare to autotools?

The biggest problem that I see with cmake is that the burden of proof
lies with cmake. We have years of building up the project
configuration in autotools and every problem we have come across has
been solvable and solved in this framework. While some/many of these
problems might have been solved faster with cmake, we do a lot of
strange stuff in many different parts of GNU Radio’s build system. We
would need proof that cmake can actually handle everything, and that
probably means redoing the entire build system with cmake. Honestly,
right now, I have more important things to do than work on this, even
as a part of the rebuild. In the rebuild that we hope to do soon, we
know exactly how to handle it in autotools and we have the benefit of
having the solutions to our build problems already solved.

It’s really not worth my time (or anyone else’s that I can think of)
to redo the entire build system at this point. The single outstanding
issue in the build system currently is working in Windows, and I don’t
think the problems there are things that cmake will automatically fix
for us.

I appreciate your thoughts, concerns, and ideas here. Hopefully, you
understand my concerns about moving to a new build system, though.

Thanks,
Tom

On Tue, Dec 14, 2010 at 4:50 AM, Michael D. [email protected]
wrote:

My US$0.02 worth, at most :wink: - MLD
We have adopted CMake over Autotools since long now, CMake is
available now on all modern distributions, it’s easier to learn and
some IDE (like Kdevelop) are even aware of the CMake syntax with
integrated help as well for each command.

My 0.02 Euro.