[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] grc block definition directories
From: |
Josh Blum |
Subject: |
Re: [Discuss-gnuradio] grc block definition directories |
Date: |
Sat, 11 Jun 2011 19:27:46 -0700 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 |
On 06/11/2011 07:16 PM, Achilleas Anastasopoulos 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. :-)
> 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 <category> 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