|
From: | Marcus Müller |
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 |
Hi Marco, .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 */ %template(intList) List<int>; %template(doubleList) List<double>; so in your case, maybe something like %template(marco_block_cc) marco_block<gr_complex>; 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? Greetings, Marcus On 05/06/2015 12:47 AM, marco Ribero
wrote:
|
[Prev in Thread] | Current Thread | [Next in Thread] |