On config.h (was Check for gr-ctrlport)

GNU Radio
1

On Sat, Mar 30, 2013 at 9:42 AM, Tom R. [email protected] wrote:

Hi Alex,

Good question. This is what the config.h file is for. It’s installed
into $prefix/include/gnuradio/config.h. If ControlPort is defined and
built for the project, it will be defined in this file as “#define
GR_CTRLPORT”. If you include that header file, you can test #ifdef
GR_CTRLPORT in your own work.

Tom

A brief digression: on the issue of exporting (i.e. installing to
$prefix/include/gnuradio) the compile time options GR was built with:
I love this, and think its the right thing to do to let applications
know what options were enabled in the build (GR_CTRLPORT,
GR_PERFORMANCE_COUNTERS, ENABLE_GR_LOG, etc., etc.), however I do want
to discuss what the correct name of the include file should be. I’m
used to the ‘old’ autoconf way of using a config.h internally for a
project to know what the configure script turned on/off, but exporting
something with a generic name of config.h seems to me like it’s
begging for a collision with some other config.h: for example, if -
horror of horrors - I’m building an OOT module (or GR-based
application) that’s still using autoconf, or some other automagically
generated config.h to handle my internal compile-time options, then
I need to jump through some hoops to make sure that when I want to
check the external config.h to see what GR was built with.

The “easy” fix is to #include <gnuradio/config.h> for those
GR-specific options, and #include “config.h” for my internal ones.
However, that does imply that $prefix/include (i.e. the level above
the gnuradio-installed headers) is in my compiler’s include path. If
I’ve install to a standard location (i.e. 98% of all cases) this will
never be a problem. However, because the canonical OOT cmake setup
(i.e. gr_modtool) wants gnuradio includes in the compiler include path
(so I’m doing, e.g. #include <gr_block.h>, and not #include
<gnuradio/gr_block.h>), I need to make sure I also (and always!) have
$prefix/include in my compiler path - which if I didn’t install to a
standard location (e.g. I’m installing to somewhere in my $HOME for
keeping multiple versions installed simultaneously, or some other
equally odd-ball, but entirely probably situation), my require some
coaxing to get happen, since cmake will otherwise point to the normal
system includes + $HOME//include/gnuradio, and not to
$HOME//include. Doing something like #include
<…/gnuradio/config.h> just seems ugly to me - although presumably it
would work.

Anyways - what I’m getting around to suggesting, is that the
exported config.h should probably be renamed to ensure we never
collided with an OOT’s internal config.h - making it
$prefix/include/gnuradio/gr_config.h makes the most sense to me, but
perhaps other folks have strong feelings about this one way or the
other.
Also - since we are encouraging people to use it now, and it’s
already in public releases, the only place this should change would be
in next. As next is getting closer to release, this is presumably the
best time to discuss/decide this sort of thing, and I’m sure we’re all
looking forward to another API-breaking change in ‘next’.

Just my $0.02,
Doug

–
Doug G.
[email protected]

2

On Sat, Mar 30, 2013 at 12:52 PM, Douglas G.
[email protected] wrote:

horror of horrors - I’m building an OOT module (or GR-based
never be a problem. However, because the canonical OOT cmake setup
<…/gnuradio/config.h> just seems ugly to me - although presumably it
in next. As next is getting closer to release, this is presumably the
best time to discuss/decide this sort of thing, and I’m sure we’re all
looking forward to another API-breaking change in ‘next’.

Just my $0.02,
Doug

–
Doug G.
[email protected]

Hey Doug,

Yes, this is the perfect time to bring this up. Let me explain part of
our plans for 3.7 as I don’t know how much we’ve communicated to
everyone.

One of the longstanding issues and things we are going to change is
that we plan on moving all include paths to point to #include
<gnuradio/header.h>. It’s a pretty standard way of including files for
most projects these days, and it really only makes sense. Especially
now that we are dropping file name prefixes of ‘gr_’, so the
likelihood of a name collision becomes much higher.

So that said, the package config files you would use to discover GNU
Radio and it’s locations would point you to “$prefix/include” and not
“$prefix/include/gnuradio”, so you would be forced to use this model.
Also, you would always have that as part of your include path in your
project (or you’ve set it up incorrectly).

So what that means is that we would use “#include
<gnuradio/config.h>”. That was always my intent when we started using
and shipping config.h. I knew at that time that it was a confusing
name, but it is the standard name for these types of things. It means
we can use it for both internal to GNU Radio and for external
projects.

But, I’m not opposed to renaming it. “gr_config.h” would be
acceptable. Even just “gnuradio.h”, although that name probably
implies that it does a lot more. I once argued with Eric about
creating a gnuradio.h that automatically included all block header
files so we didn’t need to include them individually for C++ projects;
I now think he was right (as he usually was, damn him) since it’s a
bit of a maintenance nightmare. But anyway, a gnuradio.h file seems to
imply that it would do a lot more than just declare a few defines.

Does anyone else have strong opinions on this subject? Or will the
path to using the <gnuradio/header.h> model be enough?

Thanks for bringing this up.

Tom

3

Hi,

Does anyone else have strong opinions on this subject? Or will the
path to using the <gnuradio/header.h> model be enough?

Personally I think that <gnuradio/header.h> is the right way to go. Of
course that also mean that the pkg-config .pc must have
-I${PREFIX}/include rather than -I${PREFIX}/include/gnuradio or else
that defeats the point.

But the problem I see is that 3.7 is not there yet and as of now, the
“config.h” is broken and that should be fixed … it has also caused
issue in some osmocom code because of name conflicts.

If in 3.7 we’re going to have to change include <gr_xxx.h> to include
<gnuradio/xxx.h> anyway, then using gr_config.h now seems appropriate.

Cheers,

Sylvain
4

On Sun, Mar 31, 2013 at 3:46 AM, Sylvain M. [email protected]
wrote:

Hi,

Does anyone else have strong opinions on this subject? Or will the
path to using the <gnuradio/header.h> model be enough?

Personally I think that <gnuradio/header.h> is the right way to go. Of
course that also mean that the pkg-config .pc must have
-I${PREFIX}/include rather than -I${PREFIX}/include/gnuradio or else
that defeats the point.

Hi Sylvain,
Yes, this change has already been made for the next branch / 3.7. One
of the stages is to convert all includes into this structure and make
sure the pc file properly reflects that (it does now but also has
-I${prefix}/include/gnuradio for easy compatibility right now; we’re
going to remove that when we’re ready).

But the problem I see is that 3.7 is not there yet and as of now, the
“config.h” is broken and that should be fixed … it has also caused
issue in some osmocom code because of name conflicts.

If in 3.7 we’re going to have to change include <gr_xxx.h> to include
<gnuradio/xxx.h> anyway, then using gr_config.h now seems appropriate.

Cheers,

Sylvain

Yes, I agree with you. We always hate to change things like this on
master, but the fact that we might be bringing in the file as
“#include <config.h>” right now is, as you say, broken.

I would follow your recommendation and change config.h to gr_config.h
for 3.6 as it’s probably not used widely right now and those using it
are most likely people listening to this conversation. I’m going to
bounce this off Johnathan and make a decision later today.

Thanks,
Tom