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 >
