[vtk-developers] New wrapping code

[Marcus D. Hanwell]

On Tue, Mar 26, 2013 at 2: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.
>
You were never seeing that header, so I suspect it was never set. I am
testing another fix that only adds  the extra headers that used to be
parsed (instead of all of them). I suspect it is largely due to my
brash inclusion of the vtkCommonCore headers variable in the main
module call.

It is hard for me to assess the parser changes, other than to merge
them and see what the nightly does.

Marcus