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

Wylie, Brian bnwylie at sandia.gov
Thu Nov 11 16:26:31 EST 2010 

For those bottlenecking on this (like I was) you can pop this simple patch to get it to compile on windows.

bnwylie at S914708 /c/work/Titan/TPL/VTK (master)
$ git diff
diff --git a/Common/vtkWin32Header.h b/Common/vtkWin32Header.h
index c20a502..7bb046d 100644
--- a/Common/vtkWin32Header.h
+++ b/Common/vtkWin32Header.h
@@ -64,7 +64,7 @@ Do_not_include_vtkWin32Header_directly__vtkSystemIncludes_includes_it;
 //
 #ifndef VTK_CB_CC
 #ifdef _WIN32
-#define VTK_CB_CC __stdcall
+#define VTK_CB_CC
 #else
 #define VTK_CB_CC
 #endif
diff --git a/Graphics/vtkProgrammableFilter.h b/Graphics/vtkProgrammableFilter.h

  Brian Wylie - Org 1424
  Sandia National Laboratories
  MS 1323 - Building CSRI/242
  (505)844-2238 FAX(505)284-2518   
       _______ __
      /_  __(_) /_____ _____
       / / / / __/ __ `/ __ \
      / / / / /_/ /_/ / / / /
     /_/ /_/\__/\__,_/_/ /_/
 Scalable Analysis and Visualization


-----Original Message-----
From: vtk-developers-bounces at vtk.org [mailto:vtk-developers-bounces at vtk.org] On Behalf Of David Gobbi
Sent: Thursday, November 11, 2010 1:00 PM
To: Cole,David
Cc: VTK Developers
Subject: Re: [vtk-developers] New VTK wrapping tools and a function pointer typedef question...

Yet another follow up: I think my regexp for
ProgrammableMethodCallbackType was incomplete.  It should probably be
the following:

"ProgrammableMethodCallbackType"[\t\n\r ]*[0-9a-zA-Z_]* {
 yylval.str = vtkstrndup("void (*)(void *)");
 return(VAR_FUNCTION); }

This includes the variable name as part of the regexp.

  David


On Thu, Nov 11, 2010 at 12:44 PM, David Gobbi <david.gobbi at gmail.com> wrote:
> Another quick note:  All of the suff that it says to do after running
> flex is just to avoid compiler warnings on the dashboards.  You don't
> have to do those file modifications until you are ready to commit.
>
>   David
>
>
> On Thu, Nov 11, 2010 at 12:42 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>> 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.
>>>>>
>>>>
>>>
>>
>
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.vtk.org/mailman/listinfo/vtk-developers

More information about the vtk-developers mailing list