[Top][All Lists]

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

Re: [Discuss-gnuradio] On config.h (was Check for gr-ctrlport)

From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] On config.h (was Check for gr-ctrlport)
Date: Sat, 30 Mar 2013 15:00:45 -0400

On Sat, Mar 30, 2013 at 12:52 PM, Douglas Geiger
<address@hidden> wrote:
> On Sat, Mar 30, 2013 at 9:42 AM, Tom Rondeau <address@hidden> 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/<blah>/include/gnuradio, and not to
> $HOME/<blah>/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 Geiger
> address@hidden

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

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

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.


reply via email to

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