discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] New structural change


From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] New structural change
Date: Mon, 19 Dec 2011 14:00:07 -0500

On Sun, Dec 18, 2011 at 8:30 PM, Michael Dickens <address@hidden> wrote:
On Dec 18, 2011, at 3:41 PM, Tom Rondeau wrote:
> 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.

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_<name>.h" headers around, but all they do is 2 things:

1) print out a #warning about being deprecated, and to instead use "blocks/<name>.h" -- or, whatever makes sense for such a message; and

2) #include "blocks/<name>.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_<name>.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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]