Barry Smith writes: >> 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?
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!
