new build system

[Barry Smith]

On Wed, 13 Jun 2007, Lisandro Dalcin wrote:

> The new PETSc build system make changes to current directory
> structures (regarding 2.3.x series).
> 
> 0 - The Main Goal (in my view)
> ==================
> 
> The main goal of such a change should be to make life easier for
> packagers and users of those prebuilt packages, and facilitate PETSc
> availability in many Linux distributions. I this is not the main goal,
> I see no point in changing things.

  Absolutely!
> 
> In order to achieve the main goal, we have to respect standard
> filesystem structures.

   Yes

> Additionally, IMHO we should not make a mess in
> those standard locations with many headers and libraries.
  
  I agree, but standard filesystem structures may dictate dumping
directly into lib and include, thus making them a mess.

> 
> 1 - Default PETSc package
> ================
> 
> Let's now assume that a 'default' PETSc package for some Linux distro
> does not use external packages other than BLAS/LAPACK and MPI.
> Regarding the previous paragraphs,  perhaps the better options is to
> have:
> 
> prefix/bin
> prefix/include/petsc   -> all PETSc headers
> prefix/lib/petsc        -> all PETSc libs (*.a and *.so)
> prefix/share/petsc/config     -> all configuration (old bmake stuff)
> prefix/share/petsc/<other>  -> other stuff (like docs)
> 
> Note there is no need (I am right?) for a 'bin' directory in this
> setup (I mean, with no external packages), but we can add in the near
> future a 'petsc-config' script for querying installation path, version
> and patch, etc.
> 
> This structure is standard and it does not mess 'include', 'lib', and
> 'share' with PETSc stuff.
> 
> 2 - Optional PETSc package
> ================
> 
> Now, suppose some packager whants to make many variants (here variant
> is different $PETSC_ARCH) of PETSc available for 'power' users. Each
> variant include a different set of configuration options and extenal
> packages. In such an scenario, perhaps a good location to put petsc is
> in 'opt' using a deep structure:
> 
> /opt/petsc/<version>/<variant>/bin
> /opt/petsc/<version>/<variant>/include/petsc
> /opt/petsc/<version>/<variant>/lib/petsc
> /opt/petsc/<version>/<variant>/share/petsc/conf
> 
> I think the duplication of headers and conf data is irrelevant here.
> 
> 
> 3 - Continuing the discussion
> ==================
> 
> FIRST, I invite all you to firt discuss all this and define a good and
> standard structure for an 'installed' petsc. Perhaps we should invite
> packagers (like Stephan) to joing this discussion.

  It bothers me greatly to sometimes have PETSc installed in /usr/lib/petsc..
and other times in /opt/petsc/.... Having two models is confusing.

Why don't we always dump into /opt/petsc? Everything is easy! Why make
life complicated by also supporting the /usr/lib approach? Do 
some systems/people not use the /opt?

  Barry



> 
> NEXT, build system sould be updated to be able to manage 'installed'
> versions and 'build' versions... This would possibly make the 'build'
> directory structure ugly, but IMHO this should not be excuse.

  I do not understand what you are saying. what do you mean by 
"build system"? Do you mean the PETSc makefiles? What do you mean by
"manage"? Create them initially or manage updates to the installed
version over time?

   Barry
> 
> 
> 
>