discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] GnuradioConfig.cmake on master


From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] GnuradioConfig.cmake on master
Date: Fri, 10 May 2013 10:20:04 -0400

On Thu, May 9, 2013 at 12:58 PM, Sean Nowlan
<address@hidden> wrote:
> On 05/09/2013 12:28 PM, Tom Rondeau wrote:
>>
>> 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.
>>
> I probably had some cached Cmake stuff that was getting in the way. When
> purged the build directory it worked.

Great!


>>>> See the bottom of the main page in the Doxygen manual (you'll have to
>>>> build it yourself). It explains it a bit more. Since
>>>> GnuradioConfig.cmake is
>>>> installed by GNU Radio, there's no need to put it into modtool; you just
>>>> have to use it in modtool if you want it's functionality. Right now, by
>>>> default, projects built with modtool only look for libgnuradio-runtime,
>>>> just
>>>> to make sure it's there. If you need the more complicated functionality
>>>> the
>>>> GnuradioConfig provides, you can easily add that line to the CmakeLists
>>>> file
>>>> yourself to search for the necessary components as well as the API
>>>> compatible version you need for your OOT project. So it doesn't really
>>>> need
>>>> to be part of 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."
>>
>> 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
>
>
> 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.

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



reply via email to

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