I've done some debugging in gnuradio-runtime and made the following observations:
- When not connecting the message ports in my example, gnuradio-runtime flattens the hier block, so that only the child blocks remain in the flattened flowgraph. This behavior is correct.
- Connecting the message port of the hier_block2 results in the flattening process to only partly succeed. The flatten_aux function fails to determine that the message ports of the hier_block2 are hierarchical, and therefore the message ports (and hier block itself) remain in the flattened graph as normal connections instead of being resolved. The output ports of the hier block are furthermore disconnected (I'm not sure why exactly) which causes the flowgraph validation to fail.
- Tracing back why flatten_aux determines that the message ports are not hierarchical, I found the following lines in hier_block2_detail.cc:
--
bool hier_out = (d_owner == src.
get()) && src->
message_port_is_hier_out(srcport);;
bool hier_in = (d_owner == dst.
get()) && dst->
message_port_is_hier_in(dstport);
--
At first it seemed to me that this was a small error because d_owner is always top_block for the connections of my hier_block2 and therefore the _expression_ will evaluate to false. Changing these lines to the following resolves the problem I described above:
---
bool hier_out = (d_owner != src.
get()) && src->
message_port_is_hier_out(srcport);
bool hier_in = (d_owner != dst.
get()) && dst->
message_port_is_hier_in(dstport);
---
Now, the ports are correctly determined to be hierarchical, and flatten_aux flattens the hier block in the example I provided (I can also successfully connect a debug_message() block residing within the hier_block2 to the message_prober). However, one QA test related to the hier block now fails, so this is probably not an ideal approach and I need to do some further digging to resolve this matter.