[Proj] PROJ as embeddable framework for Mac OS

William Kyngesburye woklist at kyngchaos.com
Sat Jan 5 12:43:56 EST 2008

On Jan 4, 2008, at 11:12 PM, Hal Mueller wrote:

> On Jan 4, 2008, at 9:00 PM, William Kyngesburye wrote:
>> 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.
> This sounds like an argument for using @executable_path in the  
> frameworks in that case.
Exactly, that's what the install_name_tool change is doing.

> There are certainly cases where you want to install one copy of the  
> Maptools frameworks in /Library, for all apps to share.  But there  
> are other situations where you want to be independent of the  
> installed environment.  So perhaps 2 different targets are needed-- 
> one embeddable target, and one for system-level installation.

Not really.  I think it's standard practice.  You link an app to the  
installed frameworks, then IF you want to bundle the frameworks, you  
copy them and use install_name_tool.

There may be other frameworks designed only for bundling that already  
have @executable_path, but I made my PROJ framework to be used  
normally as an installed framework.

> For the archives:  data directory ends up being /Library/Frameworks/ 
> PROJ.framework/Resources/proj, for the current iteration anyway.
> Resources/Info.plist, and the proj files themselves (in  
> PROJ.framework/Resources/proj), are world-writeable, and owned by  
> the user who installed them, with a group of "wheel".  I don't see  
> this as much of a security risk, however.
The old Panther/Tiger installers do this - I used the "admin" option  
for generating the installer, which sets ownership to the user that  
installed them.  It looked common and safe to do at the time.  It's  
also easier on me, since I don't have to worry about file ownership on  
my end.

The new Tiger/Leopard installers don't have the middle admin option,  
so I use the root option, which retains ownership as defined in the  
installer.  This means I have to make sure ownership is set correctly  
on my end.

Both require an admin user authentication (not root for the root  
option), the difference is that root *always* asks for authentication,  
whether you are an admin user or not.

In either case, nothing should be world-writable, so I don't know how  
that is happening.

> Thanks for all of your work!
> Hal

William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>

Earth: "Mostly harmless"

- revised entry in the HitchHiker's Guide to the Galaxy

More information about the Proj mailing list