[vtk-developers] building modules outside the vtk 4.0 tree
ken.martin at kitware.com
Wed Dec 19 11:46:05 EST 2001
Our plan in 4.0 was to not use local but to support additional classes
outside of the VTK tree. The problem is that we have not provided an
example of how to do this although it should be much easier than
vtk3.2 and more powerful (working from installed VTKs) Sebastien is
working up an example for folks.
> -----Original Message-----
> From: vtk-developers-admin at public.kitware.com
> [mailto:vtk-developers-admin at public.kitware.com]On Behalf Of Michael
> Sent: Wednesday, December 19, 2001 6:11 AM
> To: vtk-developers at public.kitware.com
> Subject: [vtk-developers] building modules outside the vtk 4.0 tree
> I'm inspired by the helpful "vtk Local in 15 steps" posting to ask
> the following question:
> In vtk4.0, how hard is it (under Unix) to build a
> module outside of
> the main vtk source tree?
> Background: Our lab currently faces the problem of a great
> proliferation of compiled copies of the vtk source tree. Every
> developer has one. Everyone builds their own Local library. It's
> a nightmare to maintain.
> For vtk 3.2, we came up with a way to dynamically link in modules.
> Briefly, user make a shadow tree (also known as a link) of a single
> compiled vtk source tree. They make a subdirectory in that tree.
> A script runs and pulls out the required configure line from one of
> the standard vtk modules (graphics, I think) so that the Makefile
> can be built. Optionally, the developers files can also be linked
> in from outside the shadow tree, so the entire build environment is
> essentially symbolic links to either a compiled vtk distribution or
> the users source files. Not the absolute prettiest solution to the
> problem, but it works.
> The result is a set of dynamically loadable libraries: the
> implementation C++ library, and the scripting wrappers. To use the
> module, the user need only load the wrapper library (for
> example, the
> Tcl wrapper) using scripting library tools (load in Tcl).
> The wrapper
> is linked to pull in the C++ library. No modification of
> the main vtk
> tree is needed. And that's great.
> Now we face the task of doing the same thing for vtk4.0. Can anyone
> tell me if they think it will be easier or harder? It seems that if
> we encouraged this kind of loadability, hacking vtktcl.c to
> add Local
> shouldn't be needed, since Tcl can do the load by itself. In
> addition, the ability for developers to exchange and combine
> pre-compiled modules (only if they are built off the same version of
> vtk with the same compiler, of course) is incredibly useful and
> Thanks for you for impending vtk4.0wizardwords.
> Michael Halle
> mhalle at media.mit.edu
> vtk-developers mailing list
> vtk-developers at public.kitware.com
More information about the vtk-developers