[vtk-developers] Removed windows.h from VTK headers.

[Michael Halle]

Since the problem being solved here is mostly one of efficiency,
and assisting the abstract developers who don't want to include
windows.h but have to, wouldn't it change the sense of this
switch (ie, set VTK_INCLUDE_WINDOWS=1 by default, or change the
sense of the switch to be negative, not positive) for a single minor
release before forcing developers to make this change to their
currently-working code?

I understand Brad's case that "the code that currently depends on
this configuration is technically be wrong anyway", but this change
doesn't seem like this is a "must have right now for everybody"
change, just a "really nice to have" change.

I think developers should be given one minor release to change "code
that works" to "code that works the new way" without having to edit
their code.  Developers should also be given a series of tests to
find out if their code it affected by a "proposed" or "accepted"
change, and specific directions about how to change their code
to work with "the new way."

In fact, I think it should be general VTK policy:  everyone shares
the burden of major changes.

--Mike



On Dec 17, 2004, at 8:20 AM, Brad King wrote:

> John Biddiscombe (CSCS) wrote:
>> Couldn't we
>> #include "vtkWindows.h" which would simply include windows as usual 
>> and then #undef all the clashing names that are causing trouble.
>> If users are then having trouble calling windows functions because of 
>> their removal, they can
>> #include "vtkWindowsUnMangle.h ....." which will redef the undef'ed 
>> methods. Not many users will be calling the windows functions that 
>> are renamed and they can easily insert #ifdefs in their code without 
>> vtk having to be bludgeoned into conformance
>
> This solution would not provide the compile time reduction for VTK and 
> would still require changes to application code (and probably even 
> more).  Any place the user would add vtkWindowsUnMangle.h you can just 
> add vtkWindows.h under the current solution.  Besides, I do not like 
> the idea of redefining macros defined by a system header.  The current 
> solution never actually changes these definitions.  It just 
> temporarily adds more.
>
> Right now you can fix your application very quickly by just adding 
> this to your CMake code:
>
> ADD_DEFINITIONS(-DVTK_INCLUDE_WINDOWS_H)
>
> and then using the script in VTK/Utilities/Upgrading to help find 
> methods whose names might have changed.  Again, to put this in 
> perspective it took me less than an hour to fix ALL of ParaView, which 
> is one of the largest VTK applications ever created.
>
> -Brad
> _______________________________________________
> vtk-developers mailing list
> vtk-developers at vtk.org
> http://www.vtk.org/mailman/listinfo/vtk-developers