[vtk-developers] VTK / cmake problems

[Lorensen, William E (Research)]

I understand. But I need some breathing room here. We have many people that are using the bad files.
Also, I need to maintain some backward compatibility.

So, in the short term, I would prefer to get VTK_SOURCE and TCL_LIBRARY from the VTK cache. I can
then spend time updating the CMakeLists.txt files to ge correct. 

Bill

-----Original Message-----
From: Ken Martin [mailto:ken.martin at kitware.com]
Sent: Friday, January 03, 2003 11:29 AM
To: Lorensen, William E (Research); 'Brad King'
Cc: vtk-developers at public.kitware.com
Subject: RE: [vtk-developers] VTK / cmake problems


Without going into too much detail here is the thinking behind removing
VTK_SOURCE_DIR and TCL_LIBRARY. No FindFOO module should set
FOO_SOURCE_DIR. FindTcl doesn't set TCL_SOURCE_DIR, FindGL doesn't set
GL_SOURCE_DIR etc. This is because there is no assurance that the person
building the project even has the source to OpenGL or Tcl on their
machine. And in many cases they will not have the source code and really
should not need the source code. To use VTK you do need the header files
and the libraries but you should not need the source code.
CMakeLists.txt files that use VTK_SOURCE_DIR are probably not really
using the correct value. 

Having said that, you do have some CMakeList files that are using
VTK_SOURCE_DIR and now they do not work (which sucks, wastes time etc).
We had the same issue with ParaView, VolView and a couple other
projects. We decided to modify our projects to use the correct variables
so that they could be built against an installed VTK or a source code
VTK build, etc. 

So, if this is really a problem for you we can add those two variables
back into the settings for source builds only and they will be
undocumented in the public API for the Find/USE VTK module and where
defined they will be documented that they are not to be used. This would
solve your immediate problem. But... My suspicion is that future
projects will just copy the files from existing projects which means
that all your future projects will also be limited to source builds of
VTK not binary or installed VTKs. So it might be worthwhile to improve
the CMakeLists files now so that future projects don't have those
limitations.

Basically in a nutshell we screwed up some in the VTK40 UseVTK files
because it was very early in the CMake process. Since then we have
clarified our definition of what a Find and USE module should do for the
better. 

Ken


> -----Original Message-----
> From: vtk-developers-admin at public.kitware.com [mailto:vtk-developers-
> admin at public.kitware.com] On Behalf Of Lorensen, William E (Research)
> Sent: Friday, January 03, 2003 9:50 AM
> To: 'Brad King'
> Cc: 'vtk-developers at public.kitware.com'
> Subject: RE: [vtk-developers] VTK / cmake problems
> 
> These changes are disruptive to current projects running cmake 1.4. I
> removed my internal cache
> entires and all of a sudden my build no longer worked. I would prefer
to
> remove TCL and
> VTK_SOURCE_DIR from the UseVTK.cmake.inproject. Otherwise I have
dozens of
> people that will have to
> edit their CMakeCache.txt files.
> 
> Bill
> 
> 
> -----Original Message-----
> From: Brad King [mailto:brad.king at kitware.com]
> Sent: Friday, January 03, 2003 9:38 AM
> To: Lorensen, William E (Research)
> Cc: 'vtk-developers at public.kitware.com'
> Subject: RE: [vtk-developers] VTK / cmake problems
> 
> 
> Hi Bill,
> 
> > However, it seems to me that VTK_SOURCE_DIR, TCL_LIBRARY and all
tcl/tk
> > related cmake variabl;es should not be excluded in UseVTK.cmake.in.
> 
> The LOAD_CACHE that is done there is only to simulate the real
solution
> that is implemented for CMake 1.6 (when it is released).  The idea is
to
> make VTK opaque to projects using it in that using it from the build
tree
> and from the install tree should be the same.  Therefore,
VTK_SOURCE_DIR
> cannot be set because it isn't available from the install tree.
> 
> For TCL_LIBRARY, if your project links to vtkCommonTCL, it will get
the
> Tcl library automatically.  If UseVTK has been included, it will also
get
> the proper include paths automatically.  Look at
> 
>   VTK/Examples/Build/vtkLocal
> 
> for an example of a project that uses VTK with Tcl wrapping.
> 
> If an independent library in your project links to TCL on its own,
then it
> is not VTK's responsibility to tell your project where to find TCL.
It
> should have its own use of the FindTCL CMake module.  However, as the
> above example shows, your project can do Tcl wrapping without using
> FindTCL.  Linking to vtkCommonTCL is enough to get all the Tcl symbols
it
> needs.  This is necessary anyway since the vtk Tcl wrappers depend on
some
> VTK symbols from that library.
> 
> -Brad
> _______________________________________________
> vtk-developers mailing list
> vtk-developers at public.kitware.com
> http://public.kitware.com/mailman/listinfo/vtk-developers