[vtk-developers] New VTK wrapping tools and a function pointer typedef question...

[David Gobbi]

Hi David,

Everything is just a matter of having vtkParse.l recognize the macros.
 It is particularly easy in the cases where you just want the wrappers
to ignore certain macros.

After editing vtkParse.l, it has to be processed with flex to generate
lex.yy.c.  After that everything is automatic.  Most people don't have
lex/yacc installed (or not the right versions) so I'm happy that CMake
doesn't call them automatically.

A brief summary is included at the beginning of vtkParse.l, I use flex 2.5.35.

==
This file must be translated to C and modified to build everywhere.

Run flex like this:

  flex --nounput --nodefault -olex.yy.c vtkParse.l

Modify lex.yy.c:
  - convert tabs to spaces (8 spaces per tab)
  - remove extra space from end of lines
  - remove blank lines from end of file
  - change yy_n_chars declarations from "int yy_n_chars;" to
    "size_t yy_n_chars;" in both the yy_buffer_state structure
    and the global scope.
  - in YY_INPUT change "int n" to "size_t n"
  - compile with gcc and "-Wsign-compare", there should be no warnings
==

Hope this helps.

  David




On Thu, Nov 11, 2010 at 12:34 PM, David Cole <david.cole at kitware.com> wrote:
> Thanks... Yes, I need to keep these methods wrapped, as they are *the*
> way some folks extend VTK within the wrapped languages.
>
> VTK_CB_CC expands to "__stdcall" or the empty string depending on this
> block in vtkWin32Header.h:
>
> #ifndef VTK_CB_CC
> #ifdef _WIN32
> #define VTK_CB_CC __stdcall
> #else
> #define VTK_CB_CC
> #endif
> #endif
>
> The wrapper generator also does not like "__stdcall" explicitly spelled out.
>
> Does this mean that we cannot specify the calling convention
> explicitly for SetExecuteMethod (and friends) and still have it work
> from python? Must we accept the default calling convention?
>
> Perhaps the right tack for me would be to use the default calling
> convention, and adjust the other code that has to connect to this....
>
> If I do modify the vtkParse.l file, will things rebuild automatically,
> or do I need to run some tools manually to update other bits of the
> wrappers? (I can't remember that far back. :-)
>
> Thanks,
> David
>
>
> On Thu, Nov 11, 2010 at 2:19 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>> Hi David,
>>
>> The VTK build ignores the BTX/ETX markers everywhere except the
>> GUISupport directories, so to block those lines, you would have to use
>> this instead:
>>
>> #ifndef __WRAP__
>>
>> #endif
>>
>> The reason for the failure is that the wrappers do not expand macros,
>> so they have to be programmed to specifically recognize VTK_CB_CC.
>> This would go in vtkParse.l:
>>
>> "("[\t\n\r ]*"VTK_CB_CC"[\t\n\r ]*"*" { yylval.str = ""; return(LP); }
>>
>> It should be put in the same place as where the APIENTRY macros are
>> recognized.  This will keep the parser from choking.  Do you want to
>> use this typedef'd type in methods that will be wrapped in Tcl,
>> Python, etc?
>>
>>  David
>>
>>
>> On Thu, Nov 11, 2010 at 11:48 AM, David Cole <david.cole at kitware.com> wrote:
>>> Hey David Gobbi!
>>>
>>> Help!
>>>
>>> This commit that I just pushed to VTK 'master' is getting build errors
>>> on the continuous dashboard.
>>>
>>> http://vtk.org/gitweb?p=VTK.git;a=commitdiff;h=a86ee191000177c52c01b41cda36121c7f478920
>>>
>>>
>>> Is there something I should change in the wrapper generators to handle
>>> this new line of code inside of C++ classes??
>>>  // Description:
>>>  // Signature definition for programmable method callbacks. Methods passed to
>>>  // SetExecuteMethod or SetExecuteMethodArgDelete must conform to this
>>>  // signature.
>>>  typedef void (VTK_CB_CC *ProgrammableMethodCallbackType)(void *arg);
>>>
>>> Or should I resort to BTX/ETX here?
>>>
>>> It's ironic that this breaks the existing VTK wrappers.... The purpose
>>> of my commit was to make wrapping these programmable method types
>>> automatic as C# delegates in our ActiViz .NET code base..... :-)
>>>
>>> I'm building now with python wrapping turned on locally, so I should
>>> be able to verify the fix before I push it.
>>>
>>>
>>> Thanks for any suggestions,
>>> David Cole
>>> Kitware, Inc.
>>>
>>
>