[Paraview-developers] ParaView builds, git and versions

[Utkarsh Ayachit]

Alan,

You touch on two (sorta separate) issues here. Let's isolate them just
to make it easier to handle.

Issue # 1: ParaView Version Determination Code
-------------------------------------------------------------------------
The problem is that the current mechanism for determining version of
ParaView using git or a file manually put in by users, is error prone.

Solution: (now pushed in next, should make it into 3.14)
------------

Similar to what was done in past, we'll have  a hardcoded version
number in ParaView/CMakeLists.txt that will be used if git-describe
fails for any reason. Currently, while describe yields something like
"v3.12.0-1209-g8c85b5d", the hard coded version is "v3.12.0-enhanced".
Since server/client handshake only uses the major.minor (i.e. 3.12)
for validation, servers and clients that find git and those that don't
will work just fine with each other.

Every time we tag a ParaView version, we (as in the gatekeeper) will
ensure that the tagged commit is a commit that change this version
encoded in the CMakeLists.txt file as well (exactly as was done in the
past) so that client-server handshake still works.

I don't like the idea of allow users to tell ParaView what version it
is since it's very easy to forget that that's what was done as we;d
end up with weird issues.

Issues #2: Building ParaView and all dependencies for package
maintainers/distributors
-------------------------------------------------------------------------------------------------------------------------------
Problems: (a) offline builds, (b) use-system libs, if specified.

Solution:
-------------

We are agreement there. I've been playing with a revised version of
the ParaView superbuild scripts that are make both these goals
possible (the second one is a todo, but I'm positive, it should be too
hard to address).

Here's what the solution will provide:
* Allow user to turn on/off optional dependencies e.g. Mesa, Qt. When
off, the superbuild won't download or try to use them at all.
* For dependencies that are ON, it will look at a specified location
for downloaded tarballs, if those are present, they will be used
directly without accessing the internet. Thus will make it possible to
use superbuild on machines not connected to internet.
* When a dependency is ON (or not optional), the user will be provided
with two options: i> build using superbuild ii> use-system libs. This
would be useful for Python, MPI, Qt, etc.

Work currently underway to upgrade VTK and ParaView's cmake files.
That, together with these updates to superbuild are aimed at making
packager's/site maintainer's life simpler. All of these are however,
targeted for post 3.14. We'll have  a more detailed explanation of the
plan after 3.14 is out.

Utkarsh

On Thu, Feb 2, 2012 at 8:48 PM, Scott, W Alan <wascott at sandia.gov> wrote:
> I have two concerns with ParaView builds for release – figuring out what
> version of ParaView we are building, and where we get the dependent
> packages.
>
> Here at Sandia, we have an issue whenever ParaView tries to pull any source
> code from the internet.  This occurs for the following reasons.
>
> ParaView itself has two scenarios:
>
> We have some systems that can see the internet, and some that cannot.  These
> two have to connect together as client/server.  Thus, both have to be built
> from the same source code, with the same version numbers, and one can’t
> think it is a specific git version and the other be blind.  Both have to
> think they are just some version number of ParaView.
> We are running on a platform (client and server) that cannot see the
> internet, and may not even have connectivity to the rest of our network.
> ParaView client and server still needs to build, with me (or the
> CMakeLists.txt, etc) telling it what version it is building.
>
> For other “stuff”, such as Mesa, Python, Qt, etc, we need the option to not
> have the build look at, and pull, copies of these datasets.   Once again,
> the usecase is where we are building for a system that is not connected to
> the internet – or any other part of the network.  This must work standalone.
>
>
> If I were king, we would do the following with ParaView:
>
> Allow me to tell ParaView what version we are building – turning off looking
> at Kitware for the Git version.
> On dependent packages:
>
> If the package exists, use it.  Don’t look at the internet.
> If the package doesn’t exist, try to find it from the system.  MPI will
> often happen this way.
> If the package isn’t on the system, go get it.
>
> On the superbuild, Kitware would make sure that ParaView built from scratch
> on a client – and server – setup that was disconnected from the internet.
>
>
> For some reason, I am thinking that Utkarsh convinced me that our current
> .paraview.version flag isn’t working, but I cannot for the life of me
> remember why.  Also, for all I know, we are going this direction.  I just
> didn’t want to be surprised and wish I had spoken up.
>
> There is my $0.02.
>
> Alan
>
> --------------------------------------------------------
> W. Alan Scott
> ParaView Support Manager
>
> GAITS
> Sandia National Laboratories, MS 0822
> Org 9326 - Building 880 A1-C
> (505) 284-0932   FAX (505) 284-5619
> ---------------------------------------------------------
>
>
>
>
> _______________________________________________
> Paraview-developers mailing list
> Paraview-developers at paraview.org
> http://public.kitware.com/mailman/listinfo/paraview-developers
>