On Tue, Jan 28, 2014 at 12:22 PM, Barry Smith <[email protected]> wrote:
> > On Jan 28, 2014, at 12:14 PM, Geoff Oxberry <[email protected]> wrote: > > > > > > > > > On Tue, Jan 28, 2014 at 9:10 AM, Sean Farley < > [email protected]> wrote: > > > > [email protected] 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). +1 I use MattPorts. Matt > > 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. > > [email protected] > > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener
