[Proj] PROJ as embeddable framework for Mac OS

[William Kyngesburye]

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  
>> @executable_path/../Frameworks/PROJ.framework/PROJ.
>>
>> 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/ 
PROJ /path/to/your/application.app/Contents/Frameworks/PROJ.framework/ 
PROJ

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/ 
your/application.app/Contents/MacOS/your_app

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.


and offlist:

> 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  
above.


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

[Trillian]  What are you supposed to do WITH a maniacally depressed  
robot?

[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  
answer...

- HitchHiker's Guide to the Galaxy