Re: GNU Radio 3.9 gr_modtool problem

[Boris Marjanovic]

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.volz@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