Now that we have a new stable release series, I want to alert developers to some upcoming changes in the GNU Radio trunk which will impact your software, requiring changes on your part in order to continue to compile and link against a version of GNU Radio built from the trunk.
For those of you who need to maintain source code compatibility, you should be using either the official release 3.2 tarball, the Ubuntu binary packages, or a Subversion checkout of the release 3.2 branch. This code branch will have backported bug fixes and new features, but only those which can be implemented without breaking existing source code. In no particular order of time or importance, these are among some of the changes planned for the development trunk and 3.3 release that may affect you: * Removal of the omnithreads library/switchover to Boost threads. This is a C++ auxiliary library used internally as a layer on top of pthreads, but made available for users as well. Python API users will be unaffected, as will most C++ API users, but if you've used this library directly, you'll need to investigate replacements from the Boost threading library. This changeover has been going on for some time already. * Elimination of the single-threaded flowgraph scheduler. The "thread-per-block" scheduler is already the default in 3.2. While this won't require any code changes, if you've been manually selecting the STS via the environment, you won't be able to do this anymore. * Replacement of usrp-inband code for USRP1. Using the to-be-developed merge of message passing capabilities into gr-blocks, the USRP1 (and USRP2) will have timed transmit/receive and metadata capabilities from within the traditional (non-mblock) GNU Radio C++ and Python APIs. * Migration of blks2 into C++. This has been a place to hold hierarchical blocks constructed in Python. Many of these blocks will be reimplemented as C++ API hierarchical blocks, and re-exported into Python as part of the core 'gr' namespace. This will done where possible without syntax changes needed in your Python code other than the namespace to import from. * Movement of libusrp header files into 'include/usrp' directory. Today, these are installed into the global $prefix/include directory, with the possibility of name clashes with other header files. If you are using libusrp directly, you'll need to update your #include<> statements in your C++ code. * Deprecation and eventual removal of gr-comedi. This component provides GNU Radio blocks for the libcomedi interface to many ADC cards. However, it is no longer compatible with the current libcomedi API, and without a maintainer or the ability to test correctness, it is becoming stale. If this component is important to you, we'd love to hear from you. There are of course many new capabilities planned for 3.3, which will be the subject of another email, and Eric has already touched on a few in his prior email after the release of 3.2. Johnathan Corgan Corgan Enterprises LLC _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
