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

[Douglas Geiger]

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