[vtk-developers] And one include to rule them all

[Berk Geveci]

Good point Bill. At the least, we should wait for a year or more before
making such a change (I don't have a strong opinion either way). It is
going to take a while for all the classes/modules to settle. I currently
see quite a few problems with where some classes and and inter-dependencies
that need to be addressed. So over the next year or more, classes are going
to move around quite a bit and it would be very annoying for folks to keep
fixing #includes.

-berk

On Tue, Sep 4, 2012 at 3:23 PM, Bill Lorensen <bill.lorensen at gmail.com>wrote:

> +1 for timings.
>
> Also, if code moves from one module to another, the API breaks.
>
>
> On Tue, Sep 4, 2012 at 3:12 PM, Brad King <brad.king at kitware.com> wrote:
>
>> On 09/04/2012 02:27 PM, Marcus D. Hanwell wrote:
>> > Reducing the difference between the two ways of building against VTK
>>
>> The CMake code is already no different for building against a
>> VTK build tree or a VTK install tree.  Only the value of VTK_DIR
>> changes.
>>
>> > reducing compilation time by not adding so many include paths
>> > during VTK builds.
>>
>> Has anyone done timings?
>>
>> -Brad
>> _______________________________________________
>> 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
>>
>>
>
>
> --
> Unpaid intern in BillsBasement at noware dot com
>
>
> _______________________________________________
> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20120905/785d51ab/attachment.html>