[CMake] Mac OS X Framework support

[Sean McBride]

(resent without attachment, since it was too big apparently)

On 2005-12-21 11:03, Bill Hoffman said:

>  For this feature, it seems that we need a new cmake command.
>  FIND_FRAMEWORK.   I don't think that FIND_FILE or FIND_LIBRARY can
>  be overloaded to correctly handle frameworks.   Also, there may have 
>  to be a ADD_FRAMEWORK_DIRECTORY command.  Although, you could say that
>  only fullpath frameworks found in FIND_FRAMEWORK add the -F, and only
>  if it is not in a standard framework location.  Is this correct:
>    -F/path/to/framework  (this adds the path to a framework and is like
>-I and -L.
>     -framework name  (this is like -l framework)

I only know enough about cmake to build vtk, so I'm not sure I'll have
many useful comments, but...

>  Most frameworks only have one shared library in them.  However, there
>are umbrella frameworks,
>  like OpenGL that have more than one?

Some frameworks can get really big.  The Apple supplied
ApplicationServices.framework for example.  See the attached
screenshot.  The framework itself contains other frameworks, and also
contains 'variants', that is, a debug and profile version of the dylib. 
Users of umbrella frameworks are supposed to consider them opaque however.

>2. Creating new frameworks.  I suppose we could add support for 
>  ADD_LIBRARY(foo FRAMEWORK ${srcs})
>  This would bundle a shared library into a framework as described here:
>  http://developer.apple.com/documentation/DeveloperTools/Conceptual/
>MachOTopics/index.html
>  (see Loading Code at Runtime, Packaging a Shared Library as a Framework)
>  However, I am not clear how the header files would get into the right
place?
>  This almost seems like it should be part of the install process.

I'm not sure what you mean by 'install process' but when building a
framework with Xcode, there is a 'build phase' which copies user-
selected headers into the /Headers folder of the framework.  See:
<http://developer.apple.com/documentation/DeveloperTools/Conceptual/
XcodeUserGuide20/Contents/Resources/en.lproj/bs_build_phases/
chapter_30_section_3.html>

Another thing to know is that dylibs on Mac OS X annoyingly have the
full path of where they are expected to be in the file system when they
are dynamically linked.  Hardcoded paths suck for obvious reasons.  See
'man install_name_tool' or here:
<http://www.hmug.org/man/1/install_name_tool.php>

-- 
____________________________________________________________
Sean McBride, B. Eng                 sean at rogue-research.com
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montréal, Québec, Canada