[Discuss-gnuradio] New structural change

[Tom Rondeau]

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.

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.

This is a fairly minor change. And if we started from scratch today, this would probably be the way we would do it. The namespace takes care of the need for a prefix on everything, and the include directories are a pretty typical convention for splitting these kinds of things up.

My only problem is that this is going to have to be understood by the community at large, specifically those who do under-the-hood development work with GNU Radio. Also, some things will follow this new convention and some things won't, at least for a period of time until all of the other blocks are moved over to this new structure. So there's going to be inconsistencies when developing blocks or code that use these things. You'll have to pay attention to where these things are and if they follow the old or new conventions.

And does it matter if we document the new way thoroughly enough and where all of the new stuff is? (It's unlikely/unreasonable that we'll do this for all blocks, but we should make it apparent for the new stuff, at least).

Any thoughts? No response will be regarded as acceptance of the NCO (new code order) :)

Thanks,

Tom