[vtk-developers] New wrapping code

[David Gobbi]

On Tue, Mar 26, 2013 at 12:40 PM, David Gobbi <david.gobbi at gmail.com> wrote:
> On Tue, Mar 26, 2013 at 12:36 PM, Marcus D. Hanwell
> <marcus.hanwell at kitware.com> wrote:
>> On Tue, Mar 26, 2013 at 2:29 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>> On Tue, Mar 26, 2013 at 12:13 PM, Marcus D. Hanwell
>>> <marcus.hanwell at kitware.com> wrote:
>>>> On Tue, Mar 26, 2013 at 1:55 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>>> On Tue, Mar 26, 2013 at 11:18 AM, Marcus D. Hanwell
>>>>> <marcus.hanwell at kitware.com> wrote:
>>>>>> On Tue, Mar 26, 2013 at 9:50 AM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>>>>> On Tue, Mar 26, 2013 at 7:41 AM, Marcus D. Hanwell
>>>>>>> <marcus.hanwell at kitware.com> wrote:
>>>>>>>> Hi David,
>>>>>>>>
>>>>>>>> On Tue, Mar 26, 2013 at 9:25 AM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>>>>>>> There is a minor problem with the wrapping code that I noticed:
>>>>>>>>> not all of the include files are going to vtkWrapPython.  For instance,
>>>>>>>>> take a look at Wrapping/Python/vtkIOExportPython.args and
>>>>>>>>> compare to IO/Export/vtkIOExportJava.args (or to the old python
>>>>>>>>> args file from before the wrapping changes).  This is probably
>>>>>>>>> just some minor issue with the modified cmake scripts.
>>>>>>>>>
>>>>>>>> I will look into it, is this causing issues you have noticed so far?
>>>>>>>
>>>>>>> Yes, it was half of what caused the dashboard failures (the other half
>>>>>>> being the macro).  Usually, macros are no problem for the wrapper
>>>>>>> tools, because they find the macros and expand them automatically.
>>>>>>> That's why the use of vtkSetNGetMacro in the past has not caused
>>>>>>> compile errors.
>>>>>>>
>>>>>>> Header files also contain a lot of #define's that are used for
>>>>>>> conditional compilation later on.  The wrapper tools respect #ifdefs
>>>>>>> just like a compiler does.  So it's very important that the wrapper
>>>>>>> tools can find all the header files that are #included by whatever
>>>>>>> header they are wrapping.
>>>>>>>
>>>>>> http://review.source.kitware.com/#/t/2435/ should resolve the issue,
>>>>>> although I just noticed it repeats the module's include directories.
>>>>>> If this looks reasonable perhaps just set the wrapper  tools include
>>>>>> directories based solely on this variable if present (slightly renamed
>>>>>> to make it all includes rather than extra)?
>>>>>
>>>>> It also looks like the "50+" errors on the dashboard (for some Win32
>>>>> machines) are due to the python patch.  Or at least, the only thing
>>>>> that would cause such an error is a change to the VTK CMake scripts,
>>>>> so the python patch is the prime suspect.  But I'm not sure exactly
>>>>> what cmake change is responsible.
>>>>>
>>>> I am guessing it is wrap hierarchy, with errors such as,
>>>>
>>>> In /.../VTK-maint-shared-src/Common/Core/vtkWin32Header.h:82:
>>>> 7>syntax error.
>>>>
>>>> This  seems like they are hitting something they don't understand, I
>>>> could remove more headers that were added and see what that looks
>>>> like.
>>>>
>>>> Thoughts?
>>>
>>> It seems to be another issue with "-I" options not being sent to the
>>> wrapper tools, specifically to vtkWrapHierarchy in this instance.
>>> The code on line 82 with the "syntax error" is only encountered when
>>> # if defined(VTK_INCLUDE_WINDOWS_H) is false.
>>>
>>> So I wonder why VTK_INCLUDE_WINDOWS_H isn't set anymore?
>>> I'm not even sure where it gets set.  Is it set by a -D option in the
>>> CMake scripts, I wonder?
>>>
>>> Maybe I should just add a rule to the wrapper-parser so that it can
>>> handle the strange "( __stdcall * " token combination that is causing
>>> the syntax error.
>>>
>> Are you sure it was ever set, with regards to wrap hierarchy the  only
>> change I made was to add a bunch of headers to what wrap hierarchy saw
>> (including vtkWin32Headers.h) causing the cascade. Removing it would
>> likely fix this issue, it is the Python wrapping I changed along with
>> what the module saw as the WRAP_HEADERS property was not suitable. I
>> can seriously prune  that list back down to what was in WRAP_HEADERS.
>
> That's the thing, maybe it was never set, maybe it's there to be set by
> VTK users.  It's very strange that this error has popped up all of a sudden.
> It might be a WRAP_HEADERS issue but I'm really not sure.
>
> Let me push a wrapper-parser fix to gerrit and see if that resolves the issue.

Pushed to gerrit: http://review.source.kitware.com/#/t/2436/
This allows vtkWrapHierarchy to parse the construct that was
causing the syntax error on the dashboard.

 - David