[petsc-dev] merging PETSc and BuildSystem packages

[Barry Smith]

On Sep 2, 2014, at 11:50 AM, Matthew Knepley <knepley at gmail.com> wrote:

> On Tue, Sep 2, 2014 at 11:43 AM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> 
>    Can we “merge” the BuildSystem and PETSc package.py and put all the packages/*.py together in one place?  It seems arbitrary in which each package is and having these differences make enhancing and simplifying the system difficult.
> 
>    Here specifically is what I propose.
> 
> 1) Introduce a CMakePackage much like GNUPackage for packages that use CMake
> 
> 2) “Fix” all the BuildSystem/config/packages/*.py to modern standards using GNUPackage and CMakePackage when possible. This would include adding MPICH.py and OpenMPI.py to handle those installs.
> 
> 3) Move the PETSc/packages/*.py one at a time over to the config/packages.py location, updating to follow modern standards and use GNUPackage or CMakePackage as needed.
> 
> The barrier here has always been the assumptions made about types. The PETSc package knows whether it is begin compiled
> for "single". I don't think even PETSc wants this in the long term since eventually we have to have a multiprecision interface, however
> imperfect. Jed is peppering the Elemental list with this kind of thing right now.

   Most other packages (superlu etc) used to build all the types all the time (single, double, complex, real) and have different symbol names for the functions. BUT now with other packages adopting the possible use of 64 bit integers they have actually switched to the PETSc model for that, they don’t have different symbol names, instead you decide at “configure time” to build everything with 32 bit or 64 bit integers.

   Agreed this is one of things we need to fix up.



> 
>    Matt
>  
>    Now, about versioning? I think it is too much to maintain full information about versions of all packages and which work with which but the current system where we keep no information is troublesome (for example MUMPS doesn’t currently work in our suite). BuildSystem should at least know which combinations are not currently workable and why.  Currently we track the “latest” version of some packages but for other ones we don’t always update to the latest so we are somewhat as guilty as the MUMPS folks.
> 
>   Barry
> 
> 
> 
> 
> -- 
> What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.
> -- Norbert Wiener