On Mon, Dec 19, 2011 at 4:21 AM, Martin Braun <martin.br...@kit.edu> 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: git://github.com/trondeau/gnuradio.git 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
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
