Creating apps for MacOSX, especially octave.app

[Thomas Treichl]

Hi,

I'd like to summarize our work about "creating an gnuplot.app and octave.app"
resp. a gnuplot.dmg and octave.dmg to provide the Mac users with a ready-to-run
binary release of octave. We started discussion here

   https://www.cae.wisc.edu/pipermail/help-octave/2007-April/003592.html

and somewhen we moved offside list. We made a lot of experiences about creating
apps for Mac and that's why I wanted to post this summary here at the list for
other investigators:

So everything began on a Mac IA32 with OSX 10.4.9 installed, trying to build
(cross-compile) a running binary for PPC users. Cross compilation seems to work
on Mac with option "-arch ppc" on an IA32 machine and the other way "-arch i386"
if you try to compile from a PPC machine. We didn't use a SDK in the hope that
it will work without one. We failed because 10.4.9 comes with
libncurses.5.4.dylib and a lower version is shipped with OSX 10.3.x.

Next we thought giving everybody the newest libncurses (ie. adding this to the
list of packages that octave depends), this did work but then we found out that
libsystem.B.dylib has changed since 10.3.9. And that's where real work then 
began.

We needed to recompile all packages and libraries that gnuplot and octave depend
on. And solving dependencies for cross-compilation and other OS version numbers
is really a great mess. From then we tried to compile with SDK 10.2.8 to provide
users that have 10.2. installed with apps and thought we can also use this
version on higher version OSXs. We failed because SDK 10.2.8 is not shipped with
a valid X11 environment for cross-compilation that is needed to build a
gnuplot.app necessarily for using an octave.app.

So we switched to SDK 10.3.9. This was better and we have been able to create a
working gnuplot.app on a Mac IA32 10.4.9 for 10.3.x PPC users (means that we
couldn't provide 10.2.x users anymore). The build shell script grew from day to
day and meanwhile we have a ugly conglomeration of shell functions, doing ugly
pre-patches, pre-configures, post-configures, pre-makes and so on. (If somebody
is interested in the ugly code then look into the first and second attachment of
this email - but don't expect that this works on your machine, it once again
depends on how your Mac is configured).

Thanks to Paul who had a very very good idea (an this is currently the state of 
the art): We should consider to not solve dependencies ourselves but further use 
already solved dependencies from macports or others. Further we concentrate on 
building the app with the necessary compiled libs and then packaging the app 
into the dmg.

Currently I'm trying to build the Portfile for the macports - having one problem 
but nearly solved. With this email I wanted to tell the Mac users that we are 
working at the topic about providing an octave.app. But it needs some more time, 
we didn't forget about you ;)

Then I've got some open topics (maybe somebody else will give it a try):

- The original octave icon seems to be smaller (even if sized to
  128x128bit) than other Mac icons - they all seem to be nearly full with 128
  pixels in each direction (maybe place a Huxley in the background of the octave
  logo or something like that, or rotate the sombrero so that it seems to be
  larger). Somebody who wants to make an icon please consider to create a new
  one with size 128x128 for the Mac octave.app. Cf. the attached
  OctaveLogo.tiff.

- Ever had a look at a dmg with background image (where it says to drag and
  drop the app into your Applications folder)? I'd like to have an octave
  specific background image for this dmg we create. Designers wanted ;)

- Who wants to create the octave.app for PPC (10.2 or 10.3)? If we are ready
  then somebody should do this job because I only can create IA32 apps.

Meanwhile that's it from my side,
Thomas

gnuplotappmake.tgz
Description: Binary data

octaveappmake.tgz
Description: GNU Zip compressed data