Major update to gnuradio repository 'next' branch

Note: This email only applies to GNU Radio users who have been using
the GNU Radio “3.7 experimental” next branch. The changes below do
not impact the majority of users. In particular, if you have
installed GNU Radio by compiling a release tarball, have used the
‘build-gnuradio’ script to retrieve and compile GNU Radio, have used
‘git clone’ to retrieve, then compile the GNU Radio master development
branch, have installed GNU Radio from an operating system supplied
package, or are using the Ettus R. LiveUSB or Instant SDR
products, you are not affected.

Tom R. and I have completed the second phase of the transition on
the ‘next’ branch to the 3.7 release code organization.

Phase I was to move all the gnuradio blocks out from inside
gnuradio-core into a new set of top-level components, and rewrite them
using C++ namespaces and the virtual private implementation class
pattern (details and benefits of doing this are covered in previous
emails.) This happened over a long period of time and was recently
completed.

Phase II, which has just been merged into next, was to extract the GNU
Radio runtime code into a new directory, gnuradio-runtime, and
eliminate gnuradio-core altogether.

The changes at this point primarily affect the build of out-of-tree
C++ projects, which now need to link against libgnuradio-runtime
instead of libgnuradio-core. We have supplied a new CMake module,
FindGnuradioRuntime.cmake, which you can use to replace your existing
FindGnuradioCore.cmake file. The pkgconfig library name is now
gnuradio-runtime as well.

The gr_modtool program for building out-of-tree modules on the next
branch has been updated to work with the name change. The directory:

gr-utils/python/modtool/gr-newmod/

…now contains the canonical structure for out-of-tree GNU Radio C++
modules, and you can look here to see what your out-of-tree build
should look like to work with the 3.7 next branch.

We have now removed the gr-howto-write-a-block component to reflect
this.

In order to update your GNU Radio software (again, only for those
tracking the next branch), it is strongly recommended that you first
do a ‘sudo make uninstall’ from within the build directory you created
when compiling GNU Radio. Then delete that build directory. This
will remove all traces of the existing GNU Radio libraries before
updating.

To update your next branch, it is sufficient to do a ‘git pull’ to get
the lastest changes. At that point, you can proceed to re-create the
build directory and perform the steps needed to build and install GNU
Radio again.

Python scripts and GRC programs that were already working with the
latest next branch will be unaffected by this change.

Johnathan C.
Corgan Labs

Hi,

The changes at this point primarily affect the build of out-of-tree
C++ projects, which now need to link against libgnuradio-runtime
instead of libgnuradio-core. We have supplied a new CMake module,
FindGnuradioRuntime.cmake, which you can use to replace your existing
FindGnuradioCore.cmake file. The pkgconfig library name is now
gnuradio-runtime as well.

Is there a way to have out of tree modules compatible with both 3.6 and
3.7 ?

Cheers,

Sylvain

On Thu, Mar 28, 2013 at 1:51 AM, Sylvain M. [email protected]
wrote:

The changes at this point primarily affect the build of out-of-tree
C++ projects, which now need to link against libgnuradio-runtime
instead of libgnuradio-core. We have supplied a new CMake module,
FindGnuradioRuntime.cmake, which you can use to replace your existing
FindGnuradioCore.cmake file. The pkgconfig library name is now
gnuradio-runtime as well.

Is there a way to have out of tree modules compatible with both 3.6 and 3.7 ?

For now, I think this could be accomplished with clever CMake hackery
(in the out-of-tree module) to attempt to detect libgnuradio-core vs.
libgnuradio-runtime, and set up the linkage appropriately. The actual
runtime code hasn’t changed, yet.

However, the 3.7 runtime C++ API will be undergoing the same virtual
private implementation overhaul as the C++ blocks API did, which will
make it incompatible with the current 3.6 API. This is the reason it
will be a new major release number and being done on the ‘next’ branch
vs. the ‘master’ branch.

Johnathan