[Paraview-developers] Proposal: Packaging ParaView

[Utkarsh Ayachit]

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