[petsc-dev] Sean is going to love this

[Barry Smith]

> 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.

  What about share? Isn't that a legal place to put stuff?

  Should we be putting the conf stuff into etc? var? share? Just don't save it anywhere?

> 
> 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.

  Yes, this is silly. I've prepared a branch barry/no-warning-for-overwritten-environmental-variable

> 
> 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.