[vtkusers] Can we drop Visual Studio 6 support?

Fri Apr 17 19:03:04 EDT 2009

> So, in all of VTK, there is one test that is disabled for Visual
> Studio 6. And I guess there is no other way to provide this
> functionality. Therefore, we should remove VS6 as a compiler.

No, we should remove MSVC6 support because
1. it requires significant effort to keep it compiling VTK and ParaView
cleanly including
  - obfuscated code required to handle missing or broken features that
    is hard to read and maintain,
  - developer time learning, remembering, and exercising the list
    of language features are unsupported or broken and all the hacks
    to get around them;
2. it requires significant effort to keep the tests passing (there have
been other instances besides the one I pointed out -- that's just the
one I know of where no fix was eventually discovered);
3. Microsoft no longer supports it; and
4. all of the other good reasons that people have been pointing out on
this thread.

I don't want to be rude, but I want to make sure I get my point across;
so, let me turn the question around. Besides the idea that some
nebulously-sized group of developers (who are supporting other
developers who build "products") might one day want to use a new version
of VTK instead of one of the many versions that already support MSVC6,
what reason is there to keep it?

	David

> On Fri, Apr 17, 2009 at 3:27 PM, David Thompson <dcthomp at sandia.gov> wrote:
> >> First look: the continuous vs6 platform with this ctest script:
> >> http://www.cdash.org/CDash/viewNotes.php?buildid=314820 which has
> >> PARALLEL ON is passing all tests. When you say this works on all other
> >> platforms, how did verify that?
> > In order to have a clean dashboard for the recent VTK release, the
> > buildmaster at Kitware added this to Parallel/Testing/Cxx/CMakeLists.txt
> >
> >  IF(NOT CMAKE_GENERATOR MATCHES "Visual Studio 6")
> >    SET(MyTests ${MyTests}
> >      TestMultiBlockExodusWrite.cxx
> >    )
> >  ENDIF(NOT CMAKE_GENERATOR MATCHES "Visual Studio 6")
> >
> > That was rev 1.82 on 3/6/2009 so I believe dashboards just before that
> > should show the test failing.
> >
> >        David
> >
> >> On Fri, Apr 17, 2009 at 3:06 PM, David Thompson <dcthomp at sandia.gov> wrote:
> >> >> With ITK, if we have a VS6 or Borland or mingw or cygwin or VS7 or SUN
> >> >> CC or 64 bit ICC or ... problem, we ask someone that has the compiler
> >> >> to investigate a fix. Some errors are hard to fix without access to a
> >> >> compiler.
> >> >>
> >> >> If you are still having a problem,  I have a VS6 compiler and can try
> >> >> to track it down for you.
> >> >
> >> > Be careful, I might take you up on that. :-) For instance, we have
> >> > turned off ParallelCxxTests TestMultiBlockExodusWrite on builds using
> >> > MSVC6 because, while it works on all other platforms and runs cleanly
> >> > under valgrind on Linux and Mac OS X, garbage gets written to the test
> >> > file when compiled with MSVC6.
> >> >
> >> >        David
> >> >
> >> >
> >> >> On Fri, Apr 17, 2009 at 2:19 PM, David Thompson <dcthomp at sandia.gov> wrote:
> >> >> >> What sort of maintenance issues are you having?
> >> >> > This type:
> >> >> > http://public.kitware.com/cgi-bin/viewcvs.cgi/Common/vtkUnicodeString.cxx?view=log
> >> >> > There are *many* more examples (perhaps not all as humorously narrated),
> >> >> > but the general problem is that the dashboard machines are the only way
> >> >> > for many developers to test whether something will work with MSVC6. It
> >> >> > can be quite irritating to check in something that should fix a compile
> >> >> > problem and have to wait 1-2 hours before seeing the result.
> >> >> >
> >> >> >> I think the real issue is what compilers do the VTK installed base
> >> >> >> use? You may have customers that are using 3rd party drivers/libraries
> >> >> >> that are VS6. Actually, there is no way to know who the customers are.
> >> >> > It would be nice to assume that customers who continue to develop with
> >> >> > VTK read at least the digest, but I agree that some may note and it
> >> >> > could be some time before we hear from them. I still think it is a good
> >> >> > idea to drop VC6 not because it's irritating to debug build problems but
> >> >> > because it can lead to obfuscated code as people rewrite bits here and
> >> >> > there to accommodate old syntax and broken STL implementations.
> >> >> >
> >> >> >        David
> >> >> >
> >> >> >> On Fri, Apr 17, 2009 at 1:43 PM, Berk Geveci <berk.geveci at kitware.com> wrote:
> >> >> >> > Hi folks,
> >> >> >> >
> >> >> >> > We are thinking of dropping support for Visual Studio 6. It is causing
> >> >> >> > annoying maintenance issues since no one in the developer team uses it
> >> >> >> > and since VS 6 supports only a subset of modern C++ features. Are
> >> >> >> > there any objects? If yes, I would like to know why.
> >> >> >> >
> >> >> >> > Best,
> >> >> >> > -berk
> >> >> >> > _______________________________________________
> >> >> >> > Powered by www.kitware.com
> >> >> >> >
> >> >> >> > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> >> >> >> >
> >> >> >> > Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ
> >> >> >> >
> >> >> >> > Follow this link to subscribe/unsubscribe:
> >> >> >> > http://www.vtk.org/mailman/listinfo/vtkusers
> >> >> >> >
> >> >> >> _______________________________________________
> >> >> >> Powered by www.kitware.com
> >> >> >>
> >> >> >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> >> >> >>
> >> >> >> Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ
> >> >> >>
> >> >> >> Follow this link to subscribe/unsubscribe:
> >> >> >> http://www.vtk.org/mailman/listinfo/vtkusers
> >> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >>
> >> >
> >> >
> >> >
> >>
> >
> >
> >
> 