On Tue, Sep 2, 2014 at 11:43 AM, Barry Smith <[email protected]> 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. 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
