[vtk-developers] proposed vtk build changes

[Michael Halle]

I have made local changes to some of the vtk configuration files; I'm
finishing my final tests and I'd like last minute feedback before I
check them in to the distribution.

*** Removing relative path names from the build ***

Right now, most of the vtk build directories can only be one level
deep because the make rules assume .. is the root directory of vtk.
It also means that modules have to be developed in the vtk directory
(there are good policy reasons for that, but right now the machinery
enforces it).

To correct this limitation, I've added a new make variable VTK_SRC to
system.make, which is the absolute path of the VTK source tree.  This
required changes to configure.in, configure, and system.make.in.

I then hacked Kits.make, targets.cxx configure, and configure.in to
use ${VTK_SRC} instead of ${srcdir}/.. and ${VTK_OBJ} instead of ..,
as appropriate.

*** Making vtk tcl libraries loadable through wish ***

Currently, when vtk links its Tcl wrappers, it doesn't pull in any
implementation libraries at link time.  That means if you do a 
"load ./libVTKCommonTcl.so" from wish, it won't be able to find 
libVTKCommon.so.  I changed the library link line so that linking,
say, libVTKCommonTcl.so brings in libVTKCommon.so.  It also brings
in all the associated X, GL, and MPI libraries if they are defined.

Since only one core implementation library is pulled in per wrapper
library, you have to load all libraries you need if you're going to
use this feature (you can't count on one wrapper library pulling all
the implementation libraries):

load ./libVTKCommonTcl.so
load ./libVTKGraphicsTcl.so
load ./libVTKImagingTcl.so
load ./libVTKContribTcl.so
...

All that changed here is Kits.make.

*** Adding support rules for external libraries ***

Right now, if you want to add in other objects to a library, you put
them in the KIT_LIBS variable.  However, KIT_LIBS is in the dependency
list for the library.  If it's an object file, that's great.  If not,
you have to explicitly put an empty make rule for the link to succeed.
Also, you can't then use a "-L/path/to/lib" in KIT_LIBS, because the
flag itself will be seen as a dependency.

I added an additional make variable, KIT_EXTERNAL_LIBS, that is like
KIT_LIBS except it isn't dependency checked.

This change only really touched Kits.make.  I also changed the
comments in contrib and local to reflect the new variable.


Please, let me know if any of these changes seem toxic.  If not, I'd
like to check them in early this afternoon.


							--Mike