Josh,
Many thanks for your prompt reply and suggestions.
I have followed both of the porting guide documents, settling on the GRC 3.9
version install and using its particular gr_modtool variant for all OOT block
operations.
I am aware of the CMake modernisation changes through GRC 3.8, but confess to
not being a CMake expert!
However, my original 3.7.11 code uses FFT, added as a component together with
VOLK and VOLKGNSSDR. VOLKGNSSSDR has been included and both VOLK variants are
correctly notified in the CMake configure.
In the case of VOLKGNSSDR this required a separate find package in
/cmake/Modules/and ${VOLK_GNSSSDR_LIBRARIES} appended to target_link_libraries
as before.
Volk itself requires no special treatment other than profiling before use.
I will continue to check the detail.
David
From: Josh
Sent: Monday, August 17, 2020 11:45 AM
To: David Taylor (manx.net)
Cc: GNURadio Discussion List
Subject: Re: GRC version 3.9.0.0 git master (python 3.8.2) + OOT blocks
David,
I've found most of the time I get the "No module named ..." error it is due to
C++ linkage issues in setting up the CMake. There was a big jump in CMake
modernization from GR 3.7 to 3.8, so be sure to use gr_modtool (from 3.9) to
create a new module and copy your blocks in from there is usually the easiest
way. Porting guide is here:
https://wiki.gnuradio.org/index.php/GNU_Radio_3.8_OOT_Module_Porting_Guide and
here: https://wiki.gnuradio.org/index.php/GNU_Radio_3.9_OOT_Module_Porting_Guide
the one that usually gets me and causes the ModuleNotFoundError is this
https://wiki.gnuradio.org/index.php/GNU_Radio_3.8_OOT_Module_Porting_Guide#GNU_Radio_Components
Does your library reference any GR modules, or any other external libraries?
Josh
On Mon, Aug 17, 2020 at 3:58 AM David Taylor (manx.net) <drtay...@manx.net>
wrote:
Hi,
I have been developing a number of direct spread spectrum OOT blocks as part
of a research project.
Working blocks were originally developed using GRC 3.7.11, however I wish to
move forward and have installed and persevered so far with GRC 3.9 from the
master branch.
The GRC, UHD, CMAKE (3.16) pybind11 (2.4.3) and other dependencies have been
installed and build correctly.
I have chosen to migrate the (3.7.11) C++ blocks and for completeness of the
build process checking, have included a simple python OOT.
The C++ to python code binding, make and install under Ubuntu 20.04 all work
and the new blocks import correctly to flow-graph using modified .yml
descriptors.
1). GRC 9.0 works standalone from git-master install and with the UHD, in my
case a B210.
2). OOT blocks including the aforementioned python OOT block all fail at
import. In my case ModuleNotFoundError: No module named ‘development’
i.e. failure of ‘import development’ in the flow-graph python script
3). I have tried and retained the library workarounds with PYTHONPATH and
LD_LIBRARY_PATH, but these now seem irrelevant as the GRC basically loads and
runs.
4). I have looked at the gr_modtool __init_.py file for indicators as to why
both python and C++ blocks (using python bindings) both fail.
The inability of python 3.8.2 in my case to resolve the import is clearly at
its core.
5). The OOT GRC blocks themselves import correctly into the flow-graph
produce error free python script and all have relatively primitive interfaces.
Many thanks,
David Taylor
