[petsc-dev] configure failed after update of OSX

[Sean Farley]

bsmith at mcs.anl.gov writes:

> On Jan 28, 2014, at 12:14 PM, Geoff Oxberry <goxberry at gmail.com> wrote:
>
>> 
>> 
>> 
>> On Tue, Jan 28, 2014 at 9:10 AM, Sean Farley <sean.michael.farley at gmail.com> wrote:
>> 
>> goxberry at gmail.com writes:
>> 
>> > To echo what Aron said, I wouldn't point people at the
>> > hpc.sourceforge.netbuilds. They do install directly into /usr/bin, and
>> > it's a pain in the ass
>> 
>> Satish is probably right here about the build location. It's been three or four years since I've installed it this way. I stand by that it's still difficult to revert. I actually tried this method because of PETSc and regretted it because the experience was terrible. Using a package manager is more maintainable, and I think PETSc's recommendation of the hpc.sourceforge build is a disservice to both users and to PETSc's excellent reputation.
>
>    I think package managers for Mac OS are a disservice to the community and recommend not using them. (See all the discussions in these emails about how they fuck up).

Sigh. It is this type of curmudgeon behavior that pushes away people
from helping out with these type of projects. Packagers are just
volunteers and to estrange the current three (yes, three) would be
unfortunate. Not many (read: none) of the other devs care about having
multiple compilers (thanks, fortran) nor pandering to the scientific
community's lack of good software practices.

It is no secret that MacPorts has historically flubbed on lots of
PETSc-related issues. I have been trying to change this perspective
but this email thread pretty succinctly explains what makes my job
difficult.

Just look at how difficult it is to install these packages: superlu,
superlu_dist, metis, parmetis, scotch, scalapack, and mumps.

The comments here do nothing but drive away users and frustrate
potential collaborators. Not just for PETSc but for any project that
depends on PETSc (SLEPc, FEniCS, MOOSE, etc). The true disservice to the
community is forcing each user to manage their own packages.

Instead of criticizing here, the energy could be better spent by
contributing.