[petsc-dev] configure failed after update of OSX

[Matthew Knepley]

On Tue, Jan 28, 2014 at 12:22 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:

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


+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.
> > goxberry at gmail.com
>
>


-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20140128/f4d65b53/attachment.html>