[cmake-developers] Linking Apple frameworks

[Brad King]

On 08/07/2017 05:27 PM, Eric Wing wrote:
> I think that would be a mistake because it seems that the only purpose
> of this change would be so you could bypass CMake and try to directly
> invoke some kind of command line invocation on the dynamic library
> inside the .framework bundle.

The ld(1) man page on macOS says that "-framework foo" tells the
linker to search for "foo.framework/foo".  For linking this is very
similar to "-lfoo" searching for "libfoo.so" and "libfoo.a" in the
linker search path.  We discourage the latter because it is hard to
ensure that the proper library will be found.  I think framework
libraries should be linked by absolute path too.

For example, say one has these libraries in frameworks:

    /path/A/foo.framework/foo  # want this one
    /path/A/bar.framework/bar
    /path/B/foo.framework/foo
    /path/B/bar.framework/bar  # want this one

How does one achieve this case with Xcode's abstractions or with
the "-framework foo" flag?  CMake with imported targets already
achieves this, and links via absolute path to each library file.

> be treating the framework bundle as a whole because all parts of it
> are designed to be useful.

In cases where that is needed it is still possible to detect that
a library file is part of a framework.

> The bundle assets like any .nib files and
> the Info.plist are sometimes critical components of the framework. So
> things like copying the whole framework and embedding them in the app
> bundle are important things to do.
[snip]
> But if you did decide to change this, I think it should only happen in
> conjunction of solving the rest of the needed functionality for
> dealing with frameworks, i.e. copying the entire framework bundle into
> the app bundle, codesigning the framework in the app bundle,

We already have ways of doing those things at installation and
packaging time.  Linking the build-tree copy is too early.

-Brad