Gnuradio component directory structure

GNU Radio
1

This is the currently recommended directory structure:
http://gnuradio.org/redmine/projects/gnuradio/wiki/Development2#Top-level-Directory-Structure

I think there has been some wavering around an “include” directory. I
personally like the idea of an include directory because:

  1. It separates publicly installed headers vs private headers in the lib
    directory.

  2. Its a cleaner separation of API and implementation.

  3. Its easier to point doxygen to the public headers and keep it from
    parsing everything in “lib”.

Example of a component w/ include:
http://gnuradio.org/redmine/projects/gnuradio/repository/revisions/master/entry/gr-audio/

Example of a component w/ lib only:
http://gnuradio.org/redmine/projects/gnuradio/repository/revisions/master/show/gr-qtgui

Thoughts?

-Josh

2

On Sat, Sep 17, 2011 at 3:14 PM, Martin B. [email protected]
wrote:

I’d like to point out a disadvantage to get a discussion going:
While you’re developing, this might be an inconvenience because the
files are physically separated. Most IDEs/editors have many features
such as tagging, switching from headers to sources and vice versa, ‘go
to file at cursor’ commands etc. If half of the files are somewhere
else, one has to set up the editor specifically for this dir structure
to do all of this.

It’s a logical separation that a lot of projects use. I know that I’m a
bit
biased because my “IDE” is Emacs, but I don’t recall having project
files in
different directories was a problem. Way back when I developed in
Windows
and used Visual Studio, this wasn’t an issue, but that could have been
due
to the project file that VS kept.

We haven’t made it part of our official standard, but talking with both
Johnathan and Josh last week about it, I was thinking that we would. I’m
not
sure that your argument here has quite convinced me that it’ll be a
problem.

Tom

Tom

3

I’d like to point out a disadvantage to get a discussion going:
While you’re developing, this might be an inconvenience because the
files are physically separated. Most IDEs/editors have many features
such as tagging, switching from headers to sources and vice versa, ‘go
to file at cursor’ commands etc. If half of the files are somewhere
else, one has to set up the editor specifically for this dir structure
to do all of this.

Also, …

On Thu, Sep 15, 2011 at 06:12:56PM -0400, Josh B. wrote:

This is the currently recommended directory structure:

http://gnuradio.org/redmine/projects/gnuradio/wiki/Development2#Top-level-Directory-Structure

I think there has been some wavering around an “include” directory. I
personally like the idea of an include directory because:

  1. It separates publicly installed headers vs private headers in the lib
    directory.

  2. Its a cleaner separation of API and implementation.

This are good points, but also a matter of taste, and…

  1. Its easier to point doxygen to the public headers and keep it from
    parsing everything in “lib”.

…I wonder if this really a problem if cmake has a list of public
include files anyway.

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 Wed, Sep 21, 2011 at 10:04:23AM -0400, Tom R. wrote:

It’s a logical separation that a lot of projects use. I know that I’m a bit
biased because my “IDE” is Emacs, but I don’t recall having project files in
different directories was a problem. Way back when I developed in Windows and
used Visual Studio, this wasn’t an issue, but that could have been due to the
project file that VS kept.

We haven’t made it part of our official standard, but talking with both
Johnathan and Josh last week about it, I was thinking that we would. I’m not
sure that your argument here has quite convinced me that it’ll be a problem.

To be honest,

after re-reading this, I’m not even convinced myself.
Sometimes I just like to argue :slight_smile:

Martin

–
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

5

On Mon, Sep 26, 2011 at 3:39 AM, Martin B. [email protected]
wrote:

else, one has to set up the editor specifically for this dir

used Visual Studio, this wasn’t an issue, but that could have been due to
To be honest,

after re-reading this, I’m not even convinced myself.
Sometimes I just like to argue :slight_smile:

Martin

Always good to have the discussion. I think we’re settled on the use of
include directory, then.

Thanks!
Tom

6

On Mon, Sep 26, 2011 at 11:48 AM, Ben H. [email protected]
wrote:

  1. Its a cleaner separation of API and implementation.
    the headers, and a lot of it is usually extremely helpful (at least to me)
    when I’m hacking around.

Again, this is obviously preference. If you only want Doxygen to document
the public GNURadio API, then obviously you only want to point it to
include. For actually developing inside of GNURadio, however, I often
find having the lib/ documentation to be very helpful.

Cheers,
Ben

I agree with everything you’ve said here. I think we’ll be including
both.
There’s some maintenance work on Doxygen that I need to sort out soon,
so
making sure we’re picking up everything that we want is going to be part
of
it.

Thanks,
Tom