[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] cmake build

From: Martin Braun
Subject: Re: [Discuss-gnuradio] cmake build
Date: Fri, 26 Aug 2011 15:08:23 +0200
User-agent: Mutt/1.5.20 (2009-06-14)

> We are looking at possibly moving from autotools to cmake. In many
> ways, cmake looks like it will simply many of our build issues and
> actually solve others. Josh Blum has been doing outstanding work in
> converting the GNU Radio build system over to using cmake, and we
> really need testers to chip away at any of the bugs. Specifically, we
> have tested it on some modern OSes, but we want ot make sure that it
> covers most (if not all) of our customer base (I'm sorry, but if it
> come down to it, I'm willing to let the VAX users go...).
> Find the instructions to start working on it here:
> http://gnuradio.org/redmine/projects/gnuradio/wiki/CMakeWork
> Please post both positive and negative experiences so that we know not
> only what to fix, but it will also let us know what systems are
> working.

I've now found the time to also check out gr-howto-...-cmake. Here's
some comments:

1) Once again, the build process feels faster and cleaner.

2) One feature I miss is the build-variable 'modname'. Wouldn't such a
variable make things easier? I'm guessing for most people, gr-howto is
a template for out-of-tree modules, so most of the default settings
would be OK. In this case, a variable 'MODNAME' would possibly make
the CMakeLists.txt even simpler, and give the developer less options
(which he will never need). Example: the name 'howto' pops up very
often in CMake files. Imagine someone starts building a module, then
renames it during the process (say, from howto to how2). Most
developers would like all libraries, .so-files, modules etc. to be
renamed to e.g. gnuradio-how2.so etc. However, with the given
structure, a lot of manual renaming is necessary in CMakeLists.txt's.
(Of course, renaming files will have to be done by hand).

gr_modtool.py also uses this, by the way.

3) Suggestion: automatically set the test systems by use of GLOBs. I
guess if *all* lib/qa_*.cc and python/qa_*.py are automatically added to
the tests portfolio, this would be fine with most developers 99% of the
time. I still think the 1% are brilliant enough to adapt the build
system to their needs (instead of the other way round).

My couple of €-cents...

Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

Attachment: pgp1AV4yiNQ7C.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]