Updating to 3.7/next (currently)

GNU Radio
1

Hi everyone,

Because of the large diff between 3.6 and 3.7, there’s going to be a
lot of breakage happening with code when moving to 3.7. Luckily, most
of these changes are simple syntax related edits, like in Python to
move from almost everything being in the gr module to other modules
like blocks, analog, digital, etc.

With the changes just recently posted to the next branch, we are now
changing things that will break external code that compiles against
GNU Radio. This is the first pass and there will be other changes to
come. If you are tracking our next branch, here are a few things to
keep in mind when building against GNU Radio:

  • Remove FindGnuradioCore.cmake and FindGruel.cmake,
    Replace with FindGnuradioRuntime.cmake

  • Remove all GRUEL_ references and replace GNURADIO_CORE variables
    with GNURADIO_RUNTIME_

  • Update #include<gruel/attributes.h> to <gnuradio/attributes.h>

  • Change %include “gnuradio.i” to %include “runtime_swig.i”

There are other changes required that have been discussed in the past.
This just represents the most recent updates and how to work with
them.

Thanks,
Tom

2

Thanks Tom for keeping us updated about the required changes for C++
applications that builds against GNU Radio. We are working to adapt our
code from 3.6 to 3.7 API, and these advices save us a nice amount of
time.
Let me say that the process is running quite smoothly and we are not
having
big issues in the porting.

Is there a tentative date for releasing 3.7? We are now working with the
next branch for adapting our code, but at this moment we should decide
if
we break compatibility with the master branch (3.6 API) in order to go
on
with the required modifications (and asking our users to build the next
branch instead of the master, at least until the release of GNU Radio
3.7),
or just wait for those forthcoming changes.

Best regards,
Carles

3

On Wed, Apr 3, 2013 at 5:51 AM, Carles Fernandez
[email protected] wrote:

Thanks Tom for keeping us updated about the required changes for C++
applications that builds against GNU Radio. We are working to adapt our code
from 3.6 to 3.7 API, and these advices save us a nice amount of time. Let me
say that the process is running quite smoothly and we are not having big
issues in the porting.

Great to here, Carles. We will try our best to keep providing this
information. I’ve also started collecting it on a wiki page that we
will work on when 3.7 is finally released.

Is there a tentative date for releasing 3.7? We are now working with the
next branch for adapting our code, but at this moment we should decide if we
break compatibility with the master branch (3.6 API) in order to go on with
the required modifications (and asking our users to build the next branch
instead of the master, at least until the release of GNU Radio 3.7), or just
wait for those forthcoming changes.

Best regards,
Carles

There is no set date. We have some internal goals, but nothing that’s
official. My only date is ASAP. With the divergence of next from
master, it’s becoming very difficult to maintain and keep everything
sane. And there have been enough times recently where we have failed
to do that, which is just another indication that we need to bring
this effort to a close.

Tom

4

Thanks, Tom and Johnathan for the feedback. We understand that you are
doing your best effort to bring the new release ASAP, and we appreciate
this new organization of the source code; it makes our code clearer and
avoids unnecessary dependencies. The transition using the master/next
branches is quite clean and easy to catch on to, and we can live with
the
occasional breaks (at least for a few weeks :-)) since it’s all for a
better endeavor.

Best regards,
Carles

On Wed, Apr 3, 2013 at 5:20 PM, Johnathan C.

5

On Wed, Apr 3, 2013 at 2:51 AM, Carles Fernandez
[email protected] wrote:

Thanks Tom for keeping us updated about the required changes for C++
applications that builds against GNU Radio. We are working to adapt our code
from 3.6 to 3.7 API, and these advices save us a nice amount of time. Let me
say that the process is running quite smoothly and we are not having big
issues in the porting.

Happy to hear that there are no problems.

Is there a tentative date for releasing 3.7? We are now working with the
next branch for adapting our code, but at this moment we should decide if we
break compatibility with the master branch (3.6 API) in order to go on with
the required modifications (and asking our users to build the next branch
instead of the master, at least until the release of GNU Radio 3.7), or just
wait for those forthcoming changes.

Our plan is to have the final 3.7 API on the next branch in place very
quickly, but we haven’t set a firm date. There is one major API
change left (converting the runtime code to the virtual private
implementation pattern) to do before then. This will affect users’
C++ code in several ways.

First, includes will change in form from these examples:

#include <gr_sync_block.h>
#include <gr_io_signature.h>
#include <audio/source.h>
#include <filter/pfb_decimator_ccf.h>

…to:

#include <gnuradio/sync_block.h>
#include <gnuradio/io_signature.h>
#include <gnuradio/audio/source.h>
#include <gnuradio/filter/pfb_decimator_ccf.h>

Secondly, the C++ classes in the GNU Radio runtime will be accessed
through the ‘gr’ namespace, so class declarations that look like:

class my_foo_block : public gr_sync_block {…};
class my_top_block : public gr_top_block {…};

…will become:

class my_foo_block : public gr::sync_block {…};
class my_top_block : public gr::top_block {…};

Finally, creating instances of classes in the runtime will use the
static class make() function, instead of calling the separate
gr_make_* calls. Thus:

gr_make_io_signature(1, 1, sizeof(gr_complex))

…becomes:

gr::io_signature::make(1, 1, sizeof(gr::complex))

Python and GRC code won’t be affected by this change.

It’s been a very long time in coming, but once we get this final
change in place, the remaining work for 3.7 is bug fixing, doc
cleanup, and having release candidate testing until we’re convinced
that it is stable enough to become the new master. We’ll be
documenting the process of porting existing code from 3.6 to 3.7 on
the wiki (Tom has already started this). Fortunately, it’s almost all
mechanical in nature like the above, and can largely be automated with
tools like sed.

The 3.6 → 3.7 change has been a grand internal refactoring while most
major new features have happened in parallel (without breaking user
code) on the 3.6 release series. It’s been increasingly difficult to
maintain these consistent with each other, so Tom and I have a strong
motivation to get this done as quickly as possible.

–
Johnathan C.
Corgan Labs - SDR Training and Development Services
http://corganlabs.com