[petsc-dev] Sean is going to love this

[Sean Farley]

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.