[petsc-dev] configure failed after update of OSX

[Barry Smith]

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

   Barry

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