[petsc-dev] Sean is going to love this

[Sean Farley]

Barry Smith writes:

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

That's entirely up to you of where to put it. Jed, I'm sure, can advise
on which files in 'conf' to put into etc, var, or share.

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

Awesome!