[Paraview-developers] Proposal: Packaging ParaView

[Pat Marion]

A great proposal!

Perhaps the following ideas are more radical than you had in mind, but
here's my thoughts:

- paraview superbuild cmake scripts are not in a separate repo, they are
part of paraview
- paraview superbuild becomes the standard way to build paraview all the
time.  By default USE_SYSTEM_{QT,PYTHON,MPI}  are enabled
- vtk is an external project, vtk is no longer a git submodule in paraview
(we still build against the pv branches of course)
- make as much as possible an external project, externalize IceT, protobuf,
etc.
  If patches are required to any of these 3rd party libraries, then we
maintain git forks of the projects,
  with our patches as commits, then its easy for the maintainers of these
projects to take our patches upstream.


Pat


On Tue, Mar 27, 2012 at 1:28 PM, Utkarsh Ayachit <
utkarsh.ayachit at kitware.com> wrote:

> Different people imply different things when they say they want to
> generate a package for ParaView. Some, like the official binary
> builders here at Kitware, imply that the package is a complete tarball
> with minimal external run-time dependencies. Others, like those that
> build packages for linux distros, want the package to 'depend' on
> external libraries they specify. Still others, are building on HPC
> systems that require cross compiling or specific environment setup
> with some dependencies available and others not.
>
> In the past ParaView build/install cmake rules themselves tried to
> address all these cases and as expected failed to address all these
> concerns at all the times.
>
> Enter CMake External Projects or Superbuilds. These are meant to be
> used for building projects that depend on other projects. We started
> playing with using superbuilds for ParaView packaging starting with
> 3.12. With our experience with 3.14 builds, it seems like superbuild
> may just be the panacea we were looking for. If we follow the
> following simple rules, it seems like we may be able to address all
> the necessary use-cases.
>
> 1. ParaView (and VTK)'s "make install" will never install any external
> dependencies. The mantra will be "you install what you build". Thus
> people who expected "make install" to install Qt, FFMPEG, Python --
> sorry! "make install" is not for you. You should use
> ParaView-Superbuild to generate a "complete package" and then install
> it where ever you like.
>
> 2. A separate git repository will host what we call the
> ParaView-Superbuild. These will be cmake files that know how to build
> ParaView and all its dependencies for generating packages.
>
> 3. ParaView-Superbuild also follows the same principle as ParaView
> i.e. "package what you build". However unlike ParaView,
> ParaView-Superbuild will know how to build all dependencies for
> ParaView including zlib, libpng, hdf5, Python, numpy and even Qt.
>
> 4. ParaView-Superbuild will have top-level options to build
> with/without Qt or GUI Support or build with OS Mesa (when Qt GUI is
> disabled). These top level options will make it easier to build
> packages with Qt application or just command line server-side tools.
>
> 5. While ParaView-Superbuild will build all dependencies by default,
> there were be options for a few subprojects to use system versions.
> Thus, we can choose to use system Python, Qt, MPI, or HDF5.
>
> 6. One can then use cpack to generate a package with all dependencies
> that were built in the ParaVIew-Superbuild. For system dependencies,
> cpack will ensure that the rpath is setup to include the path where
> those are present e.g. if use chose to use system Qt, then the package
> will be missing any Qt libraries but will have rpath (where
> applicable) setup to  point to where the Qt was located during builds
> so that the user doesn't have to setup the paths when running. Of
> course in this case the binary may not work if simply moved to another
> machine, but then you want to let superbuild build all the
> dependencies on its own.
>
> 7. Finally superbuild will also support cross-compiling as well as
> using external VTK. (I haven't thought about either much at this point
> to say exactly how that would happen, but it needs to).
>
> How does every feel about this approach? Any comments? Thoughts?
>
> To get a feel for what this ParaView Superbuild may look like, look at
> the "v3.14.0" tag on this temporary git repo:
> https://gitorious.org/paraview-collaboration/paraview-binaries-superbuild
>
> This is an experimental repo that only works on linux for now, but it
> should clarify a few things discussed here.
>
> Utkarsh
> _______________________________________________
> Paraview-developers mailing list
> Paraview-developers at paraview.org
> http://public.kitware.com/mailman/listinfo/paraview-developers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20120327/6d76c6ea/attachment.htm>