[Paraview-developers] Proposal: Packaging ParaView

[Utkarsh Ayachit]

Haha, radical is a good way to put it since I am going to object to
pretty much all of them :). Here are my counter arguments:

> - paraview superbuild cmake scripts are not in a separate repo, they are
> part of paraview

We tried this is past and there is one major problem with this: it
becomes incredibly tricky to synchronize the release builds and
tagging the source for a release. If we detect some build setting bug
after the release was tagged, we cannot simply fix it. It has to go to
the source and we need to produce a patch etc. etc. It's much easier
to say here's a tagged ParaView source now setup the cmake scripts to
package this particular paraview.

> - paraview superbuild becomes the standard way to build paraview all the
> time.  By default USE_SYSTEM_{QT,PYTHON,MPI}  are enabled

For the reasons above, this is not possible.

> - 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.

Superbuild is unwieldy when it comes to  subprojects that are
constantly changing e.g. if you changed VTK source files, just doing a
make will not rebuild paraview. I could go either ways with 3rd party
utils like freetype etc. but for VTK, submodule is sort of a
necessity.

>   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.

This should indeed be the case irrespective of whether we do
submodules or external projects. It's unfortunate, partly because CVS
never supported that in the past, that don't maintain forks with
changes separated from the originals.

Utkarsh