New structural change

GNU Radio
1

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_.h file installed into
$prefix/include/gnuradio, it’s just .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) :slight_smile:

Thanks,
Tom

2

On Dec 18, 2011, at 3:41 PM, Tom R. wrote:

The differences, though, coming in the naming scheme and installation
method. Instead of having a gr_.h file installed into
$prefix/include/gnuradio, it’s just .h that is installed into
$prefix/include/gnuradio/blocks. Likewise, the headers in gr-filter are
installed into $prefix/include/gnuradio/filter.

I like this change in header include structure. Most of the projects I
work on do it this way, and it makes a lot of sense. Because this will
be a change that impacts just about everyone doing C++ development using
GNU Radio, I think -if possible- it would be good to keep the
“gr_.h” headers around, but all they do is 2 things:

  1. print out a #warning about being deprecated, and to instead use
    “blocks/.h” – or, whatever makes sense for such a message; and

  2. #include “blocks/.h” so that the user’s code still compiles as
    before

That way, we benefit from the new header include structure, but aren’t
totally screwed if we’ve forgotten to use it. And, somewhere down the
road after an appropriate amount of time, the “gr_.h” headers can
be removed entirely, if desired, because everyone has been well warned.
I hope something along this line can be done.

  • MLD
3

On Sun, Dec 18, 2011 at 03:41:13PM -0500, Tom R. 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 :slight_smile:

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) :slight_smile:

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

–
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin B.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

4

On 12/18/2011 08:30 PM, Michael D. wrote:

  1. #include “blocks/.h” so that the user’s code still compiles as before

That way, we benefit from the new header include structure, but aren’t totally
screwed if we’ve forgotten to use it. And, somewhere down the road after an
appropriate amount of time, the “gr_.h” headers can be removed entirely, if
desired, because everyone has been well warned. I hope something along this line
can be done.

At the same time, can we clean up the various combination of
-I/usr/inclide/gnuradio etc

with

#include “gr-header.h”
#include “gnuradio/gr-header.h”

?

I’d like to see the use of -I dropped where possible and all header
files referred to relative to /usr/include (or /usr/local/include)

Philip

5

I also like the structure change, and I think Michael’s suggestion for
handling the migration is perfect.

Cheers,
Ben

6

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 :slight_smile:

Browse here:
http://gnuradio.org/cgit/jblum.git/tree/gr-blocks?h=gr_blocks
http://gnuradio.org/cgit/jblum.git/tree/gr-filter?h=gr_blocks

-Josh

7

On Mon, Dec 19, 2011 at 4:21 AM, Martin B. [email protected]
wrote:

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 :slight_smile:

See the gr_blocks branch on my github:
git://github.com/trondeau/gnuradio.git

This builds under autotools, has QA code, and other fixes.

As Michael said, this sounds like a good thing. Namespaces and proper file
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

8

On Sun, Dec 18, 2011 at 8:30 PM, Michael D. [email protected]
wrote:

Radio, I think -if possible- it would be good to keep the “gr_.h”
after an appropriate amount of time, the “gr_.h” headers can be
removed entirely, if desired, because everyone has been well warned. I
hope something along this line can be done.

  • MLD

That’s a good way to go about it, thanks.

I think we can safely introduce it into the 3.5 versions and basically
not
even mention it’s there. It’ll just be an add-on for people who either
want
it or need it (since many of the blocks are using Volk, the performance
benefits might be useful to certain applications). We’ll have some
documentation to explain the state and how to use it.

When we update the version and start making this the main way to go, we
will deprecate the blocks in gnuradio-core that it replaces.

We’ve been very bad in the past about having actual deprecation
messages.
You only know that something is deprecated if you read everything on
this
mailing list or got to the ChangeLog (file or the new wiki I put up with
3.5). That’s not very helpful. So hopefully, everyone can help keep us
honest about issuing deprecation warnings in these blocks when we get
there.

Tom

9

On Dec 19, 2011, at 10:40 AM, Philip B. wrote:

At the same time, can we clean up the various combination of

-I/usr/inclide/gnuradio etc

with

#include “gr-header.h”

#include “gnuradio/gr-header.h”

?

I’d like to see the use of -I dropped where possible and all
header

files referred to relative to /usr/include (or
/usr/local/include)

I’ll second or third Phil’s proposal! If "we"re doing to make
major changes to the header include location / path / structure,
let’s just get it done. Won’t be greatly fun, but just think how
good "we"ll all feel once it’s done :slight_smile: - MLD

10

On Mon, Dec 19, 2011 at 10:40 AM, Philip B.
[email protected]wrote:

a change that impacts just about everyone doing C++ development using GNU
totally screwed if we’ve forgotten to use it. And, somewhere down the road
#include “gnuradio/gr-header.h”

?

I’d like to see the use of -I dropped where possible and all header
files referred to relative to /usr/include (or /usr/local/include)

Philip

Agreed. We should definitely make it that way.

If, following along from my thoughts to Martin, we move to v4.0, we
would
probably want to change every block to have the new constructor style.
At
the same time, we’d need to change everything to work with the new
include
hierarchy.

Man, that’s going to be fun…

Tom