[vtk-developers] Improvements to the Python wrapping in VTK

Kyle Lutz kyle.lutz at kitware.com
Tue Mar 19 15:53:39 EDT 2013


On Tue, Mar 19, 2013 at 3:34 PM, Marcus D. Hanwell
<marcus.hanwell at kitware.com> wrote:
> On Tue, Mar 19, 2013 at 9:43 AM, David Gobbi <david.gobbi at gmail.com> wrote:
>> On Mon, Mar 18, 2013 at 6:08 PM, Marcus D. Hanwell
>> <marcus.hanwell at kitware.com> wrote:
>>> On Mon, Mar 11, 2013 at 1:51 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>> On Mon, Mar 11, 2013 at 11:37 AM, Marcus D. Hanwell
>>>> <marcus.hanwell at kitware.com> wrote:
>>>>> On Mon, Mar 11, 2013 at 1:34 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>>>> On Mon, Mar 11, 2013 at 11:01 AM, Marcus D. Hanwell
>>>>>> <marcus.hanwell at kitware.com> wrote:
>>>>>>>
>>>>>>> That sounds great - I will make that move (and agree on reducing
>>>>>>> moves). My final question if you look at the patch is on the right way
>>>>>>> to handle vtkType.h and friends - should they just be marked as
>>>>>>> WRAP_SPECIAL, should we do something different with WRAP_HEADER (which
>>>>>>> is currently going into the classes file).
>>>>>>
>>>>>> I want to export all python-wrappable files, including vtkType.h.  But
>>>>>> there is no vtkCommonCore-Headers.cmake, so I don't know where to put
>>>>>> vtkType.h except in vtkCommonCore-Classes.cmake, which is a poor fit.
>>>>>>
>>>>>> The main purpose of both WRAP_HEADER and WRAP_SPECIAL is
>>>>>> just to wrap files in python that don't get wrapped in tcl or java.  The
>>>>>> WRAP_HEADER is just for wrapping headers that aren't already in the
>>>>>> class list.  So of course I'd like for WRAP_HEADER headers to be
>>>>>> exported, but really I'd prefer to export all non-class headers
>>>>>> anyway.
>>>>>>
>>>>>> Since I never extended the "special" wrapping to the java and tcl
>>>>>> wrappers (and almost certainly won't) maybe a WRAP_PYTHON
>>>>>> should replace both WRAP_HEADER and WRAP_SPECIAL.
>>>>>>
>>>>> I feel like if WRAP_SPECIAL is simply ignored by the other wrapped
>>>>> languages keeping that name seems reasonable. If we want to extend
>>>>> either one (or another language in the future) then we can use
>>>>> WRAP_SPECIAL as an extended set of files that your wrapper must
>>>>> support and get rid of WRAP_HEADER entirely. It seems to me like they
>>>>> belong in the -Classes file, but perhaps that name could be a little
>>>>> more general (-Headers as we only really care about headers for
>>>>> wrapping?)
>>>>
>>>> I'd also prefer -Headers over -Classes.  A complete list of
>>>> every header file that is part of the install, along with a list
>>>> of properties.
>>>>
>>> I am just working on cleaning this topic up. I noticed that since
>>> moving the vtkWrappingPython module three Python tests are now
>>> failing,
>>>
>>> http://open.cdash.org/viewTest.php?onlyfailed&buildid=2842500
>>>
>>> It seems that there is some hardwired logic I am not aware of - any
>>> ideas? This is the test string, templates and variants so it all fits
>>> that the special code is being missed somehow.
>>
>> These failures happen because some classes appear in both the
>> SRCS and HDRS, and that confuses the vtkWrapHierarchy  tool.
>> Specifically, vtkTypedArray, vtkSparseArray, vtkDenseArray appear
>> as both .h and as .txx files.  The Hierarchy.txt files end up with two
>> entries for each, one marked as WRAP_EXLUDE;WRAP_SPECIAL
>> (which is correct) with a duplicate marked as just WRAP_EXCLUDE.
>
> I am just getting my head around this now, I guess this is because the
> txx need to be installed, but why not list the txx in the source (as
> they are closer to the source) and add some code to deal with txx
> files correctly? This doesn't seem to affect the -Headers file either,
> which only shows one occurrence of each of these classes. So if I fix
> the duplication then wrap hierarchy should be happy? It would be good
> to get all of the wrapping tools looking at the same information, but
> I am not sure I will have the time necessary to carry this through for
> everything.

While the answer is probably "because historical reasons", is there
any benefit to keeping the .h and .txx files separate? There seems to
be less than a dozen .txx's in VTK, perhaps it would be easier to just
merge them with the .h's instead?

-kyle



More information about the vtk-developers mailing list