On Jul 10, 2014, at 2:37 PM, Adam Dershowitz Ph.D., P.E. <de...@alum.mit.edu> wrote:
> > > On Jul 10, 2014, at 5:20 PM, Jerry <lancebo...@qwest.net> wrote: > >> >> On Jul 10, 2014, at 6:08 AM, Adam Dershowitz Ph.D., P.E. >> <de...@alum.mit.edu> wrote: >> >>> >>> >>> On Jul 10, 2014, at 1:41 AM, Ryan Schmidt <ryandes...@macports.org> wrote: >>> >>>> >>>> On Jul 9, 2014, at 11:01 PM, Adam Dershowitz <de...@alum.mit.edu> wrote: >>>>> >>>>> No. They do use existing standard ports. So openmodelica does require >>>>> certain macporys dependencies, not its own separate copies. I don't know >>>>> about Qt, and don't have access to check at the moment. But, my guess is >>>>> that they are using the standard macport Qt, not a redundant one. I know >>>>> that for a bunch of other things they just use the macport port so there >>>>> is no redundancy. They have even worked on some ports to get them >>>>> upgraded to get things to work together. The only reason that I could see >>>>> any redundant versions is if they require some specific version that >>>>> macports doesn't have. And doing that would be tricky to avoid any >>>>> conflicting versions. >>>>> I think that you have a bit of a misunderstanding. You could, for example >>>>> create your own port file of something, and just keep that file locally >>>>> (see the macport instructions). That port could then have other >>>>> dependencies that are included with macports. All they have done is put >>>>> their port file, instead, on their server, and you can then use it by >>>>> adding it to your sources file. No redundant files involved, and no extra >>>>> disk space. A port file is just a text file that explains where to find >>>>> files, and how to build. Part of that "how" is what other ports are >>>>> required to be installed. If someone were able to copy the current port >>>>> file from their server to macports the build would be identical in size >>>>> and dependents. >>>>> My guess is that the reason they haven't done that is because the release >>>>> version is a bit behind, and the develop version is changing every day. >>>>> But I don't know for sure. >>>> >>>> Adam, Jerry is correct. The binary distribution provided on the >>>> openmodelica web site, though created with MacPorts, installs the >>>> MacPorts-provided dependencies into a separate prefix /opt/openmodelica, >>>> not the normal MacPorts prefix /opt/local. This is exactly as we at >>>> MacPorts would recommend for a third party wanting to distribute a >>>> standalone installer so that it will not conflict with an existing >>>> MacPorts installation. Jerry is correct that, would the openmodelica >>>> developers instead submit their portfile to be included in the standard >>>> MacPorts ports tree, then openmodelica could be installed by using >>>> existing MacPorts dependencies (in /opt/local or whatever the user's >>>> prefix is), and would not need separate copies thereof in >>>> /opt/openmodelica. The user can already accomplish this however by setting >>>> up a second sources entry in their sources.conf pointing to the >>>> openmodelica rsync server, which is in fact what Jerry had done and is >>>> what prompted him to begin this thread, when the openmodelica rsync server >>>> was temporarily offline. >>>> >>>> You can read more about all of this at: >>>> >>>> https://www.openmodelica.org/index.php/download/download-mac >>>> >>>> >>> >>> >>> Perhaps we just were not communicating clearly. I was not talking about >>> the binary, and I didn’t think that Jerry was either (perhaps I am >>> mistaken). He was suggesting that they make an “official port file” and >>> they already have one. They just keep it on their own server. The >>> instructions on that page make it clear, as you said. The reason that I >>> believe the binary had nothing to do with Jerry’s comments is because if he >>> was using the binary he would not have run into the rsync problem when >>> their server went down. That problem was purely from trying to download the >>> source port file, which, as I have said, takes up the same amount of space >>> whether on their server or the macports server. >>> I did verify that their port does just use the existing qt4-mac port, for >>> example, so their is no redundancy in Qt, as Jerry had suggested. But, I >>> do understand that if someone installs the binary, then they are not using >>> Macports for the install, and will be downloading a whole bunch of stuff >>> that they might already have. >>> The port file for openmodelica-devel changes many times a day. So, I >>> assume that they have a script that auto generates it, on their server, for >>> every change in their development branch. I have been using their >>> development branch with macports, for a while now, and it has tended to >>> work well. As it is devel, there are occasional problems, but they have >>> always been very quick to fix them, and keep it building. >> >> >> Well, let's all agree that I barely know what I'm talking about. >> >> My file at /opt/local/etc/macports/sources.conf contains two non-comment >> lines: >> rsync://rsync.macports.org/release/tarballs/ports.tar [default] >> rsync://build.openmodelica.org/macports/ >> >> I don't know how the second line appeared since I _think_ I have not messed >> with openmodelica since last installing MacPorts. Should I remove the second >> line? >> >> >> >> The following is a history of openmodelica wrt Macports on my machine. I >> suggest that you skip it. >> >> So let me take another crack at what I experienced 2+ years ago. I'm >> reconstructing and vastly simplifying from notes and forum posts. >> >> In September, 2011, I downloaded from openmodelica.org a .pkg or .mpkg which >> they referred to as a binary installer. I did not have MacPorts installed at >> the time. It created /opt/openmodelica (I had no /opt at the time) >> containing 631 MB. The installer screen had a message, "This package was >> made with MacPorts. http://www.macports.org";. Some executables were also >> installed in /Applications/MacPorts/ but I don't know how large it/they were. >> >> In April, 2012 (yes, I keep notes of unusual software installations), I >> tried to install MacPorts, specifically py-spyder. The attempt failed, with: >> >> Error: Target org.macports.activate returned: Image error: >> /Library/LaunchAgents/org.freedesktop.dbus-session.plist already exists and >> does not belong to a registered port. Unable to activate port dbus. Use >> 'port -f activate dbus' to force the activation. >> Error: Failed to install dbus >> >> I looked at /Library/LaunchAgents/org.freedesktop.dbus-session.plist and >> found that it is an alias that pointed to >> >> /opt/openmodelica/Library/LaunchAgents/org.freedesktop.dbus-session.plist >> >> This effort and related discussions continued in several ways for several >> days until the openmodelica guy started suggesting arcane ways to overcome >> the problem and MacPorts people suggesting removing openmodelica in order to >> succeed with py-spyder. >> >> At one point, the maintainer at openmodelica.org said, "...If you'd like to >> maintain OpenModelica on macports.org, feel free. It's too much work for me >> (I won't accept to maintain the horrible paradiseo and rml-mmc dependencies >> on macports)." >> >> In August, 2012, I noted to myself that I had grown weary of the process >> (and never got openmodelica to run). I noticed that Wolfram was offering a >> version of OpenModelica called SystemModeler that is integrated with >> Mathematica, so that seemed like a relatively good approach even though I'm >> a self-funded researcher and it was $ off my beer budget. I believe that the >> Wolfram product uses an old version of openmodelica and they don't like to >> upgrade stuff frequently (or even issue bug fixes but that's another matter). >> >> Jerry >> _______________________________________________ > > > If you don’t plan on using OpenModelica, then yes, you should remove the > line: rsync://build.openmodelica.org/macports/ (although there is little > harm in having it remain) while if you want to try using it, you should > leave that line. > I believe that once you add that line to your sources.conf it would remain > through reinstalls of MacPorts. It would only go away if you deleted that > line, or deleted your full /opt/local directory structure. So, you probably > just added it years ago. > I don’t know how OpenModelica was two years ago. But, my impression is that > back then it was really alpha level software, with a bunch of issues, and > that since then they have improved it greatly. Perhaps a year ago, they did > not have a Mac available to test out builds, and since then they have a Mac > and a build farm that does nightly builds for Mac, Linux and Windows. > My experience is that now just adding the line above to souces.conf and then > sudo port install openmodelica-devel does now work fine, and the application > itself also works well. That's great to know. I had no idea that that could work—I assumed that since OM is not listed at macports that I couldn't install that way. > I am not a OpenModelica developer, but the developers have always gotten > back to me in a day or two when I have run into Mac issues, and fixed them > quickly. So, I have been impressed, and just want to acknowledge that. Also good to know. My need for OpenModelica/SystemModeler is still in my future but it's good to know I can get a recent version if the Wolfram product seems stale. Jerry > > Best, > > —Adam >
_______________________________________________ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
