[Proj] PROJ as embeddable framework for Mac OS
woklist at kyngchaos.com
Sat Jan 5 00:00:38 EST 2008
On Jan 4, 2008, at 5:36 PM, Hal Mueller wrote:
> I need to reconfigure PROJ as an embeddable framework for Mac OS.
> This is so that I can make a drag-and-drop installable app (one that
> does not need an installer, as is recommended by current Apple
> guidelines). The binaries posted on the Kyngchaos site are built as
> system-wide frameworks.
> The Kyngchaos port has this tantalizing note in the ReadMe.rtf:
>> Before linking (or maybe after linking) the framework copy's
>> install_name and library paths should be changed using
>> install_name_tool. A handy relative path that can be used is
>> @executable_path, this is the location of the app executable. So
>> a path to the framework within the app package would be
>> You would have to change the id of the framework, and the
>> dependencies of the framework that are also included in the app
>> package, to be relative paths. This can get messy.
>> Currently there is an additional consideration: the data folder.
>> It is normally hardwired into the library, but there is also an
>> environment variable to override that. It's up to the programs
>> using PROJ to take care of this.
> What exactly do I need to pass as arguments to install_name_tool?
> What -id am I working with?
I guess I was expecting Mac developers to know what they're doing and
how to do this. To change the install_name of the PROJ framework
itself (only do this on your bundled copy of the framework) [I'm not
sure it's critical to do this one]:
install_name_tool -id @executable_path/../Frameworks/PROJ.framework/
to change the embedded path in your app binary:
install_name_tool -change /Library/Frameworks/PROJ.framework/Versions/
4.5/PROJ @executable_path/../Frameworks/PROJ.framework/PROJ /path/to/
To verify the current id and embedded paths to libraries, use otool:
otool -L /path/to/some/library_or_exectuable
For a library (or frmaework), the first item is the library itself
(the id), and is what will be embedded into executables and other
libraries. The rest (or all, for executables) are the linked libraries.
> What are the "messy" dependencies referred to?
As a small example, if you bundle the GDAL and PROJ frameworks. GDAL
also links to PROJ, so you would have to change the references in the
bundled GDAL to use the relative path to the bundled PROJ. The more
interdependent frameworks you bundle, the more changes within those
bundled frameworks are needed.
> What change do I need to make to manage the data folder? What's the
> default as built?
The default is the absolute path to the framework as installed in /
Library/Frameworks. Using a different data folder is something you
would have to look at the PROJ API to find. You app would initialize
(or something like that) PROJ with the alternate data path before
calling the projection functions.
I'm not much of a C programmer, so you're on your own on the PROJ API.
> This would be a lot easier to understand if the build instructions
> were included in the framework. Or are they now included if I do a
> configure/build on the Mac?
It's not in a configure-make build. I currently patch a couple items
to make it endian-agnostic so it can be a universal binary. It's on
my list to push for changes in the PROJ source to take care of this.
> You mentioned that the Xcode project you have posted is not actually
> the project you use to build the framework. I'd really like to get
> a look at the build choices you're making.
Now that I'm done with the bulk of the Leopard update, updating the
Xcode project downloads is next. Stay tuned.
> My app is crashing on framework not found, searching in /Library,
> even though the Proj framework is in the app's Frameworks folder.
> Rather than mucking around with install_name_tool and guessing about
> the data directory, I'd like to build the thing from scratch
> myself. It does not appear to me that what is posted is sufficient
> to do that, based on what I've read and on what you've told me.
Changing the hardwired data path to match your app is probably not
what you want to do - that will tie it down to whatever path you
choose, and it won't be drag-n-droppable to an arbitrary location any
more. Use the PROJ API to set the data path at runtime, as mentioned
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
[Trillian] What are you supposed to do WITH a maniacally depressed
[Marvin] You think you have problems? What are you supposed to do if
you ARE a maniacally depressed robot? No, don't try and answer, I'm
50,000 times more intelligent than you and even I don't know the
- HitchHiker's Guide to the Galaxy
More information about the Proj