[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss-gnuradio] Recent development activity, upcoming plans

From: Johnathan Corgan
Subject: [Discuss-gnuradio] Recent development activity, upcoming plans
Date: Sun, 1 Apr 2012 18:48:57 -0700

I just wanted to give a heads up on several things that are in flight
right now, and what Tom and I are planning soon.

- Removal of dependency on gsl for gnuradio-core. The wavelet blocks
that were in gnuradio-core, which depend on the GNU Scientific Library
for some of their functions, have been moved into their own top-level
component, gr-wavelet.  This means that for the majority of users, the
need for installing libgsl and libgsl-dev will go away.  Python users
wishing to use these blocks will find them in the 'wavelet' namespace
under gnuradio, and C++ users will find them renamed to wavelet_*.

- Clean up and preparation for releasing 3.5.3.  There are still a few
more development items remaining to merge in, but we expect to tag and
release this next weekend.  Numerous bug fixes, the addition of
support for the FUNcube dongle SDR, enhancements to support the Ettus
Research UHD 3.4.0 release, and a few smaller items will make this

- Preparation to to merge the 'next' branch back in to 'master', after
the 3.5.3 release.  The 'next' branch is the long-running development
branch where we implement things that are either somewhat unstable, or
more often, make changes to the API such that user code might break.
After the 3.5.3 stable release, we'll switch the master branch to the
3.6 API by merging 'next' back into master.  The largest change
involved here is the official switch from GNU autotools to CMake as
the build system for GNU Radio. Our plan is to focus on testing and
prepping for a 3.6.0 release, then start a new long-term 'next' branch
for the 3.7 API.

If you normally use GNU Radio by compiling from a tarball, these
changes won't affect to you until you start using the 3.5.3 or 3.6.0
release tarballs. If you are tracking our master branch and compiling
from that, then once 3.5.3 releases, you need to be prepared for the
change to the 3.6 API.

More details on the changes will be provided in release notes and on
the list here.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]