On Apr 13, 2007, at 5:14 PM, Thomas Treichl wrote: Paul Kienzle schrieb: On Apr 8, 2007, at 3:21 PM, Marius Schamschula wrote: Paul, On Apr 8, 2007, at 1:59 PM, Paul Kienzle wrote: On Apr 8, 2007, at 11:40 AM, Marius Schamschula wrote: Paul,
On Apr 8, 2007, at 10:11 AM, Paul Kienzle wrote: You could also build octave as an app.
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.
DYLD_LIBRARY_PATH worked for me when I tried it three years ago.
I didn't say it doesn't work. However, you got to be very careful, otherwise you can break any and all applications (i.e. something akin to rm when used as -Rf from root - fortunately you can undo this). I vaguely remember setting DYLD_LIBRARY_PATH for a particular package, which worked, but most everything else didn't. Setting DYLD_LIBRARY_PATH is a kludge, it should not be needed.
The environment variable will only affect the current shell. By putting it in a script you restrict it so it won't break the rest of the system. The only danger I can see is when the user runs a shell command from octave since it inherits the octave environment, but we should be able to remove DYLD_LIBRARY_PATH from the environment once octave is running, so even that danger is minimal. Since all of this is happening inside an app, most users won't notice anything is being done. - Paul
Hi everybody,
imagine, I successfully build my first binary Octave.app for MacOSX IA32! At the moment I try to compile the same for the PPC users, but don't wait, I don't know if this cross-compilation will succeed. So what the Octave.app does, it's on my Desktop, starts up the X11 environment when I do a double click, after that the xterm is opened and in the xterm there is octave (without calling bash or another shell before). It seems that octave is a real MacOSX application. But now I've got a lot of questions to make a more better Octave.app resp. a cleaned up version:
Paul, what exactly do you mean with:
> The only danger I can see is when the user runs a shell > command from octave since it inherits the octave environment, <snip>
you have some sample for me to run out of the Octave.app?
Is sed needed to run octave (not just for compiling octave), so do I need to add the new compiled versions to the Octave.app?
Are these programs needed to run octave (not to compile octave, cf. OctaveForMac on the wiki): - bison
- gawk
Bison is a build tool and should not be needed after installation. gawk is only needed for installation. It is used along with perl and sed to run build and installation scripts. In a .app you should not need any of these. - readline
Absolutely necessary to run octave. Apple's readline is only related by name, but not by functionality. What about the programs in the background for using "help"? Which programs are these and must these be added to the Octave.app? Or we could check if they are there before starting octave and open up a warning dialog or something like that? The same with gnuplot!?
Current releases of Mac OS X (10.3/10.4) have a version of texinfo pre-installed albeit not the latest. Linking octave: I think a dynamically linked Octave mustn't work on other computers isn't it? So I need to use --disable-shared and --enable-static?
This is backwards. Static linking is strongly discouraged under Mac OS X and may cause compile problems with octave. You certainly don't want to use both... - What about the idea of the universal binary - throw it away or give it a try?
Should be possible. - Who is interested to host MacOSX binary on server? OctaveForge?
Is somebody really interested in using a binary MacOSX Octave.app or am I doing something for the trash?
If I had more time, I would have already tried to implement this. There will be number of potential octave users on the Mac platform who don't want to use MacPorts, Fink or build octave from source.
Marius -- Marius Schamschula Webmaster
The Huntsville Macintosh Users Group www.hmug.org
webmaster at hmug dot org marius at schamschula dot com
|
PGP.sig