# Handling Hier Blocks in Build Process

**URL:** <https://www.ruby-forum.com/t/handling-hier-blocks-in-build-process/231381>\
**Category:** GNU Radio\
**Created:** [August 5, 2014, 7:07pm UTC](https://www.ruby-forum.com/t/handling-hier-blocks-in-build-process/231381 "2014-08-05T19:07:59Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![addis\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@addis\_a](https://www.ruby-forum.com/u/addis_a)\
**Post date:** [August 5, 2014, 7:07pm UTC](https://www.ruby-forum.com/t/handling-hier-blocks-in-build-process/231381/1 "2014-08-05T19:07:59Z")

</div>

I’d like to keep a large number of hier blocks organized in the apps  
folder (which may not be standard practice for GR). Ideally, I’d like  
to  
maintain _only_ the GRC files with version control, but allow the build  
system to:

- Compile the .grc files into python/xml files.
- Install the .py files into the same location as everything else so  
they show up in the OOT module’s namespace.
- Do the same for .xml files for access to GRC.
- If there were a way to get around manually adding the resulting .py  
file to **init**.py, that would be a nice-to-have feature so other  
developers can easily add hier blocks to the module’s namespace.

I was just wondering if someone could tell me if this was possible, has  
been done already, or might be an unreasonable thing to do for some  
reason. (before I waste an afternoon).

-John

---

<div class="post-metadata">

**Author:** ![jmaenpaa](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/9de053/32.png) [@jmaenpaa](https://www.ruby-forum.com/u/jmaenpaa)\
**Post date:** [August 5, 2014, 7:26pm UTC](https://www.ruby-forum.com/t/handling-hier-blocks-in-build-process/231381/2 "2014-08-05T19:26:25Z")

</div>

Hi John,

compiling things while building kind of makes sense 😉  
So, yes, this is doable.  
In general, you could add the generated python files to the python  
install\_list in the python/CMakeLists.txt, and have a hook in the  
grc/CMakeLists.txt that generates these, but that would break CMake’s  
compiling-source tree differentiation.

I’d suggest looking at cmake/Modules/GrPython.cmake of your OOT. You  
could have a function similar to GR\_PYTHON\_INSTALL that does essentially  
the same, but instead of just shebanging the python files and adding  
them to an installation target, it would create python using "grcc -d  
/python " and install that.

The **init** automatisation was a topic some weeks ago, I don’t know in  
which context, though. Yeah, there are python-magical ways to do that,  
but they can easily litter module namespaces and cause problem if that  
produces naming conflicts, which will not even be caught be QA (since  
that happens pre-install…).

Greetings,  
Marcus

---

<div class="post-metadata">

**Author:** ![jmaenpaa](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/9de053/32.png) [@jmaenpaa](https://www.ruby-forum.com/u/jmaenpaa)\
**Post date:** [August 5, 2014, 8:00pm UTC](https://www.ruby-forum.com/t/handling-hier-blocks-in-build-process/231381/3 "2014-08-05T20:00:57Z")

</div>

John,

in one of my OOTs I did just that; I had GRC hier blocks that were  
compiled using grcc when running ‘cmake’.

I put these lines into grc/CMakeLists.txt (I stored all the hier blocks  
in grc/):

# Make sure to add them in a non-dependent order

list(APPEND grc\_hier\_blocks  
file1.grc  
# etc. list all grcs here  
)

message(“Compiling GRC hier blocks…”)  
foreach(grc\_file ${grc\_hier\_blocks})  
message("Compiling " ${grc\_file})  
execute\_process(  
COMMAND grcc ${grc\_file}  
WORKING\_DIRECTORY ${CMAKE\_CURRENT\_SOURCE\_DIR}  
)  
endforeach(grc\_file ${grc\_hier\_blocks})

A bit of a hack, but did the trick.

M