Grc block definition directories

I notice that in some directories (eg, gr-noaa, gr-pager) there is a grc
subdirectory with the corresponding definitions, while for others the
definitions are in the grc/blocks directory.

Is there a specific reason for one vs the other option?
Which one is the preferred method?

I want to add some grc block defs for the newly added pccc
and sccc encoders/decoders in gr-trellis and would prefer a
grc subdir inside gr-trellis.
If there is no objection, can someone generate it and put inside the
already existing grc defs from grc/blocks.
I would do it myself but don’t know what other files need to be
changed…

BTW, I also see a discrepancy in the way swig files are handled:
some are in the swig subdir while other inside src/lib.
Is there a prefered way to do this as well???

thanks
Achilleas

On 06/11/2011 07:16 PM, Achilleas A. wrote:

I notice that in some directories (eg, gr-noaa, gr-pager) there is a grc
subdirectory with the corresponding definitions, while for others the
definitions are in the grc/blocks directory.

I did the cmake’ification of gr-trellis after those files were added and
I was just thinking about the organization. :slight_smile:

Is there a specific reason for one vs the other option?
Which one is the preferred method?

It seems that there is an unofficial new standard for a gnuradio
component (gr-uhd, gr-noaa, gr-audio, gr-pager, a few others…)

Its a flat directory structure inside the component directory.

/lib - for the cc files, private headers, and maybe public
/include - if you feel like separating the public header files
/swig - swig .i files and swig generation
/python - python modules and often the swig module’s init.py
/grc - grc xml block wrappers
/apps - apps installed into the runtime/bin directory
/examples - examples installed into the share directory

I want to add some grc block defs for the newly added pccc
and sccc encoders/decoders in gr-trellis and would prefer a
grc subdir inside gr-trellis.
If there is no objection, can someone generate it and put inside the
already existing grc defs from grc/blocks.
I would do it myself but don’t know what other files need to be changed…

  1. Move the .xml files from grc/blocks to gr-trellis/grc.
  2. Remove the entries from grc/blocks/Makefile.am
  3. Remove the entries from grc/blocks/block_tree.xml
    4a) Either add tags to the blocks
    4b) Or create a gr-trellis/grc/trellis_block_tree.xml

BTW, I also see a discrepancy in the way swig files are handled:
some are in the swig subdir while other inside src/lib.
Is there a prefered way to do this as well???

Its way easier to follow when its under its own swig directory and not
lib.

-Josh

On Sat, Jun 11, 2011 at 10:27 PM, Josh B. [email protected] wrote:

Is there a specific reason for one vs the other option?
Which one is the preferred method?

It seems that there is an unofficial new standard for a gnuradio
component (gr-uhd, gr-noaa, gr-audio, gr-pager, a few others…)

It’s not unofficial. It’s the official, if under-documented, new
directory
structure.

Tom

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs