[CMake] Mac OS X Framework support

[E. Wing]

> From: Bill Hoffman
> Hi all,
>
> I am looking for some advise from Mac OS X developers/users.  There
> are some requests for CMake to better support Frameworks.   There
> are two main requests:

OS X developers, please check my bug report responses at these locations:

Bug #: 2250 (http://public.kitware.com/Bug/bug.php?op=show&bugid=2250)
Bug #: 886 (http://public.kitware.com/Bug/bug.php?op=show&bugid=886)

They cover much of this discussion. You can also correct me as necessary.

A quick response to these (most of which has been covered in my bug reports).

> 1. Finding and using existing frameworks.
>
>   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.




I think FIND_LIBRARY can and should be overloaded to handle this case
rather than creating a new FIND_FRAMEWORK API call. (See bug report
).

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

Generally yes, but bear in mind that "standard framework location"
changes once you invoke the 10.4 Universal SDK (or any SDK for that
matter) for Universal Binaries.

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)

Yes,
-framework name is like -lname
-F/path/to/framework is kind of like both -I and -L. There is a tricky
part that comes up in usage patterns, e.g. #include "SDL.h" vs
#include <SDL/SDL.h>. -F covers the latter, but not the former. You'll
probably need me to elaborate on this when the time comes. I have
documented the situation in my FindOpenThreads.cmake or Findosg.cmake
module which uses the latter form. SDL itself actually requires the
former form.


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

Don't worry about umbrella frameworks or indirect dependencies. OpenGL
technically isn't an umbrella framework by the way. I think Accelerate
is the poster child for umbrella frameworks. But I digress. A
framework is just a glorified dylib. The linking patterns aren't any
different, just the flags. If you could link to the dylib before, you
can link to the counterpart framework. For umbrella frameworks, by
Apple's documentation you are not supposed to interact/link with the
subframeworks so treat the top level framework like any other and
ignore the subframeworks.

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


2) Yes, header files will need to be copied into the correct place. It
may seem natural to put this in the install process, but I don't think
it belongs there for several reasons. The first reason is that often I
just build so I can package something up for shipping. I don't really
want to "install". Second, I often need separate projects to reference
others' products directories. In the framework case, I would want the
framework ready to go once it's build and not require some
intermediate install process. Also, since frameworks seem to have some
kind of versioning system, it seems that additional logic should be
supported to ensure these headers are copied to the correct header
version location and the correct symbolic links are set up. This
should be done as part of the framework build and not an install
process somebody needs to setup. (Nobody is going to know how.)

Also there seems to be a notion of public, project, and private
headers in Xcode. Public gets copied into the framework. Project
doesn't get copied. I don't really understand what Private does. But
if these distinctions turn out to be important, the CMake API probably
should be ready to handle this.

So I don't think a new API call would be unreasonable to handle this.
Or conversely, you could overload ADD_LIBRARY to handle this, but it
could get messy.

Additional things to consider...should there be support to handle
-compatibility_version
-current_version
-install_name
-prebind (with -seg1addr <address>)
-integrated release, _debug, and _profile builds in the same framework

Thanks,
Eric