[Paraview-developers] [EXTERNAL] Re: ParaView builds, git and versions

[Scott, W Alan]

1) - Sounds OK.  Since I am not sure this will actually work, please test this case before release or ask me to (i.e., client can see outside, server cannot - and then the reverse).  I am thinking this is exactly the failure that I had a few months ago that caused us to put in the .paraview.version hack.

I can live with not changing version numbers.  The reason I often do so is that users run my "master" build, and if Kitware leaves the version numbers where they were last release, it is confusing.  For instance, the 3.14.0 alpha release still says 3.12.0 for users (who are using master - to get at prism features, and testing prism.)  By trying to protect users from themselves, you take a tool away from me (and I know - keep me from hurting myself.)

2) Excellent, most excellent.

Alan

-----Original Message-----
From: Utkarsh Ayachit [mailto:utkarsh.ayachit at kitware.com] 
Sent: Thursday, February 02, 2012 8:55 PM
To: Scott, W Alan
Cc: paraview-developers at paraview.org
Subject: [EXTERNAL] Re: [Paraview-developers] ParaView builds, git and versions

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
>