Best way to share/install hierarchical grc blocks?

GNU Radio
1

Hi,

I’m trying to figure out a good way to distribute some custom heir
blocks that go with my low-level custom blocks I’ve written. The issue
is that the xml and py files are both generated into my ~/.grc_gnuradio
directory, and the xml files contain lines like

execfile("/Users/myname/.grc_gnuradio/file.py")

which obviously is not distributable. (Those lines get generated into
any grc output files that use the block, so editing it at the point of
use is not much of a solution.)

The obvious answer is to edit that line by hand, but the next problem is
that I don’t even know where the gnuradio directory is for other people
(could be a different host platform, for instance). There also seems to
be no “execfile search path” concept, which would allow me to perform
some light editing of the xml file to remove the absolute path. So how
do people share their created hierarchical blocks?

(I suppose the answer could be “give them my .grc_gnuradio files and
tell them to edit all of the references”, but that doesn’t make for a
nice delivery.)

Don Porges
Lyric Labs/Analog Devices

2

On Thu, Mar 15, 2012 at 3:28 PM, Porges, Donald
[email protected]wrote:

grc output files that use the block, so editing it at the point of use is
them to edit all of the references", but that doesn’t make for a nice
delivery.)

Don Porges
Lyric Labs/Analog Devices

Does this help?

http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioCompanion#Installing-the-XML-Block-Definition

Tom

3

On 03/15/2012 02:14 PM, Porges, Donald wrote:

I’m trying to figure out a good way to distribute some custom heir
blocks that go with my low-level custom blocks I’ve written. The
issue is that the xml and py files are both generated into my
~/.grc_gnuradio directory, and the xml files contain lines like

execfile(“/Users/myname/.grc_gnuradio/file.py”)

Well, this is my doing, and I can’t say I love it. The idea was that
user didnt need to set their PYTHONPATH.

This would be a code change, but it could be better replaced by “from
file import class”. Here is the relevant line:
http://gnuradio.org/cgit/gnuradio.git/tree/grc/python/convert_hier.py#n39

I guess the additional thing is that the generated client code also
append os.path.join(os.expanduser(‘~’), ‘.grc_gnuradio’) to the
sys.path, so the imports would still work when the PYTHONPATH env var
isnt set.

-josh

4

On Thu, Mar 15, 2012 at 5:14 PM, Porges, Donald
[email protected]wrote:

I’ve read that, and it only applies to telling grc where the xml is for a
non-hierarchical block; that is, it solves a build-time problem, not a
runtime problem.

Oh, I see. I wasn’t reading closely enough. So generally, I’ve just used
the original XML file that you create and save yourself in whatever
directory you’re working in. You can pass this along and then others
would
open up gnuradio-companion, open this file, and build it locally
themselves.

But that still feels kludgy, doesn’t it? I’ve always ignored the .xml
file
you’re talking about, though. You could just pass around your original
grc
file and the py file that’s created. There’s someone who has also
created a
grcc (I think that’s the name they gave it) that allows you to take a
grc
file and compile it into a Python file by running this on the command
line.
We have talked about getting it into GNU Radio, but I need to track it
down
again. This might help, so now you just pass around your .grc file and
the
other people can more easily just run grcc against it to create the hier
block. I assume that when grcc would “compile” a hierarchical block that
it
would end up in the user’s ~/.grc_gnuradio directory just like if you
created it in gnuradio-companion.

Anyone have more info on this tool?

Tom

5

I’ve read that, and it only applies to telling grc where the xml is for
a non-hierarchical block; that is, it solves a build-time problem, not a
runtime problem.

On Mar 15, 2012, at 5:07 PM, Tom R. wrote:

On Thu, Mar 15, 2012 at 3:28 PM, Porges, Donald
<[email protected]mailto:[email protected]> wrote:
Hi,

I’m trying to figure out a good way to distribute some custom heir
blocks that go with my low-level custom blocks I’ve written. The issue
is that the xml and py files are both generated into my ~/.grc_gnuradio
directory, and the xml files contain lines like

execfile(“/Users/myname/.grc_gnuradio/file.py”)

which obviously is not distributable. (Those lines get generated into
any grc output files that use the block, so editing it at the point of
use is not much of a solution.)

The obvious answer is to edit that line by hand, but the next problem is
that I don’t even know where the gnuradio directory is for other people
(could be a different host platform, for instance). There also seems to
be no “execfile search path” concept, which would allow me to perform
some light editing of the xml file to remove the absolute path. So how
do people share their created hierarchical blocks?

(I suppose the answer could be “give them my .grc_gnuradio files and
tell them to edit all of the references”, but that doesn’t make for a
nice delivery.)

Don Porges
Lyric Labs/Analog Devices

Does this help?

http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioCompanion#Installing-the-XML-Block-Definition

Tom

6

Incidentally, to close out (for now) this line of conversation: I
decided indeed to go with editing the files with a script at
build/install time. For anyone else who wants to go down this path,
note that you must process 3 kinds of files:

– the .py.xml file for the hier block
– the .py file for any higher-level hier block that uses those blocks
– the .py file for any sample code that uses those blocks.

Thanks again to those who answered; I decided to go this route because
I can do it now, without needed to modify any tools (which didn’t seem
100% simple, which is why it hasn’t already been done).

7

I need to think about some of these ideas, but wanted to thank both of
you for the replies. My inclination right now is to install the .py.xml
into the grc installation-wide “blocks” directory, and the .py into the
correct gr subdirectory for my additions,
and then have an install-time step that edits the .py.xml so that the
execfile line points directly to that .py file. (I’m presuming that a
hier-block .py.xml file, once installed in the “normal” place, won’t
try to mess with ~/.grc_gnuradio, but I haven’t tried it yet.) I’m
using the how-to-write-a-block framework, so the python install
directory would be available to the Makefile in the build/grc directory
(which right now has no build actions since it just is there for “make
install”)

Incidentally, I tried changing the execfile into “from dir import
class”, but it seemed to not quite produce the same state, in that I was
not able to instantiate the module after that. But I may have just done
something wrong and given up too early.

On Mar 15, 2012, at 5:07 PM, Tom R. wrote:

On Thu, Mar 15, 2012 at 3:28 PM, Porges, Donald
<[email protected]mailto:[email protected]> wrote:
Hi,

I’m trying to figure out a good way to distribute some custom heir
blocks that go with my low-level custom blocks I’ve written. The issue
is that the xml and py files are both generated into my ~/.grc_gnuradio
directory, and the xml files contain lines like

execfile(“/Users/myname/.grc_gnuradio/file.py”)

which obviously is not distributable. (Those lines get generated into
any grc output files that use the block, so editing it at the point of
use is not much of a solution.)

The obvious answer is to edit that line by hand, but the next problem is
that I don’t even know where the gnuradio directory is for other people
(could be a different host platform, for instance). There also seems to
be no “execfile search path” concept, which would allow me to perform
some light editing of the xml file to remove the absolute path. So how
do people share their created hierarchical blocks?

(I suppose the answer could be “give them my .grc_gnuradio files and
tell them to edit all of the references”, but that doesn’t make for a
nice delivery.)

Don Porges
Lyric Labs/Analog Devices

Does this help?

http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioCompanion#Installing-the-XML-Block-Definition

Tom