[vtk-developers] Update on VTK modularization progress

tom fogal tfogal at sci.utah.edu
Wed Sep 28 19:18:08 EDT 2011


We could do that, but it adds more to the link, making shared objects 
bigger and thus causing link and load times to increase.. of course this 
is a very minor concern.

Really: we use NetCDF, but we roll it on our own without using any of 
VTK's support.  So the VTK code for this never gets used in our case.

We'd really like to trim out as much as we can from VTK.  We're doing a 
bit better in this regard now I hope, but we still end up supporting a 
VTK version far longer than it should be supported.  And it looks like 
right now we're going to be shipping a VTK very similar to the branch I 
just pushed, which was based off of your 'release' branch at an 
essentially arbitrary point in time.  New issues crop up; for example, 
newer gcc's (4.5, 4.6) are getting more strict on headers and breaking 
things like the very old vtkDICOM code we have in there... and we don't 
even support loading DICOMs!

The more we can disable the less we have to worry about those kinds of 
issues.

-tom

On 09/28/2011 05:08 PM, David Partyka wrote:
> VisIt uses netcdf doesn't it? Would a VTK_USE_SYSTEM_NETCDF be better so
> that you could just tell VTK to use the netcdf that VisIt is built against?
>
> On Wed, Sep 28, 2011 at 6:48 PM, tom fogal<tfogal at sci.utah.edu>  wrote:
>
>> On 09/27/2011 12:37 PM, Aashish Chaudhary wrote:
>>
>>> Hi Tom,
>>>
>>> On Tue, Sep 27, 2011 at 2:00 PM, tom fogal<tfogal at sci.utah.edu>   wrote:
>>>
>>>> Eeek, I didn't know the modularization effort included a rework of how GL
>>>> worked.  You might be interested in commits like [...]
>>>>
>>>>
>>
>>> I remember your discussion on the mailing list but not sure how much
>>> these commits are related to that (it was some time back).
>>>
>>> These changes are quite significant. Would it be possible for you to
>>> push a topic branch that is GL specific?
>>>
>>
>> I hadn't considered it ready for review quite yet -- in particular, I
>> wanted to fix up a lot of things about how mangled / osmesa is handled in
>> the build system -- but I pushed something anyway.
>>
>> The branch is called 'visit':
>>
>>
>> http://review.source.kitware.**com/#q,status:open+project:**
>> VTK+branch:master+topic:visit,**n,z<http://review.source.kitware.com/#q,status:open+project:VTK+branch:master+topic:visit,n,z>
>>
>> Some of it isn't necessarily OGL related, it's just stuff that's useful for
>> us.  For example:
>>
>>   http://review.source.kitware.**com/#change,2952<http://review.source.kitware.com/#change,2952>
>>
>> which lets us disable NetCDF altogether.  I can provide more
>> comments/explanations per-commit, if that would help.
>>
>> Some of it is in varying levels of completeness and isolation.  That NetCDF
>> commit is probably ready to be pulled right now, for example. Would love to
>> hear comments on what I can do to get what we've got (or similar solutions)
>> upstream.
>>
>> -tom
>>
>> ______________________________**_________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at http://www.kitware.com/**
>> opensource/opensource.html<http://www.kitware.com/opensource/opensource.html>
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.vtk.org/mailman/**listinfo/vtk-developers<http://www.vtk.org/mailman/listinfo/vtk-developers>
>>
>>
>




More information about the vtk-developers mailing list