|Subject:||Re: [Discuss-gnuradio] How make a *.t block|
|Date:||Wed, 06 May 2015 08:35:36 +0200|
|User-agent:||Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0|
.t is for template, and at build time, the full implementations of these blocks are generated, and then compiled.
gr_modtool doesn't support that. However, the magic involved is not really of the overly complex kind:
* CMake writes a python program to do the substitutions
* In the CMakeLists.txt, that program is applied to all templates
* the resulting headers/C++ implementations are added to the list of files that need to be built and linked together
For reference, open up gr-blocks/lib/CMakeLists.txt, and have a look at all the *EXPAND* lines; you'll find the matching CMake routines in cmake/Modules/GrMiscUtils.cmake.
SWIG *should* handle the templates well by now, but might be exceptionally hard to tell it what to wrap (and what not). Also, the classical templating problems arise: Unless you *use* a specific template specialization, it never gets built -- and in the end, SWIG might try to wrap things that aren't there; maybe
http://www.swig.org/Doc1.3/SWIGPlus.html#SWIGPlus_nn30 has an approach that might work for you:
/* Instantiate a few different versions of the template */
so in your case, maybe something like
I haven't tested this for a while, though.
The reason there's these expanding templates instead of proper C++ templates in GNU Radio is for historical reasons (SWIG didn't use to handle templates at all), and for the reason that a block typically doesn't care about the data that it's being handed at all (e.g. it just memcpy from A to B), in which case a simple passing of the item size as parameter is sufficient, or it cares a lot about the type, and needs a different specialization for basically almost all implementations (e.g. multiplying two floats is optimized differently than multiplying complexes). So the reasonable thing to ask here is: Does your block fit in either of these two categories?
On 05/06/2015 12:47 AM, marco Ribero wrote:
|[Prev in Thread]||Current Thread||[Next in Thread]|