GnuradioConfig.cmake on master

GNU Radio
1

GnuradioConfig.cmake was recently added to master. It broke finding
gnuradio-digital include directories. The reason for the failure was the
following line:

112 GR_MODULE(DIGITAL gnuradio-digital digital/lfsr.h
gnuradio-digital)

The LFSR and most other gr-digital components haven’t been ported to 3.7
API on master branch, so digital/lfsr.h was not found. This change is a
band-aid:

112 GR_MODULE(DIGITAL gnuradio-digital
digital/ofdm_frame_equalizer_vcvc.h gnuradio-digital)

There may be other packages that aren’t found for similar reasons
(missing new-style/3.7 header format). I haven’t tried them all.

For everybody’s information, I got this to work in my out-of-tree
project by modifying my CMakeLists.txt file in the top-level project
directory:

Find gnuradio build dependencies

…

take a look at GnuradioConfig.cmake for the component names

set(GR_REQUIRED_COMPONENTS CORE ANALOG DIGITAL BLOCKS FFT FILTER)

this is installed on a system path; there’s no need to copy

GnuradioConfig.cmake

to your gr-/cmake/Modules directory

find_package(Gnuradio)
…

Setup the include and linker paths

include_directories(
…
#{GNURADIO_ALL_INCLUDE_DIRS}
…
)

link_directories(
…
#{GNURADIO_ALL_LIBRARIES}
…
)

I hope this new config method finds its way into gr-modtool!

2

On 05/09/2013 09:48 AM, Tom R. wrote:

Good catch, Sean, and thanks for the patch as well! Seems I can’t make
any changes without messing up between the master/next changes these
days… I’m making sure all of the components are searching for the
right headers in master and next.

Actually, I’m having trouble with the CORE component. Perhaps it’s
conflicting with the FindGnuradioCore.cmake module.

This works:
find_package(GnuradioCore)
set(GR_REQUIRED_COMPONENTS ANALOG DIGITAL BLOCKS FFT FILTER)
find_package(Gnuradio)

This doesn’t:
set(GR_REQUIRED_COMPONENTS CORE DIGITAL BLOCKS FFT FILTER)
find_package(Gnuradio)

“cmake …/” succeeds and finds both libgnuradio-core.so and includes in
/usr/local/include/gnuradio. However, when I run “make,” I get:
fatal error: gr_io_signature.h: No such file or directory

Somehow the include statements aren’t getting set correctly. I suppose I
need to keep find_package(GnuradioCore). If so, what’s the purpose of
setting CORE (or RUNTIME) in GR_REQUIRED_COMPONENTS?

modtool. Thanks! Tom
Ok. Although, I don’t think placing a couple of commented-out lines in
CMakeLists.txt would hurt, with a comment like, “to use GR components,
uncomment the following and set GR_REQUIRED_COMPONENTS to libraries you
want to link.”

Finally, it looks like it’s not necessary to set “include_directories”
to ${GNURADIO_ALL_INCLUDE_DIRS} and “link_directories” to
${GNURADIO_ALL_LIBRARIES}. Cmake is a colossal mystery to me…

3

On Thu, May 9, 2013 at 11:56 AM, Sean Nowlan
[email protected] wrote:

/usr/local/include/gnuradio. However, when I run “make,” I get:
fatal error: gr_io_signature.h: No such file or directory

Try it from a clean build directory. I just did and it worked fine.
gr_io_signature.h is in $prefix/include/gnuradio, so if that’s in your
include directories like you mentioned above, there should be no
reason for it not to find it.

Somehow the include statements aren’t getting set correctly. I suppose I
need to keep find_package(GnuradioCore). If so, what’s the purpose of
setting CORE (or RUNTIME) in GR_REQUIRED_COMPONENTS?

You should not need to use find_package(GnuradioCore) (or
GnuradioRuntime) if you are using the GnuradioConfig script. They are
duplications; the latter, if used, should replace any need for the
former in your cmake files.

Try it again. Like I said, I just tried it, and it worked fine for me.

Ok. Although, I don’t think placing a couple of commented-out lines in
CMakeLists.txt would hurt, with a comment like, “to use GR components,
uncomment the following and set GR_REQUIRED_COMPONENTS to libraries you want
to link.”

Sure, adding a comment is certainly appropriate here.

Finally, it looks like it’s not necessary to set “include_directories” to
${GNURADIO_ALL_INCLUDE_DIRS} and “link_directories” to
${GNURADIO_ALL_LIBRARIES}. Cmake is a colossal mystery to me…

Eh, probably not. But they could be easy convenience variables to use.
And it doesn’t hurt anything being there, even if unused.

Tom

4

On Thu, May 9, 2013 at 12:58 PM, Sean Nowlan
[email protected] wrote:

purged the build directory it worked.
Great!

file
to link."
Tom
Without this step I would get “undefined symbol” errors when trying to run
swigged blocks from Python. I don’t quite understand why I didn’t need to
include GNURADIO_BLOCKS_LIBRARIES or GNURADIO_FILTER_LIBRARIES, which these
modules also use. It may be something specific to my code/configuration;
it’s hard to tell.

So gnuradio-analog and gnuradio-digital both depend on gnuradio-blocks
and gnuradio-filter. So by linking to one of them, you are getting the
other libraries, too. And since they all sit under the same include
directory, if you get one, can get to them all.

(I think this makes sense).

Tom

5

On 05/09/2013 12:28 PM, Tom R. wrote:

/usr/local/include/gnuradio. However, when I run “make,” I get:
GnuradioRuntime) if you are using the GnuradioConfig script. They are
duplications; the latter, if used, should replace any need for the
former in your cmake files.

Try it again. Like I said, I just tried it, and it worked fine for me.

I probably had some cached Cmake stuff that was getting in the way. When
purged the build directory it worked.

And it doesn’t hurt anything being there, even if unused.

Tom

Last thing: I have a couple C++ hier blocks that use components from
gr-analog and gr-digital. I needed to add GNURADIO_ANALOG_LIBRARIES and
GNURADIO_DIGITAL_LIBRARIES to lib/CMakeLists.txt:

target_link_libraries(${Boost_LIBRARIES} ${GRUEL_LIBRARIES}
${GNURADIO_CORE_LIBRARIES} ${GNURADIO_DIGITAL_LIBRARIES}
${GNURADIO_ANALOG_LIBRARIES})

Without this step I would get “undefined symbol” errors when trying to
run swigged blocks from Python. I don’t quite understand why I didn’t
need to include GNURADIO_BLOCKS_LIBRARIES or GNURADIO_FILTER_LIBRARIES,
which these modules also use. It may be something specific to my
code/configuration; it’s hard to tell.

6

I probably had some cached Cmake stuff that was getting in the way. When
purged the build directory it worked.
Great!
I find that it’s really good practice to purge the build directory, when
you would otherwise just do a “make clean”.

–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium