Thanks, Tom and Johnathan for the feedback. We understand that you are
doing your best effort to bring the new release ASAP, and we appreciate
this new organization of the source code; it makes our code clearer and
avoids unnecessary dependencies. The transition using the master/next
branches is quite clean and easy to catch on to, and we can live with the
occasional breaks (at least for a few weeks :-)) since it's all for a
better endeavor.

Best regards,
Carles





On Wed, Apr 3, 2013 at 5:20 PM, Johnathan Corgan
<[email protected]>wrote:

> On Wed, Apr 3, 2013 at 2:51 AM, Carles Fernandez
> <[email protected]> wrote:
>
> > Thanks Tom for keeping us updated about the required changes for C++
> > applications that builds against GNU Radio. We are working to adapt our
> code
> > from 3.6 to 3.7 API, and these advices save us a nice amount of time.
> Let me
> > say that the process is running quite smoothly and we are not having big
> > issues in the porting.
>
> Happy to hear that there are no problems.
>
> > Is there a tentative date for releasing 3.7? We are now working with the
> > next branch for adapting our code, but at this moment we should decide
> if we
> > break compatibility with the master branch (3.6 API) in order to go on
> with
> > the required modifications (and asking our users to build the next branch
> > instead of the master, at least until the release of GNU Radio 3.7), or
> just
> > wait for those forthcoming changes.
>
> Our plan is to have the final 3.7 API on the next branch in place very
> quickly, but we haven't set a firm date.  There is one major API
> change left (converting the runtime code to the virtual private
> implementation pattern) to do before then.  This will affect users'
> C++ code in several ways.
>
> First, includes will change in form from these examples:
>
> #include <gr_sync_block.h>
> #include <gr_io_signature.h>
> #include <audio/source.h>
> #include <filter/pfb_decimator_ccf.h>
>
> ...to:
>
> #include <gnuradio/sync_block.h>
> #include <gnuradio/io_signature.h>
> #include <gnuradio/audio/source.h>
> #include <gnuradio/filter/pfb_decimator_ccf.h>
>
> Secondly, the C++ classes in the GNU Radio runtime will be accessed
> through the 'gr' namespace, so class declarations that look like:
>
> class my_foo_block : public gr_sync_block {...};
> class my_top_block : public gr_top_block {...};
>
> ...will become:
>
> class my_foo_block : public gr::sync_block {...};
> class my_top_block : public gr::top_block {...};
>
> Finally, creating instances of classes in the runtime will use the
> static class make() function, instead of calling the separate
> gr_make_* calls.  Thus:
>
> gr_make_io_signature(1, 1, sizeof(gr_complex))
>
> ...becomes:
>
> gr::io_signature::make(1, 1, sizeof(gr::complex))
>
> Python and GRC code won't be affected by this change.
>
> It's been a very long time in coming, but once we get this final
> change in place, the remaining work for 3.7 is bug fixing, doc
> cleanup, and having release candidate testing until we're convinced
> that it is stable enough to become the new master.  We'll be
> documenting the process of porting existing code from 3.6 to 3.7 on
> the wiki (Tom has already started this).  Fortunately, it's almost all
> mechanical in nature like the above, and can largely be automated with
> tools like sed.
>
> The 3.6 -> 3.7 change has been a grand internal refactoring while most
> major new features have happened in parallel (without breaking user
> code) on the 3.6 release series.  It's been increasingly difficult to
> maintain these consistent with each other, so Tom and I have a strong
> motivation to get this done as quickly as possible.
>
> --
> Johnathan Corgan
> Corgan Labs - SDR Training and Development Services
> http://corganlabs.com
>
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to