[Paraview-developers] [EXTERNAL] Proposal: Packaging ParaView

[Utkarsh Ayachit]

Both those requirements will be/are supported.

Utkarsh

On Tue, Mar 27, 2012 at 11:47 PM, Scott, W Alan <wascott at sandia.gov> wrote:
> I would assume this would work.  Just to mention a few of my requirements, in case I am missing something, I have a build environment that is mixed with regards to firewalls.  In other words, some LANs/Clusters can see external git repositories, and others cannot.  Further, I want to make sure they all build from the same codebase.  Thus, I assume I want to be able to explicitly pull the correct source packages, and turn off the superbuild's pulling these packages for me.  Finally, all of these builds have to be able to make client/server connections together.  We had an issue  where one build of paraview was pulled to a release tag, the other saw the git repository and pulled to a git checkin tag, and they would not connect.
>
> Alan
>
> -----Original Message-----
> From: paraview-developers-bounces at paraview.org [mailto:paraview-developers-bounces at paraview.org] On Behalf Of Utkarsh Ayachit
> Sent: Tuesday, March 27, 2012 11:28 AM
> To: ParaView Developers
> Subject: [EXTERNAL] [Paraview-developers] Proposal: Packaging ParaView
>
> 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
>
>