On Sat, Mar 30, 2013 at 9:42 AM, Tom Rondeau <t...@trondeau.com> 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 doug.gei...@bioradiation.net _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
