And another thing…
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 B. 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.
Thanks!
Tom
On Thu, Aug 18, 2011 at 09:07:15PM -0400, Tom R. wrote:
And another thing…
[…]
Find the instructions to start working on it here:
http://gnuradio.org/redmine/projects/gnuradio/wiki/CMakeWork
Seems like the 'site is down again.
MB
–
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)
Dipl.-Ing. Martin B.
Research Associate
Kaiserstraße 12
Building 05.01
76131 Karlsruhe
Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu
KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association
On Thu, Aug 18, 2011 at 09:07:15PM -0400, Tom R. wrote:
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 like it!
…some more verbose comments:
-
All of my machines are pretty standard (all Ubuntu, 32 and 64 bit
flavours, versions 11.04 and 10.10). It works on both (with some minor
issues).
-
One of the machines had an old UHD version, which manages to crash the
build:
[ 88%] Building CXX object
gr-uhd/lib/CMakeFiles/gnuradio-uhd.dir/gr_uhd_usrp_source.cc.o
In file included from
/home/braun/src/gnuradio-cmake/gr-uhd/lib/gr_uhd_usrp_source.cc:22:
/home/braun/src/gnuradio-cmake/gr-uhd/include/gr_uhd_usrp_source.h:27:
fatal error: uhd/usrp/multi_usrp.hpp: No such file or directory
compilation terminated.
make[2]: ***
[gr-uhd/lib/CMakeFiles/gnuradio-uhd.dir/gr_uhd_usrp_source.cc.o] Error 1
make[1]: *** [gr-uhd/lib/CMakeFiles/gnuradio-uhd.dir/all] Error 2
I believe this should be caught by the configuration process, not
during the build (…?)
-
I didn’t time it, but is the build time much faster? Even if this is
only subjective, it’s an improvement.
-
The way the CMakeLists.txt look, this system seems much easier to
configure. Thumbs up! (Even though it’s actually longer 
-
One of the tests failed:
99% tests passed, 1 tests failed out of 83
Total Test time (real) = 71.21 sec
The following tests FAILED:
69 - qa_costas_loop_cc (Failed)
Errors while running CTest
make: *** [test] Error 8
- I noticed radar-mono and sounder are missing. If that was done on
purpose, then good riddance. While they’re interesting demos, they’re
not really useful and I always disabled them.
I hope this transition comes soon!
MB
–
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)
Dipl.-Ing. Martin B.
Research Associate
Kaiserstraße 12
Building 05.01
76131 Karlsruhe
Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu
KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association
Testing on OSX 10.6.8, XCode 3.2.3 (gcc 4.2.1 with Apple tweaks),
MacPorts 2.0.0 for all other dependencies. It looks like that
"configure’ and ‘build’ CMake logic is pretty good. I’d guess there’s
an issue with how ‘Python’ is called during the ‘test’ stage.
From the top-level git directory, after pulling Josh’s next branch and
switching to it:
% mkdir -p builds/cmake_next
% cd builds/cmake_next
% cmake …/…
[ succeeds, but finds Python 2.7 instead of 2.6;
“which python” -> python 2.6 installed by MacPorts ]
% make
[ fails at Volk, which is not a surprise ]
% cmake …/… -DPYTHON_EXECUTABLE=/opt/local/bin/python2.6
-DENABLE_VOLK=off
[ finds correct Python now;
succeeds, disables gr-qtgui, which is not a surprise ]
% make
[ succeeds ]
% make test
Running tests…
Test project /opt/GNURadio/git_new/builds/jb_next_cmake
Start 1: gruel-test
1/82 Test #1: gruel-test … Passed 3.02 sec
Start 2: qa_pmt
2/82 Test #2: qa_pmt …***Failed 1.26 sec
Start 3: gr-core-reed-solomon-test
3/82 Test #3: gr-core-reed-solomon-test … Passed 0.09 sec
Start 4: gr-core-test-all
4/82 Test #4: gr-core-test-all … Passed 11.53 sec
Start 5: qa_add_and_friends
5/82 Test #5: qa_add_and_friends …***Failed 0.45 sec
Start 6: qa_add_v_and_friends
[ all of the rest of the tests fail;
I get lots of pop-ups telling me that Python unexpectedly quit ]
5% tests passed, 78 tests failed out of 82
Total Test time (real) = 29.37 sec
[ 88%] Building CXX object
I believe this should be caught by the configuration process, not
during the build (…?)
Does uhd/usrp/multi_usrp.hpp actually exist on the machine? And did
gnuradio (current master) build w/ this version of uhd? There may have
been an issue w/ an older uhd.pc file.
- I didn’t time it, but is the build time much faster? Even if this is
only subjective, it’s an improvement.
Ive noticed this too. 
- The way the CMakeLists.txt look, this system seems much easier to
configure. Thumbs up! (Even though it’s actually longer
The cause of this may be that the job performed by makefile.swig.gen*,
runtests.in*, *.m4, *.am files is actually combined into the cmakelists.
Same functionality, less files.
This is a known issue w/ gr-digital. Tom has a fix in his digital branch
- I noticed radar-mono and sounder are missing. If that was done on
purpose, then good riddance. While they’re interesting demos, they’re
not really useful and I always disabled them.
I believe those components will be removed in the near future.
Thanks for testing!
-josh
5/82 Test #5: qa_add_and_friends …***Failed 0.45 sec
Start 6: qa_add_v_and_friends
[ all of the rest of the tests fail;
I get lots of pop-ups telling me that Python unexpectedly quit ]
5% tests passed, 78 tests failed out of 82
Total Test time (real) = 29.37 sec
OK, make sure that if this was checked out from an old repository that
you git cleaned -dfx to remove any old in-tree generated headers. That
could have caused some of the problems you are seeing.
Can you send me /Testing/Temporary/LastTest.log
Alternatively, you can usually run
/component/python/<name_of_test>.sh manually to get the
verbose.
-josh
On 08/19/2011 08:48 AM, Martin B. wrote:
been an issue w/ an older uhd.pc file.
Hm… sorry, I didn’t check. I cleaned out all UHD and re-installed,
after that the build worked like a charm.
It probably didn’t, but still, shouldn’t that be caught by cmake’s
configuration step?
Yes. It looks like I am not imposing a version check on uhd, which I
should be. So it probably accepted the older pc file.
-josh
On Fri, Aug 19, 2011 at 08:42:52AM -0700, Josh B. wrote:
[gr-uhd/lib/CMakeFiles/gnuradio-uhd.dir/gr_uhd_usrp_source.cc.o] Error 1
make[1]: *** [gr-uhd/lib/CMakeFiles/gnuradio-uhd.dir/all] Error 2
I believe this should be caught by the configuration process, not
during the build (…?)
Does uhd/usrp/multi_usrp.hpp actually exist on the machine? And did
gnuradio (current master) build w/ this version of uhd? There may have
been an issue w/ an older uhd.pc file.
Hm… sorry, I didn’t check. I cleaned out all UHD and re-installed,
after that the build worked like a charm.
It probably didn’t, but still, shouldn’t that be caught by cmake’s
configuration step?
- I noticed radar-mono and sounder are missing. If that was done on
purpose, then good riddance. While they’re interesting demos, they’re
not really useful and I always disabled them.
I believe those components will be removed in the near future.
Thank god. They should move to CGRAN, though.
MB
–
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)
Dipl.-Ing. Martin B.
Research Associate
Kaiserstraße 12
Building 05.01
76131 Karlsruhe
Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu
KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association
On Aug 19, 2011, at 11:24 AM, Josh B. wrote:
OK, make sure that if this was checked out from an old repository that
you git cleaned -dfx to remove any old in-tree generated headers. That
could have caused some of the problems you are seeing.
Can you send me /Testing/Temporary/LastTest.log
Alternatively, you can usually run
/component/python/<name_of_test>.sh manually to get the verbose.
This was a fresh checkout, and all I had tried to do was build Volk
(which failed) – so I don’t think cleaning will help. I checked out he
LastTest.log file, and here’s an example (all of the errors are like
this one):
Command: “/bin/sh”
“/opt/GNURadio/git/builds/cmake_next/gnuradio-core/src/python/gnuradio/gr/qa_agc_test.sh”
Directory:
/opt/GNURadio/git/builds/cmake_next/gnuradio-core/src/python/gnuradio/gr
“qa_agc” start time: Aug 19 09:41 EDT
Output:
Fatal Python error: PyThreadState_Get: no current thread
/opt/GNURadio/git_new/builds/jb_next_cmake/gnuradio-core/src/python/gnuradio/gr/qa_agc_test.sh:
line 8: 3157 Abort trap /opt/local/bin/python2.6
/opt/GNURadio/git_new/gnuradio-core/src/python/gnuradio/gr/qa_agc.py
Test time = 0.09 sec
Command: “/bin/sh”
“/opt/GNURadio/git/builds/cmake_next/gnuradio-core/src/python/gnuradio/gr/qa_agc_test.sh”
Directory:
/opt/GNURadio/git/builds/cmake_next/gnuradio-core/src/python/gnuradio/gr
“qa_agc” start time: Aug 19 09:41 EDT
Output:
Fatal Python error: PyThreadState_Get: no current thread
/opt/GNURadio/git_new/builds/jb_next_cmake/gnuradio-core/src/python/gnuradio/gr/qa_agc_test.sh:
line 8: 3157 Abort trap /opt/local/bin/python2.6
/opt/GNURadio/git_new/gnuradio-core/src/python/gnuradio/gr/qa_agc.py
Thats a very strange error. I have tested this on my macmini and havent
seen the same. Do you see errors when running the tests under autotools
on the next branch?
Take a look at
/opt/GNURadio/git/builds/cmake_next/gnuradio-core/src/python/gnuradio/gr/qa_agc_test.sh
and see if any environment variables are suspicious.
-josh
On Aug 19, 2011, at 3:27 PM, Josh B. wrote:
on the next branch?
No, the autotools variation does fine once you fix the errors in
“gruel/src/include/gruel/Makefile.am” (seems like an extra “<<<<<<<
HEAD” got in there) – I mean, it still errors out doing the socket
test, but otherwise the Python tests run OK (and pass).
Take a look at
/opt/GNURadio/git/builds/cmake_next/gnuradio-core/src/python/gnuradio/gr/qa_agc_test.sh
and see if any environment variables are suspicious.
Hmmm … those look OK overall. If I have time, I’ll look at this over
the weekend – or, maybe you’ll figure it out before then - MLD
The DYLD_LIBRARY_PATH is not being set in the shell script when using
CMake. It is being set when using autotools (in the run_tests.sh file).
Maybe this makes a difference? - MLD
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:
-
Once again, the build process feels faster and cleaner.
-
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.
- 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…
MB
–
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)
Dipl.-Ing. Martin B.
Research Associate
Kaiserstraße 12
Building 05.01
76131 Karlsruhe
Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu
KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association
- 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).
So here is an example of globbing w/ gr-digital:
http://gnuradio.org/cgit/jblum.git/tree/gr-digital/python/CMakeLists.txt?h=next#n54
And here is the “manual” way of doing it in gr-howto
http://gnuradio.org/cgit/jblum.git/tree/gr-howto-write-a-block-cmake/python/CMakeLists.txt?h=next#n37
My thoughts where that the gr-howto is to help learn by example, and
that the code would be easier to understand the “manual” way.
Thoughts?
-josh
On Fri, Aug 26, 2011 at 10:12:16AM -0700, Josh B. wrote:
And here is the “manual” way of doing it in gr-howto
http://gnuradio.org/cgit/jblum.git/tree/gr-howto-write-a-block-cmake/python/CMakeLists.txt?h=next#n37
My thoughts where that the gr-howto is to help learn by example, and
that the code would be easier to understand the “manual” way.
Thoughts?
A compromise might be to put more comments and annotations into the
CMakeLists.txt, e.g. to explain how things would be done manually.
With globs, there is less understanding of the build systems, but
getting started is also easier–it would make the learning curve nicer
for newbies.
MB
–
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)
Dipl.-Ing. Martin B.
Research Associate
Kaiserstraße 12
Building 05.01
76131 Karlsruhe
Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu
KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association
Just tested the cmake install on OS X 10.5.8, XCode 3.1.4, Homebrew
for dependencies. Homebrew is not quite up to scratch for the
dependencies since it’s missing pyqwk and pygtk, and qt is there but
the install script failed for me. Anyway there’s enough working for
gnuradio-core to install but not gnuradio-companion.
The problem I’m running into appears to be caused by the installed
version of python being 2.5. Cmake requests a version of 2.5 or later
so it should be okay, however I get the following error.
Serf:gnuradio-build ben$ make
[ 0%] Generating …/include/volk/volk.h, volk.c, volk_init.h,
…/include/volk/volk_typedefs.h, …/include/volk/volk_cpu.h,
volk_cpu.c, …/include/volk/volk_config_fixed.h,
volk_environment_init.c, volk_environment_init.h, volk_machines.h,
volk_machines.c, volk_machine_generic.c, volk_machine_sse2_only.c,
volk_machine_sse2_32.c, volk_machine_sse3_32.c,
volk_machine_ssse3_32.c
Unknown option: -B
usage:
/System/Library/Frameworks/Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/Python
[option] … [-c cmd | -m mod | file | -] [arg] …
Try `python -h’ for more information.
make[2]: *** [volk/include/volk/volk.h] Error 2
make[1]: *** [volk/lib/CMakeFiles/volk.dir/all] Error 2
make: *** [all] Error 2
A google suggests that the -B option for python was added in 2.6.
I’ll install a newer version of python and see if I have more luck.
Cheers,
Ben
Hi Ben - I believe that Volk (in general, not just the Python version)
doesn’t play nicely with OSX (any version) yet. Use --disable-volk on
the configure command line to disable it, and everything else should
work. - MLD
Use --disable-volk on the configure command line to disable it, and everything
else should work.
Right. CMake. Use what Josh said: -DENABLE_VOLK=OFF on the cmake
command line. I’m still in GNU autotools mode. - MLD
I got everything working in the end by upgrading python to 2.7 and by
using the standard autotools installation with volk disabled (I didn’t
try in with volk enabled based on your advice).
However, for the sake of completeness, here is the error that
prevented me from using cmake with python 2.7 installed.
[ 9%] Building C object
gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/sse_debug.c.o
[ 9%] Building C object
gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/float_dotprod_sse64.S.o
float_dotprod_sse64.S:66:bad register name %rdx' float_dotprod_sse64.S:76:bad register name%rax’
float_dotprod_sse64.S:81:bad register name %rsi)' float_dotprod_sse64.S:82:bad register name%rdi)’
float_dotprod_sse64.S:83:bad register name %rdi' float_dotprod_sse64.S:84:bad register name%rsi’
float_dotprod_sse64.S:87:bad register name %rax' float_dotprod_sse64.S:96:bad register name%rdx’
float_dotprod_sse64.S:101:bad register name %rsi)' float_dotprod_sse64.S:103:bad register name%rsi)’
float_dotprod_sse64.S:111:bad register name %rdi)' float_dotprod_sse64.S:113:bad register name%rsi)’
float_dotprod_sse64.S:115:bad register name %rdi)' float_dotprod_sse64.S:117:bad register name%rsi)’
float_dotprod_sse64.S:119:bad register name %rdi)' float_dotprod_sse64.S:121:bad register name%rsi)’
float_dotprod_sse64.S:123:bad register name %rdi)' float_dotprod_sse64.S:125:bad register name%rsi)’
float_dotprod_sse64.S:127:bad register name %rdi' float_dotprod_sse64.S:128:bad register name%rsi’
float_dotprod_sse64.S:129:bad register name %rdx' float_dotprod_sse64.S:158:suffix or operands invalid forret’
make[2]: ***
[gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/float_dotprod_sse64.S.o]
Error 1
make[1]: *** [gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/all]
Error 2
make: *** [all] Error 2
volk_machine_sse2_32.c, volk_machine_sse3_32.c,
I’ll install a newer version of python and see if I have more luck.
The -B tells python not to generate .pyc files (to keep junk from being
generated in tree). I didnt realize it was for 2.6 and up.
For now, you can harmlessly remove it, or alternatively, disable volk
-DENABLE_VOLK=ON/OFF
-josh