GnuradioConfig.cmake not working properly?

GNU Radio
#1

Hi,

I’m having a couple of issues when trying to switch from
FindGnuradioRuntime to GnuradioConfig

  1. GNURADIO_ALL_INCLUDE_DIRS (and possibly GNURADIO_ALL_LIBRARIES)
    don’t seem to be propagated propely.

I have ${GNURADIO_ALL_INCLUDE_DIRS} in include_directories(…) in the
top level CMakeFile but the path is not added and CMakeCache.txt has
no trace of that variable either.

If you install in /usr/local you might not notice … but if you use a
prefixed install, the OOT module don’t find the includes

  1. No GNURADIO_ALL_LIBRARY_DIRS to set in link_directories(…). I
    don’t really know if it’s needed since it doesn’t even get to that
    point due to the include issue above

  2. Doesn’t follow all the libraries requested by the .pc
    For ex, the .pc for gnuradio-runtime asks for -lgnuradio-runtime
    and -lgnuradio-pmt … so it should automatically put both in
    GNURADIO_RUNTIME_LIBRARIES but it doesn’t.
    This causes issues for OSX for example. When using
    FindGnuradioRuntime, I had to ship my own patched version that
    followed all the libs. It’s either that, or I need to specify ‘PMT’ as
    a required component even though I don’t use it … (which then embeds
    some GR interdependency knowledge in my own OOT projects …)
    GnuradioConfig

So am I doing something wrong that I get all theses issues ? Or isn’t
anyone using GnuradioConfig ?
(I found myself wanting to use it because I now need the FFT
components linked in and didn’t want to write a FindGnuradioFFT.cmake
…)

Cheers,

Sylvain
#2

I’m having a couple of issues when trying to switch from
FindGnuradioRuntime to GnuradioConfig

Attached a patch that deals with issue 1 & 3. Issue 2 doesn’t seem to
be an issue since ALL_LIBRARIES has absolute path in it.

Cheers,

Sylvain
#3

On Sun, Nov 10, 2013 at 11:56 AM, Sylvain M. [email protected]
wrote:

I’m having a couple of issues when trying to switch from
FindGnuradioRuntime to GnuradioConfig

Attached a patch that deals with issue 1 & 3. Issue 2 doesn’t seem to
be an issue since ALL_LIBRARIES has absolute path in it.

Cheers,

Sylvain

Thanks, Sylvain. I was actually working on a tutorial for gnuradio.org
to describe the use of GnuradioConfig when I noticed the exact same
issue with the ALL variables. Your patch did the trick and has been
pushed.

Tom

#4

Hi Tom,

Thanks, Sylvain. I was actually working on a tutorial for gnuradio.org
to describe the use of GnuradioConfig when I noticed the exact same
issue with the ALL variables. Your patch did the trick and has been
pushed.

Great.

I updated gr-fosphor to use the new stuff. But for now I use a
“bundled” version (renamed FindGnuradio inside the OOT so that it has
precedence over the system-wide GnuradioConfig) Once 3.7.3 has been
out for some time and I can reasonably expect people to be up to date,
I’ll remove it and let the system one do the job.

Cheers,

Sylvain

PS: BTW, in the tutorial, maye it should be “find_package(Gnuradio
3.7.2 REQUIRED)” or it will just be a warning but still try (and fail)
to build …

#5

On Tue, Nov 12, 2013 at 06:54:43PM +0100, Sylvain M. wrote:

The attached patch fixes that by re-declaring the variable in the parent scope.

This fixes the gr-osmosdr build for me.
@Martin : could you give it a shot to check it fixes it for you too ?

Yep, this fixes gr-osmosdr on my side.

MB

–
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin B.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

#6

Hi Tom,

I’m afraid my patch broke something :frowning: gr-osmosdr and probably some
other OOT projects that were using GnuradioConfig but without using
the ALL variable but using the individual ones.

Turns out that after the patch, GNURADIO_XXX_LIBRARIES is no longer
directly build from find_library, but from a custom foreach loop (to
build up the proper list)

But that also mean that it’s scope is not restricted to the function
and is not global and so not available elsewhere.

The attached patch fixes that by re-declaring the variable in the parent
scope.

This fixes the gr-osmosdr build for me.
@Martin : could you give it a shot to check it fixes it for you too ?

Cheers,

Sylvain
#7

On Tue, Nov 12, 2013 at 1:28 PM, Martin B. (CEL)
[email protected] wrote:

On Tue, Nov 12, 2013 at 06:54:43PM +0100, Sylvain M. wrote:

The attached patch fixes that by re-declaring the variable in the parent scope.

This fixes the gr-osmosdr build for me.
@Martin : could you give it a shot to check it fixes it for you too ?

Yep, this fixes gr-osmosdr on my side.

MB

Patches applied. I also updated the OOT tutorial to use REQUIRED and
gr-modtool now defaults to using the GnuradioConfig style checks with
REQUIRED as well.

Thanks!

Tom

#8

I think that needs to be applied to the maint branch as well: i.e.
Sylvain’s first patch got applied to both master and maint, but the fix
(second patch) only ended up on master.
Doug

#9

On Thu, Nov 14, 2013 at 12:25 PM, Douglas G.
[email protected] wrote:

I think that needs to be applied to the maint branch as well: i.e. Sylvain’s
first patch got applied to both master and maint, but the fix (second patch)
only ended up on master.
Doug

Thanks for catching that. Since I had done some other changes to how
GnuradioConfig is used, I thought I only put that on master. Fixed
now.

Tom