Hi Ryan, Thanks for the response. Yep, it just did not make sense. Almost as if the build was made to test CMAKE_INSTALL_PREFIX="". Thanks for GR_PREFIX. That was something I was trying to guess. Not an easy thing to find - does not get many mentions on the web :)
Can't properly test any more since I removed the package and built GR 3.9 from source. I had a few other issues later on when trying to create/build OOTs, and having already had issues with the package, I decided to start clean. Therefore build from source. I'll raise an issue. I find it interesting that it was not encountered (or maybe reported) before. Makes me wonder if I did something wrong, but not sure what it would be. Thanks again Boris On Wed, 19 May 2021 at 05:12, Ryan Volz <ryan.v...@gmail.com> wrote: > Hi Boris, > > On 5/16/21 7:20 PM, Boris Marjanovic wrote: > > I understand that the original issue was resolved. But I have the same > problem with a different setup. > > > > I installed (did ot build it myself) gnuradio 3.9. on Ubuntu 20.02.2 > using ppa:gnuradio/gnuradio-releases with no issues. The companion seems to > work fine. Similar to above, though, I can not create new module using > modtool 'out of the box'. > > Running gr_modtool fails > > $ gr_modtool newmod temp > > ModToolException: Could not find gr-newmod source dir. > > Interestingly, running config info returns prefix '/.' > > $ gnuradio-config-info --prefix > > /. > > This would explain why gr.prefix() which is imported via 'form gnuradio > import gr' returns the string that creates an incorrect path to search for > templates and later to find clang-format.conf file. > > This is definitely strange and points to a problem with the package build > or with the prefix handling in gnuradio-runtime. I would expect > `gnuradio-config-info --prefix` to return '/usr' or '/usr/.' in this case. > Looking at the PPA package build log didn't turn up anything questionable > to me, so I'm at a loss. > > > > > I think there might be an issue with the installation package. As far as > I can tell, (I'm 'advanced beginner' in python, so nothing is certain) that > comes from shared library /usr/lib/python3/dist-packages/gnuradio/gr/ > gr_python.cpython-38-x86_64-linux-gnu.so < > http://gr_python.cpython-38-x86_64-linux-gnu.so> > > Having the correct path in /etc/gnuradio/conf.d/modtool.conf makes no > difference. I copied the file to ~/.gnuradio/config.conf but still did not > work. For some reason it seems these files are not checked for the path. > > It seems gr_modtool was re-written in 3.9 (maybe 3.8) to use click. The > code shows there is now a parameter for a newmod option 'srcdir'. If srcdir > is provided, the module seems to be created, > > $ gr_modtool newmod --srcdir > /usr/share/gnuradio/modtool/templates/gr-newmod temp > > Creating out-of-tree module in ./gr-temp... > > Failed to copy .clang-format: [Errno 2] No such file or directory: > '/./share/gnuradio/clang-format.conf' > > Done. > > Use 'gr_modtool add' to add a new block to this currently empty module. > > > > Note that the srcdir provided in the command is the same as the value in > the config file. There is still a failure because file clang-format.conf > can not be found. The reason is the same as before - gr.prefix() returns > incorrect value. But it seems to be 'warning level' since the module > scaffolding seems to be in place and blocks can be added. I have not tried > compiling them yet though. > > The workaround (would not call it a fix) is to modify lines creating the > path in newmod.py files (under both cli and core directory) in your > gnuradio python installation > > It would be good if someone more familiar with the system could check if > this makes sense. > > If so, it would be nice to patch the library. I'm not sure if there is > an environment variable that would override the prefix as used by the > library. > > You can use the GR_PREFIX environment variable to override the prefix that > it would use by default. So `export GR_PREFIX=/usr` would probably work for > you. But again, that shouldn't be necessary. > > > > > Apologies for the length of the email. As I said, the original problem > was resolved but maybe this can help someone installing 3.9 without > building from source. > > > > > > I'm going to suggest that you file a bug on the GNU Radio GitHub so that > the developers can track it. (The bug being that the returned prefix is not > what it should be, pointing to a packaging or library problem. In this > case, gr-modtool is just a casualty.) Hopefully that will get some more > eyes on it and someone will be able to figure out what is happening. > > Cheers, > Ryan > >
