Mac OS X frameworks for support libraries

[William Kyngesburye]

Ready to be released into the wild.  In a beta sort of way.  The idea  
was to make them more Mac-like - bring them out into the open more,  
not hidden away in some invisible folder, and thus make them more of  
a drag-n-drop install, and hopefully more of a standard for other to  
use in their own software.  While also keeping them easily usable in  
a normal Unix sort of way.  They could be also easily embedded in Mac  
application packages like other normal frameworks.

So far I'm sticking to the basics needed by the various GIS  
applications, and it's Tiger only right now.  It's possible to make  
them Panther compatible, but it's a hassle and I just want to get  
them working and tested first, and get feedback.  All are universal  
binaries.  All can be installed with a simple drag-n-drop to /Library/ 
Frameworks.

Included are:

- Xerces framework - this was easy, there is a framework build in the  
source already

- SQLite3 framework

- FFTW3 framework

- FreeType framework

- UnixImageIO framework - a bit of an experiment.  This is an  
'umbrella framework', loading just the framework is the equivalent of  
loading all the individual libraries, that is all their symbols are  
available directly from the framework.  It's just for image formats,  
and they include GIF, PNG, JPEG, JPEG2000, Xpm and TIFF.  Mostly I  
just wanted to avoid the clutter of many small frameworks.  If this  
doesn't work out, I'll think about doing individual frameworks.  The  
individual libraries are still available within the package for use  
as normal libraries.

- PROJ framework - a big problem was the datum grid files.  The NAD  
grids are constructed at build-time from source ASCII tables, thus  
making them specific to an architecture for endianess.  I patched  
PROJ so that it will read little-endian grid files on both PPC and  
Intel Macs, and do byte-swapping on PPC Macs.

- GEOS framework - the default here is the C API, not C++.  The  
normal C++ library is available as well.  I need to look into the  
possibility of packaging both as an umbrella framework, like the  
UnixImageIO, then both would be available with a single -framework  
GEOS option.  I'm not sure if having C and C++ in the same library  
will cause problems or not.

- GDAL framework - This is similar in scope to the UnixImageIO  
'umbrella' framework, but not an umbrella FW.  All the support  
libraries for the various formats are embedded in the package and can  
be used in the normal library capacity by themselves.


To make them more easily used in Unix porting, there is a 'unix'  
subfolder in the package that will behave as a normal /usr/local sort  
of prefix, so most configure scripts should work without changes.

The exception would be the UnixImageIO framework.  Used as a  
framework, configure would have to be changed so that all tests for  
the various image libraries test the same '-framework UnixImageIO'.   
But in a pinch, the 'unix' subfolder could still be used to get the  
individual libraries.


To go along with these frameworks, there is a new GRASS build  
available.  First, it uses the frameworks above (installed  
separately).  And, it's a double-clickable, drag-n-drop installable,  
Mac application, and of course Universal.  It can be installed  
anywhere, it's not fixed to /Applications and nothing else is  
installed in other locations (like /usr/local).  I decided for now on  
using Abracode's OnMyCommand Droplet as the base for the  
application.  It simply fires up a Terminal to start GRASS in the  
standard CLI way, including starting the GUI (in X11 or Aqua, however  
you have your preference, but it defaults to X11).

One big problem I had to work out - the stroked font files.  Like the  
PROJ datum files, they are constructed at build time.  I did the same  
kind of patch - font files are fixed at little-endian, and the font  
loading routine byte-swaps on a PPC.


The frameworks are mostly movable, given the right processing.  They  
could be altered to be embeddable in another .app package.  Library  
locations are handled by using install_name_tool to change them to  
relative paths.  I'm not sure about GDAL plugins yet.  Other data  
paths have environment and funtion controls to set them.

But, I didn't do this for GRASS since that defeats part of the  
purpose of having libraries or frameworks in known, standard  
locations - reduced duplication, easier to update all applications.   
Why bloat BOTH GRASS and QGIS by 90MB?  And MapServer and PostGIS  
don't really have (and won't have) an application package to put them  
in.


All the utilities that come with the various libraries are also  
available in the Programs subfolder of the framework.  It may mean  
more in your shell PATH, but they're there.


Next, I'll work on rebuilding QGIS to make use of the frameworks.   
Which will make another good test to help iron out usability issues  
of the frameworks.

When they are stabilized, I intend to replace my current /usr/local- 
based installers with the frameworks and switch over Mapserver, PHP  
and Postgres+PostGIS to use them.  I may then work on making them  
Panther compatible if there is enough interest.


That's it for now, but I may have forgotten something.  Try them  
out.  They won't get in the way of the standard installers, and are  
easily removed if desired.  Comments welcome and encouraged.

-----
William Kyngesburye <kyngchaos at kyngchaos.com>
http://www.kyngchaos.com/

"This is a question about the past, is it? ... How can I tell that  
the past isn't a fiction designed to account for the discrepancy  
between my immediate physical sensations and my state of mind?"

- The Ruler of the Universe