> On Dec 23, 2014, at 1:38 PM, Sean Farley <[email protected]> > 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.
