[petsc-dev] configure failed after update of OSX

[Sean Farley]

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
> to undo. The R/AT&T build of gcc was better, but also installed into
> /usr/bin, and was also a pain in the ass to uninstall.

It's impossible to uninstall since it overwrites gcc binaries. So you
have to reinstall Xcode / Command Line Tools to go back.

The biggest reason I don't recommend the gfortran binary from R or from
hpc.sourceforge.net is that it puts you in a spot of maintaining your
own stack. Now that I've integrated all my custom modifications into
MacPorts-proper, I can finally start pointing people to that.

That's not to say that I think MacPorts is the best solution for
everyone. I just found that I could get MacPorts to do what I wanted
with the least amount of work.

> Having used both MacPorts (2010-2012) and Homebrew (2012-present), I find
> Homebrew to be a better experience, especially if you only need a small
> number of packages for development. MacPorts used to insist on its own
> stack, which meant that if you wanted gfortran, you also had to install
> many other packages.

MacPorts still does this so that it can get a sane stack that is
invariant of OS versions and processor type (we still support ppc
:-(). A year or two ago we got buildbots so that most people can benefit
from binary downloads.

Over the last year, I've finally been able to become maintainer for a
lot (~100) of the scientific packages in MacPorts (including PETSc and
friends) with the goal of improving the 

> I generally developed using gcc 4.2 because I found cross-version linking
> to be a pain in the ass. I've also installed gcc 4.8 via the
> homebrew/versions tap and that's worked well, too.

My problem with homebrew's use of compilers is that I couldn't specify
(easily) a way to install a package with either compiler and then switch
between the two packages (a la PETSC_ARCH).

> Python is sort of broken in both MacPorts and Homebrew. If you look at the
> GitHub issues, there's been a lot of traffic related to Python in Homebrew
> lately because they completely revamped how they handle Python in their
> build recipes, which then broke some Python packages installed via
> Homebrew. Last I checked, Python was more broken in MacPorts and required
> lots of hacks to get things to work, but it's been a while since I've used
> MacPorts. I think the best policy is to rely on the package manager for as
> little Python software as possible, and install the rest of your Python
> stack in an isolated manner; I use pyenv, pip, & virtualenv. Conda sort of
> does something similar, but I feel like conda is a great build system with
> too many other responsibilities.

Woah, woah, woah there. Python is broken? I've been using it in MacPorts
for years with no issues. If you can reproduce anything or point me to
the tickets on trac.macports.org, I can try to fix them.