N_DIR a relative path? I'm taking Andrej into CC, because he
> did a lot of the actual "modern CMake" conversion and is back home :)
>
> Best regards,
> Marcus
> On Tue, 2019-05-21 at 14:34 -0400, Toby Flynn wrote:
> > Marcus,
> > I think I have found the issu
will point to
the relative path only of GR_PYTHON_DIR within the CMake process, and I
think that is what is needed to correctly fix the issue. This may show up
because the installed path is /usr/lib/... on the sysroot and not an actual
PREFIX.
Thanks
Toby
On Mon, May 20, 2019 at 1:44 PM Toby Flynn
wrote
think it's an
> issue in the triangle between CMake, CMake instructing SWIG and
> detecting the right Python libs along the way.
>
> Anyway, I'll take a minute to literally parse your email :)
>
> Thanks!
> Marcus
>
> On Mon, 2019-05-20 at 09:09 -0400, Toby Flynn wrote:
> > M
lly doubt it's a CMake issue; to be precise, I think it's an
> issue in the triangle between CMake, CMake instructing SWIG and
> detecting the right Python libs along the way.
>
> Anyway, I'll take a minute to literally parse your email :)
>
> Thanks!
> Marcus
>
> On Mon, 2
wrote:
> Hi Toby,
>
> I don't really doubt it's a CMake issue; to be precise, I think it's an
> issue in the triangle between CMake, CMake instructing SWIG and
> detecting the right Python libs along the way.
>
> Anyway, I'll take a minute to literally parse your email :)
&g
ge is that the old CMake
> constructs we used to employ in GNU Radio have been replaced by more
> modern CMake patterns, which especially means that the notion of
> component dependencies and hence install targets has changed.
>
> Best regards,
> Marcus
>
> On Fri, 2019-05-17 a
be highly
> appreciated. One of the main reasons of breakage is that the old CMake
> constructs we used to employ in GNU Radio have been replaced by more
> modern CMake patterns, which especially means that the notion of
> component dependencies and hence install targets has changed.
>
>
I am attempting to install OOT modules using a Yocto/Openembedded
enviroment and the latest GNURadio 3.8. This process was working before
the latest cmake changes to 3.8 were incorporated. I am now having issues
with the cross-complitaion. I have tracked the issue down to a file I
believe is
