Paul,On Apr 8, 2007, at 10:11 AM, Paul Kienzle wrote: On Apr 8, 2007, at 7:44 AM, Marius Schamschula wrote:
I also had a look at the Mac installation page a couple of days ago, and noticed that there was no mention of MacPorts < http://www.macports.org/>. They currently have octave 2.9.9 and octave-forge 2006.07.09.
Fundamentally it is possible to build octave as a .pkg or .mpkg for Apple's Installer.app. I did this several years ago. I later pulled this .mpkg due to the duplication of effort with my normal .tar.gz based install system. The real problem is coming up with the file list. You can't just package up everything in /usr/local, so you need to build into a separate tree. This is a bit of a chore, since you have to add a lot of configuration arguments and environmental variables. My coworkers at Boston University use this approach for CISM_DX - which currently includes octave 2.1.72 - see < http://www.bu.edu/cism/cismdx/>. Alternately, you can use a utility to find changed files, such as afick. However, it may miss files that were not overwritten during the install process.
You could also build octave as an app. The octave libraries can be moved so long as you set the appropriate variables before running such as DYLD_LIBRARY_PATH to point to the octave libraries and the appropriate m-file path on octave startup. You can even include gnuplot and aquaterm in the bundle for an extra couple of megabytes so that the user doesn't have to work to find them. You can similarly hack mkoctfile so that it runs from the octave prompt and can find the header files (with the new package manager this is probably available already), so that users can write their own extensions and download packages.
I've looked at this approach in the past. This has been done for Gimp and several other open source packages. The problem is the Voodoo associated with the DYLD_LIBRARY_PATH. Setting the environmental variable can cause problems. To build a self contained app, you have to manually change the internal paths after building such that everything is on a relative path (dylibs are on absolute paths by default, run otool -L against a dylib). The library names change every time a package is updated, so this is very difficult to automate. Frankly, I hate messing with it, just as much as Frameworks get in the way to a point where I'd rather rebuild a library than build against a Framework installed by the OS. I gave up on the app approach since I have things working in the classical *NIX style on the command line.
The only part I don't know how to do is start a terminal with octave running when you click on the app, and figuring out how to set the proper working directory. If nothing else you could probably embed the Terminal app in the bundle as well, or alternatively use one of the octave IDEs that run on the Mac.
Note that I built double clickable Icons for CISM_DX (see my earlier post, quoted above) to start octave and OpenDX which take care of launching either the terminal or X11 respectively. These are based on examples I found on the web and could be easily adapted. Marius -- Marius Schamschula Webmaster
The Huntsville Macintosh Users Group www.hmug.org
webmaster at hmug dot org marius at schamschula dot com
|
PGP.sig