[petsc-dev] configure failed after update of OSX

[Geoff Oxberry]

On Tuesday, January 28, 2014, Satish Balay <balay at mcs.anl.gov> wrote:

> On Tue, 28 Jan 2014, Barry Smith wrote:
>
> > >
> > > 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).
> >
>
> My view is: anyone using OSX has bought into the idea of not having a
> proper package management system. [yeah you get easy-install packages
> - but most of them don't have an proper way to uninstall - unless its
> an "osx-app" which you can drag/drop into trash]
>
> gfortran from hpc.sourceforge does things "no worse" than most packages
> that are available for OSX.
>
> Its not obvious - but one can use the file listing from the tarball [as
> mentioned in my previous e-mail to uninstall]. And is tucked away
> in /usr/local - so it doesn't do any damage like other packages.


If you follow the relative install paths, yes, your method does the job.
It's what I did, with some testing, and then I reinstalled the XCode
Command Line Tools. As long as a user is careful, no harm done; it's also
easy to mess up. You could do something similar via lsbom for packages in
OS X and/or delete via the package identifier using pkgutil and largely
only leave behind plist files. This method is what homebrew-cask uses for
managing OS X binaries.


> [for eg: install mercurial for OSX - and see if you can uninstall it]


For Mercurial, I'd install & uninstall via pip and a virtualenv. Your point
is well-taken for packages in general, and can still be managed (see
above). Uninstall apps will also do the job.


> I agree a better package management system [aka macports/homebrew]
> should be preferable. But with all the wierd issues that keep comping
> up with users using macports on petsc lists - I can't convince myself
> that it is a better recommendation.
>
> perhaps homebrew is better - I don't know.


You guys do the support work (and do a good job of it), so I defer to your
judgment here. My opinion was borne out of a bad experience and trying
several methods of installation; I apologize for the brief burst of
impertinence.

I would not recommend MacPorts either; I don't use it. Sean knows more
about this than I do and can better defend MacPorts.

With Homebrew, it should be possible to replicate the current
recommendation and only install six additional packages (cloog, gmp, isl,
mpfr, libmpc, and pkg-config).

Mixing gfortran 4.8 with the rest of the gcc 4.2 or clang 3.3 stack can
also be tricky, which was my point about different compiler versions. SciPy
recommends the AT&T build and states that problems may arise with the
hpc.sourceforge build; as you pointed out, this version causes problems for
PETSc. So I tend to use multiple builds of PETSc in different PETSC_ARCH
directories; one of these builds is a gcc 4.8 build because PETSc is
relatively self-contained (which is a testament to your design and build
system), so I'm not terribly worried about system library conflicts.

My Python rant is not a good argument for hpc.sourceforge (or against
package managers) because sitewide installs of interpreted language
packages -- especially via an OS package manager -- should be minimized,
regardless of operating system or distribution. Otherwise, you run into
problems like pip trying to overwrite system libraries.

I would aswell recommend virtualbox with linux as a superior choice.
>
> Satish
>

Probably the best choice. Even then, some can't run virtual machines (I
can't at work), and OS X is a lesser evil than a Windows machine.

As Jed points out, manual installation is difficult to maintain. Fixing
a package manager is my best path forward (not getting a different job);
they're not perfect, but they won't get better unless people work on
them. I agree with Matt that most of this discussion is ideology.


-- 
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/acc924ba/attachment.html>