There are lots of changes on the way in GNU Radio. But since I don't think that I can say it better, here is Johnathan Corgan's email to the GNU Radio mailing list from yesterday describing it:
Some of you may have noticed recent check-ins that have added new
top-level components (like gr-fft), or duplication of blocks (such as
into gr-digital.) I'd like to explain the master plan Tom and I are
working from and what to expect over the next few weeks.
Essentially, we are making two things happen at the same time:
- libgnuradio-core is going away, and its blocks are being reorganized
into several new, smaller libraries
- The C++ API is changing to use pure virtual interface classes, C++
namespaces, and segregated header files
These two transitions will occur in such a way that as much work as
possible will be completed on the master branch but without requiring
any changes to your existing code, and the rest will happen on the
next branch.
The gnuradio-core component has accumulated hundreds of blocks over
the last 10 years. In order to simplify and organize things, we are
creating several new top-level components to replace it. The first
step of this was done when gr-digital collected much of the digital
modulation/demodulation code up into its own component. The second
step was to create gr-wavelet and move the wavelet blocks into that.
When we are done, the following top-level components will hold all the
code that used to be in gnuradio-core:
* gr-blocks - "basic" blocks used widely across many flowgraphs, like
math operations, type conversions, stream/vector manipulation,
file/message/network sources/sinks, etc.
* gr-analog - analog waveform processing blocks such as signal
sources, AM/FM modulation/demodulation, AGC, squelch, power
measurement, etc.
* gr-digital - digital waveform processing blocks such as PSK and OFDM
modulation, scramblers, timing and carrier recovery, channel
equalization, bit packing/unpacking, framers, deframers, CRC, etc.
* gr-fec - Reed-Solomon and convolutional coding, future development
* gr-fft - blocks that wrap the external FFTW library
* gr-filter - FIR and IIR filters, filter design, resampling,
channelizers, channel models
* gr-vocoder - voice processing codecs
* gr-wavelet - wavelet processing blocks, future development
* gnuradio-runtime - top block and friends and runtime scheduler, very
small number of blocks for QA testing of runtime (vector source/sink,
null source/sink, etc.)
The process we are following to get this done is to create the new top
level components on the master branch and copy the existing blocks
into them, then remove the old blocks from gnuradio-core *on the next
branch only*. In this way, developers can, if they wish, start
migrating their applications to use the new block hierarchy in their
applications as they become available, without having to do it all at
once. Existing code, however, can also be left alone without any
impact as gnuradio-core itself will remain unchanged until the 3.7
release.
Part of this process is already done--gr-vocoder, gr-digital, and
gr-wavelet are part of the current release. The new gr-fft was merged
into master recently. Soon, gr-filter will be added in, and then we
will remove all fft and filter blocks out of gnuradio-core on the 3.7
branch only. Today, several more blocks from gnuradio-core were
copied into gr-digital, and again, we'll soon delete those blocks out
of gnuradio-core on the 3.7 branch only.
Since we're touching so much code, we're taking the opportunity make a
change to the C++ API to implement pure virtual interface classes for
API visible code. This was discussed on the mailing list March 12.
In addition, we're reorganizing the API to use C++ namespaces, which
shortens filenames, simplifies the Python wrapper generation, and
eliminates some redundancies in class naming. You can see an example
of this in the new gr-fft directory on the master branch, or in the
gr-wavelet directory on the next branch.
The same process for dividing the work between the master branch and
next branch applies here. Where possible, when we copy over blocks
from gnuradio-core to the new top-level components, we'll convert them
to use the new C++ coding style. This won't affect any existing
user's code, as the old blocks will stay in gnuradio-core. For all
the rest of GNU Radio outside of gnuradio-core, we'll be making the
C++ changes on the next branch, again so as to not disturb existing
user's code.
Finally, during all this, as we implement the new block structure,
we're going to pay special attention to:
- Reimplementing functionality using libvolk vector optimization where possible
- Updating or adding missing header file documentation
- Converting code where needed to conform to the GNU Radio coding style guide
- Adding QA test code if missing
- Creating GRC block wrappers if missing
- Removing obsolete code or other cruft
Few of these changes will impact Python or GRC users, except that most
blocks that once lived in the 'gr' namespace imported from gnuradio
will instead import from a different namespace under gnuradio, such as
is already done for gr-audio, gr-digital, gr-uhd, etc.
The net of all this is that we expect the 3.7 C++ API to be better
organized, easier to use, and have better documentation, but without
changing much of the functionality other than performance
improvements.
Tom and I will be working up documentation on the wiki detailing the
changes as we go along, and there will be a 3.6->3.7 conversion guide
for C++, Python, and GRC GNU Radio applications.
So, as they say, "pardon our dust".
Johnathan