Let me try to explain better:<br><br>* The latest official release of VTK is 5.0. <br>* ParaView does not work with VTK 5.0 (we have made changes, additions and bug fixes to VTK since then).<br>* It is too much work and also too complicated to release a special VTK for ParaView. We have documentation, books and other support products that have to match the VTK release.
<br>* We do not want to be bound to an official release of VTK because ParaView releases are much more often than VTK releases<br>* Next time we make a release (ParaView 2.6 in November), we will branch VTK. We will not create an official VTK release.
5.2 will probably be much later.<br>* Debian and other distributions should use the latest official VTK release<br><br>When ParaView release cycle slows down and can match VTK's in the future, we will consider synchronizing the two. As for Tk, we are switching to Qt and we will not include Qt in the ParaView source. Therefore, it will be possible to link against an external Qt.
<br><br>As for Debian packages, it should be possible to include the VTK that ParaView needs in such a package. If the issue is naming conflicts, we can change the cmake scripts to name ParaView's VTK libraries appropriately to avoid conflicts.
<br><br>-berk<br><br><div><span class="gmail_quote">On 10/4/06, <b class="gmail_sendername">Francesco Poli</b> <<a href="mailto:frx@firenze.linux.it">frx@firenze.linux.it</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Wed, 4 Oct 2006 14:38:05 -0400 Berk Geveci wrote:<br><br>> We depend on specific version of VTK and TclTk. To avoid the headache<br>> of debugging version incompatibilities, we make it very hard to use<br>> anything but included version.
<br><br>This seems to be a significant inconvenience for users, though.<br><br>What's the use of dynamic libraries ("shared objects"), if every<br>application ships with its own copy of the needed libraries?<br>
It's unnecessary code duplication on the target system and makes Unix<br>systems go one step in the direction of a situation similar to the<br>so-called "DLL hell" (which is typically found in Windows systems).<br>
<br>I can understand recommending particular VTK and TclTk releases and<br>stating that any other combination is untested, but deliberately making<br>it hard to link against already installed libraries does not sound<br>right...
<br><br><br>As an aside, I suspect that this is one of the reasons why nobody has<br>yet successfully packaged Paraview for inclusion in the official Debian<br>archive[1]: it's probably unacceptable not to link against libraries
<br>(such as VTK and Tcl/Tk) that are already packaged for Debian, unless<br>there are very good reasons not to do so...<br><br>[1] despite the interest that some users have expressed for such a<br>package: there's an open RFP (Request For Package) bug about Paraview
<br><<a href="http://bugs.debian.org/304334">http://bugs.debian.org/304334</a>><br><br><br><br>--<br>But it is also tradition that times *must* and always<br>do change, my friend. -- from _Coming to America_<br>..................................................... Francesco Poli .
<br> GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4<br><br><br>_______________________________________________<br>ParaView mailing list<br><a href="mailto:ParaView@paraview.org">ParaView@paraview.org</a>
<br><a href="http://www.paraview.org/mailman/listinfo/paraview">http://www.paraview.org/mailman/listinfo/paraview</a><br><br><br><br></blockquote></div><br>