That CMake code reads nicely; a little more verbose than desirable, but
whatever works as it's an OOT & not GR proper. You -might- be able to do
"find_package(gnuradio-myoot)" ... might work or not depending on whether
.cmake and/or .pc file were installed by the OOT.
Wouldn't it be nice if you could instead just do "find_package(gnuradio
COMPONENTS runtime myoot)" and then various return variables would be set
that you could use for the includes and linking? There's an open request
for something like this from, I believe, Mait. I don't think it's made
progress, but it's something I'd love to see! It would mean, of course,
than you can have only 1 version of "myoot" installed at a time. IMHO a
small price to pay for the convenience!
Food for thought... - MLD
On Tue, Nov 5, 2019 at 4:02 PM Morman, Joshua <jmor...@perspectalabs.com>
wrote:
> Michael,
>
>
> Thank you for the response. Here is what I ended up doing:
>
>
> If I have gr-myoot that I want to reference from gr-anotheroot
>
>
> In gr-anotheroot/cmake/modules, create FindMyoot.cmake, which should look
> something like:
>
>
> ########################################################
>
> find_package(PkgConfig)
> pkg_check_modules(PC_GNURADIO_RUNTIME gnuradio-runtime)
>
> find_path(MYOOT_INCLUDE_DIR myoot/one_of_the_header_files.h
> HINTS ${PC_GNURADIO_RUNTIME_INCLUDEDIR}
> ${PC_GNURADIO_RUNTIME_INCLUDE_DIRS}
> PATH_SUFFIXES myoot )
>
> find_library(MYOOT_LIBRARY NAMES gnuradio-myoot
> HINTS ${PC_GNURADIO_RUNTIME_LIBDIR}
> ${PC_GNURADIO_RUNTIME_LIBRARY_DIRS} )
>
> include(FindPackageHandleStandardArgs)
> # handle the QUIETLY and REQUIRED arguments and set MYOOT_FOUND to TRUE
> # if all listed variables are TRUE
> find_package_handle_standard_args(Myoot DEFAULT_MSG
> MYOOT_LIBRARY MYOOT_INCLUDE_DIR)
>
> mark_as_advanced(MYOOT_INCLUDE_DIR MYOOT_LIBRARY )
>
> set(MYOOT_LIBRARIES ${MYOOT_LIBRARY} )
> set(MYOOT_INCLUDE_DIRS ${MYOOT_INCLUDE_DIR} )
> ########################################################
>
> I'm sure there are better ways to do this, but this did the trick quick
> and dirty. It looks like some other oots have .pc files installed which
> help with the process, but that doesn't look to be standard.
>
>
>
> Josh
>
> ------------------------------
> *From:* Michael Dickens <michael.dick...@ettus.com>
> *Sent:* Tuesday, November 5, 2019 2:14 PM
> *To:* Morman, Joshua
> *Cc:* discuss-gnuradio@gnu.org
> *Subject:* [EXTERNAL] Re: Using function from OOT in another OOT
>
> Hi Josh - I don't think there's a standard way to do this. -Most- OOTs
> install cmake scripts that can be used to "find" them, if you can determine
> the correct "find" name (might be "gr-OOT" or just "OOT", where 'OOT' is
> the name of the OOT module). Once found, you can then use either the target
> or returned variables (OOT_INCLUDE_DIRS, OOT_LIBRARIES most likely) to find
> the API and link against the ABI. Nothing special, but generic enough that
> it should work on different OSs & GR installs. Hope this is useful! - MLD
>
> On Tue, Nov 5, 2019 at 1:42 PM Morman, Joshua <jmor...@perspectalabs.com>
> wrote:
>
>> Is there a prescribed method for including functions from one OOT in
>> another OOT (c++ code)?
>>
>>
>> I could probably figure out how to do it in cmake, but is there some
>> magical cmake find functions that already exist for OOTs to set the
>> INCLUDE and LIBRARY variables relative to the GR prefix installation?
>>
>>
>> Thanks,
>>
>> Josh
>>
>
>
> --
> Michael Dickens
> Ettus Research Technical Support
> Email: supp...@ettus.com
> Web: https://ettus.com/ [ettus.com]
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__ettus.com_&d=DwMFaQ&c=YC-d702opsuYKpiO2Bmlzg&r=-OttVOCFItYdAESKCAf54UYYCHv8xssKxCxab-nx5UA&m=Ef8z0W0VV0FJhO2Gi19L14SAnThIphzjnqAAgdGLv5k&s=2fWh96T2ZIoLHJl2x4asongRKo1Yc2zpJZUxPNTtzfc&e=>
>
--
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/
