[Discuss-gnuradio] Upcoming changes in the development trunk

[Johnathan Corgan]

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