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@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