[Ifeffit] Demeter under El Capitan

Matt Newville newville at cars.uchicago.edu
Sun Nov 15 09:34:33 CST 2015


Hi Joe,

On Fri, Nov 13, 2015 at 12:54 PM, Fowler, Joseph W. <joe.fowler at nist.gov>
wrote:

> Dear Matt,
>
> I’m the official MacPorts maintainer for Demeter. I am an amateur at this
> (i.e., at Ports), but I do have notes somewhere on how to update the port
> file (and, indeed, where to find it in the first place!).
>
>
Thanks!  I'm definitely an amateur at MacPorts too.   I was (and I think
many others were too) very, very grateful when Frank Schima made this port
available, and that you've continued it.


> Concerning the long list of dependencies: I was unaware of the size of
> this list. I agree. It sounds crazy to think that we need THREE non-clang
> compilers to build demeter. I know the fellow who was the previous
> maintainer, and he has a bit of a superstitious belief in the powers of
> gcc. Perhaps he imposed this belief unnecessarily on us all?
>
>
I think if binary installs were the default for El Capitan, we would not
even have noticed.  But yeah, it might be worth investigating what is
really necessary.    I can believe that gcc is needed as llvm doesn't
(AFAIK) include Fortran, but needing 2 llvms and 2 gccs probably isn't
needed.


> It sounds to me like you understand the internals of what demeter uses and
> how, much much better than I do. Let me suggest that you either contact me
> privately OR file a trac ticket at MacPorts about this. Either way, include
> details of what you think plausibly might be false dependencies. Of course,
> we’ll also want to add the new Perl dependencies that you pointed out.
> Perhaps then I can patch the port file and get your assistance in testing
> it in some way? Once we have a patch we like, I don’t have the powers to
> commit it to the MacPorts repository directly,
>
but I can certainly make a request for a commit (they are pretty fast and
> responsive about that).
>

OK.  I really don't know that much about how MacPorts works, but I've used
it many times over the past few years to try installing various stuff.

I don't know where the PortFiles actually live or how one might update
them.  I remember seeing these in the past, and that they weren't too
painful as build scripts go, but all the links I see to them now are dead.
I haven't investigated in detail.  Do you know where these are kept?  It
would be nice to at least add the couple perl modules that are needed and
not included in the dependency list.



> I’d like to comment also on the time it takes to install MacPorts. The
> whole MacPorts concept supports installing from source AND installing
> pre-built binaries. The catch (as I understand it) is that the server
> resources that they use to build and serve the binaries are donated by a
> large corporation (one with a strong interest in selling more Macintosh
> computers, naturally). Thus the open-source Ports team cannot simply make
> the binary “buildbots” appear at will. An early adopter of an OS X version
> has to install every port, even the incredibly complex ones, from source.
> Again, I could be wrong, but I think that El Capitan is still in this
> state. See https://trac.macports.org/ticket/48609 and
> http://macports-dev.macosforge.narkive.com/tRq2luOR/el-capitan-buildbot
> for some additional info.
>
>
Yes, I'm sympathetic to the MacPorts developers in this.  They're dealing
with a large vendor not famous for its generosity toward developers of
scientific or open source work, and liable to make huge infrastructure
changes (chipset, compiler tools) between OS versions.   Then again, these
binaries probably need to be generated exactly once per OS version.
Somebody is hosting the source code and Portfiles... its hard to see how
hosting binaries is a significant difference.

More importantly, I think we can't really mean to say that in order to run
Athena on Mac OS X, you have to build gcc from source.   Even if MacPorts
makes it *possible* to do with a single command line, taking many hours to
install is a problem.


> Now, this is not to say that Homebrew is a worse solution than MacPorts. I
> have no basis for comparison (though here is one clue: many packages that I
> use within the Julia language depend on Homebrew for further dependencies,
> and I have noticed that they manage to Just Work). But I did want to defend
> MacPorts from the implied charge that it will always take all users ten
> hours to install a working system. If you can find a Homebrew expert to
> work with and develop a Demeter solution, that’s great. Here in my group at
> NIST, we use MacPorts for so many things that I’m sure we’ll continue to
> maintain the port file for the foreseeable future.
>

If binaries are available from MacPorts, I have no problem sticking with
it.  From my point of view, that would be the easiest solution.  If
Homebrew worked, I'd have no problem using that either.    For Demeter, the
usual challenges are getting gfortran available and getting wxPerl built.
I think Homebrew solves the first but not the second.   Getting wxPerl to
build with Homebrew might be "not hard", but I've had many failures trying
to build wxPerl myself (and followed instructions from many places).  I
think seeing the Portfile and patches used by MacPorts might be very
helpful for that.

--Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://millenia.cars.aps.anl.gov/pipermail/ifeffit/attachments/20151115/7bf2553e/attachment.html>


More information about the Ifeffit mailing list