[GRASS-dev] Mac OS X frameworks for support libraries
woklist at kyngchaos.com
Thu Jul 27 15:37:20 EDT 2006
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/
- Xerces framework - this was easy, there is a framework build in the
- 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
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
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>
"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
More information about the grass-dev