Re: [Ifeffit] Demeter under El Capitan
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!).
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?
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).
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.
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.
Best wishes,
Joe Fowler
On Nov 13, 2015, at 11:00 AM,
Hi Joe,
On Fri, Nov 13, 2015 at 12:54 PM, Fowler, Joseph W.
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
participants (2)
-
Fowler, Joseph W. -
Matt Newville