On Mon, Dec 19, 2011 at 4:21 AM, Martin Braun
<address@hidden> wrote:
On Sun, Dec 18, 2011 at 03:41:13PM -0500, Tom Rondeau wrote:
> Hey list,
>
> I'm working on merging Josh's gr_blocks branch into GNU Radio, and he's made a
> few structural changes to how things will be installed. I wanted to have a
> discussion to see what people felt about the changes. Note that this only
> affects the new stuff that's added (gr-blocks and gr-filter). However, we will
> be deprecating the old blocks that these replace and have them removed in one
> of the upcoming versions, so at that point, the new structure becomes
> important.
Hi Tom,
could you please give us a link to the relevant branch? Josh sends so
many git-URLs around, it's a bit hard to keep track :)
See the gr_blocks branch on my github:
This builds under autotools, has QA code, and other fixes.
> If you look at any of the source files in gr-blocks, you'll see that he's made
> and started using namespaces a great deal more than before, and he's using
> another level of inheritance and abstraction to provide a different way of
> auto-generating blocks that do the same operation on different types (as
> opposed to the gengen work that uses Python to build code out of templates).
> This is all probably a good thing.
>
> The differences, though, coming in the naming scheme and installation method.
> Instead of having a gr_<name>.h file installed into $prefix/include/gnuradio,
> it's just <name>.h that is installed into $prefix/include/gnuradio/blocks.
> Likewise, the headers in gr-filter are installed into $prefix/include/gnuradio/
> filter.
As Michael said, this sounds like a good thing. Namespaces and proper file names in
combination with proper directory names is the way to go.
> Any thoughts? No response will be regarded as acceptance of the NCO (new code
> order) :)
Many, many cool things have been happening in the last couple of years.
However, the 3.x version branch has morphed incredibly since 3.0.
Perhaps, at some time when all the glitches have been figured out, and a
sensible structure and API have been developed, it would make sense to make a cut,
deprecate all the old stuff and call it GNU Radio 4.0.
Version 3.5 is already very different from 3.0, and every change in
structure/API doesn't really help people who actually want a stable
version of GNU Radio (although I belong to those who prefer an unstable
one with lots of new features :).
MB
That's an excellent point, Martin. It might be time to start thinking about a 4.0 release. We have had significant changes, and some of this new stuff adds even more. Even the constructors in gr-blocks are different. It's not simply going from gr.add_ff to blocks.add. The new API asks you to specify the data type the block works with instead of having a suffix for it. I'm not entirely sold on this, yet, but am thinking of ways rework it (for instance, the current blocks allow you to specify _a_ type, but not, say, and input and and output type).
Regardless of the specifics, we're talking about a pretty big change in what people are used to. You might be right that it's time we moved up a major version number.
Thoughts (Johnathan, I'm looking at you)?
Thanks!
Tom