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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
