[Paraview] Building standalone vtk within Paraview

[John Biddiscombe (CSCS)]

Thanks Ken,

I think this will be fine for maintaining vtk/paraview type builds, but 
for a situation like this...

Projects
  --vtkCSCSCommon
  --vtkCSCSProjectX
  --vtkCSCSProjectY

Each project has got a cmakelists file and we need to FIND_VTK + USE_VTK 
etc etc. This works ok and an easy build of all vtk modules ensues...The 
trouble is, we also want to produce Paraview wrappers for the projects. 
So for this to work we need to FIND_PARAVIEW + USE_PARAVIEW instead of 
VTK. Having two build trees isn't so straightforward now because 
building for vtk and building for paraview entail slightly different setups.

Option 1 could be to put some logic in cmakelists at the top level 
Projects cmakelists so that the user can build with VTK support and thus 
include vtk stuff, or build with Paraview support.... Would this work? 
we'd need a lot of If(CSCS_BUILD_PARAVIEW) logic around some of the lib 
generation and the linking of libs against each other gets a little more 
messy (libvtkCSCSProjectX uses libvtkCSCSCommon and libPVvtkCSCSProjectX 
etc etc gets a little involved) 

Option 2 - enable a single paraview compatible tree which spits out a 
complete vtk build on the way. This would make life considerably easier 
I think - this is what I was hoping for by tweaking the build.

Option3. I'm still experimenting with building multiple vtkLocal style 
libs for paraview and perhaps I'm making life harder than it needs to be 
and in fact the libs issue is not so tricky and option 1 can be made 
workable.

So my question is really...why can't a paraview build use the standard 
VTK_WRAP_TCL - why is a special case required. If I understand this 
properly I think I'll see better how to manage our builds.

thanks

JB

Ken Martin wrote:

>What we typically do here at Kitware is have one source tree and then two
>binary trees. One binary tree is for ParaView and the other ParaView tree is
>for VTK. We point the VTK binary tree to the VTK subdirectory in the
>ParaView source tree. That way we can make changes to the source tree and
>test both ParaView and VTK. Of course this requires building both VTK and PV
>which ends up duplicating a bunch of .o files but it's not too bad.
>
>Ken
>
>
>  
>
>>When building paraview, only a subset of the vtk is wrapped in tcl,
>>which means that for testing regular vtk code with tcl, one must build
>>vtk on its own, and also build paraview separately.
>>
>>I'd like to build Paraview alone, and have it produce a complete vtk
>>build so that one set of libraries and one set of build can be done to
>>cover both.
>>Having looked at the cmakelists files I see that VTK_WRAP_TCL is forced
>>to false, and then a separate Utilities/VTKTclWrapping set of stuff is
>>invoked.
>>
>>By disabling the forcing of VTK_WRAP_TCL and clearing one of the COPY
>>Tcl/tk lib flags, I was able to produce most of the tcl wrappers, but
>>the xdmf utility died on VTK_WRAP_TCL2 command.
>>
>>Can anyone briefly outline how I would do this cleanly within Paraview.
>>It'd be nice to have a
>>BUILD_VTK_COMPLETE flag which could be enabled and would result in a
>>full set of vtk libs being produced.
>>
>>Any reason why this can't be accomplished (subject to those flags which
>>Paraview needs to force).
>>
>>thanks
>>
>>JB
>>
>>_______________________________________________
>>ParaView mailing list
>>ParaView at paraview.org
>>http://www.paraview.org/mailman/listinfo/paraview
>>    
>>
>
>
>_______________________________________________
>ParaView mailing list
>ParaView at paraview.org
>http://www.paraview.org/mailman/listinfo/paraview
>
>  
>

-- 
John Biddiscombe,                            email:biddisco @ cscs.ch
http://www.cscs.ch/about/BJohn.php
CSCS, Swiss National Supercomputing Centre  | Tel:  +41 (91) 610.82.07
Via Cantonale, 6928 Manno, Switzerland      | Fax:  +41 (91) 610.82.82