[petsc-dev] Sean is going to love this

[Barry Smith]

   Sean,

    Say I am writing a PETSc package (for any generic packaging system) that will use the MPICH compilers package and the BLAS/LAPACK package (and say, the hdf5 package). How do I indicate to PETSc's configure the information for MPICH, BLAS/LAPACK, and hdf5 so they will be correct for users when they link and run their applications? That is, I don't want to randomly list some hdf5 on the system but is it enough to just list the exact location of the hdf5 I know the package manager will install hdf5 to?

   Thanks

   Barry


> On Dec 23, 2014, at 1:38 PM, Sean Farley <sean.michael.farley at gmail.com> wrote:
> 
> 
> Karl Rupp writes:
> 
>> Hi,
>> 
>>>> The only way to do this, in my experience, is if the package manager has
>>>> something like 'variants' (macports and homebrew have it, at least, I
>>>> don't know about others):
>>>> 
>>>> port install petsc +superlu +mumps +mpich +hdf5 +hypre ... etc.
>>> 
>>> I think variants are a crutch for poor plugin support.  I would prefer
>>> for PETSc to offer these as plugins that can be built and distributed
>>> separately.  Then one can install petsc-superlu, petsc-mumps, etc.
>> 
>> I cannot agree more with Jed on this. Although defining a sufficiently 
>> powerful plugin system for this isn't easy and would require us to 
>> rethink the whole build process, it has the potential of reducing the 
>> number of support requests on building PETSc substantially, just because 
>> inexperienced users can then rely on package managers to setup  a PETSc 
>> tailored to their needs.
>> 
>> Ideally we could preserve the following two options:
>> a) building a 'fat' PETSc lib with packages compiled into libpetsc.so
>> b) a 'slim' libpetsc.so which loads additional packages from e.g. a 
>> plugin folder.
>> We already have a), but I'm not entirely sure whether we can (and want 
>> to?) reasonably support option b) without giving up parts of a).
> 
> While I definitely agree with both Karl and Jed, I think there are
> easier targets to hit to help package managers. The current rough spots
> I deal with are:
> 
> 1) Non-standard prefix
> 
> This is by far the biggest one and would require, I'm sure, much
> discussion. The desired outcome would be a PETSc installation into
> $PREFIX/{bin,etc,include,lib,libexec,man,var,www}. No other directories
> (seems to only be 'conf') would be allowed.
> 
> 2) Multiple installations
> 
> Not as high on the list but still would be nice.
> 
> 3) Don't warn the user about environment variables
> 
> It is an unfortunate fact that some package managers set environment
> variables. I manually use the correct --CC, --FC, etc. but still get a
> warning. I think a simple fix for this is to not show the warning if the
> command line arg is set.
> 
> 4) Better coordination with dependent packages
> 
> This item is hard to implement because it's out of the PETSc team's
> control. For example, packages like SLEPc depend on PETSc but don't have
> as good of a build system. SLEPc can't be built with a version of SLEPc
> already installed in the prefix. This is unnecessarily cumbersome for
> end-users.
> 
> 
> The above points would drastically reduce the friction of having PETSc
> in a package manager.