[petsc-dev] configure failed after update of OSX

[Geoff Oxberry]

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.


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

Functionally, that's the same thing. Again, it's been three or four years.


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


That was not my experience.


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

Homebrew and MacPorts use different philosophies. Homebrew relies more on
the system stack, which led to all sorts of problems when Mavericks came
out. Most of these seemed to be due to the clang transition to libc++, or
to C++11. Mike McQuaid, Misty DeMeo, Jack Nagel, and Adam Vandenburg have
been doing an excellent job fixing bugs.


> 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 used to follow that. It seemed like it took a long time for MacPorts to
respond to bug reports, and they weren't particularly keen on external
contributions. I haven't had that issue with Homebrew; all their core devs
are very engaged.


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


You're right; MacPorts does that better. There may be a way to do that with
flags. Some formulas in Homebrew build with gcc instead of clang. At worst,
you could maintain your own taps of formulas that you want to compile with
specific compilers. It would be an interesting idea to pitch.


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

Aron already went over this in his comments on the Scientific Python stack.

I've basically stopped using MacPorts as of two years ago because I found
that to make things work, I had to repeatedly kludge around things, making
building software from scratch quite painful. I think I submitted maybe one
or two tickets to MacPorts, and didn't get much of a response. I don't plan
on resurrecting my old install just to file bug reports. I switched to
Homebrew because the UX in MacPorts was getting miserable, it's written in
Ruby (not Tcl), they're much more welcoming about contributions (submitting
a PR was painless), and there's much more of a community there. I don't
need to kludge things, and they do an excellent job of responding to bugs.

I applaud what MacPorts is doing, and as a former user, my biggest
suggestion would be to make it a little more clear that MacPorts values its
user community. There are some bug reports that go unresolved for a year or
more, which makes it hard to stick with MacPorts if you're one of the users
that keeps dealing with that bug. MacPorts also gives off the impression
that it's hard to contribute (Homebrew has 3450 contributors according to
GitHub, and is GitHub's most starred/forked repo; MacPorts has 182
contributors according to Ohloh). There are a lot of similar complaints in
"Homebrew vs MacPorts" posts, which is why Homebrew seems to be eating
MacPorts' lunch, despite MacPorts' big head start, and initially far
superior feature set.

-- 
Geoffrey Oxberry, Ph.D., E.I.T.
goxberry at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20140128/c077e230/attachment.html>