On 8/8/17, Brad King <brad.k...@kitware.com> wrote:
> 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
>
So two more quick points.
1) The absolute path this is actually a problem, especially for iOS
because of the way the SDK stuff works. There are two subcases where
the CMake behavior breaks down:
a) When the user needs to change the target SDK on the fly
a) When switching between simulator and device build, this
effectively changes the root of the SDK on the fly so different
binaries can be pulled in to link to. Unfortunately Apple doesn't use
their fat binary concept here, and actually causes problems for 3rd
party iOS frameworks because if you try to build a fat dynamic
library, the app store rejects it because you have simulator
architectures.
2) The packaging and installation conventions CMake imposes are just
plain wrong for Apple development. It needs to be an atomic piece as
part of the main build phase, not a two phase thing. Xcode knows it
must bundle all the resources, bundle the frameworks, manage the
sandboxing entitlements, and do all the codesigning in the correct
order and this is built into Xcode's build process. The CMake way
breaks this and basically gets in the way of developing any proper app
that would need to be shipped on the App store. It also breaks a lot
of the tooling around it since it assumes that once you hit the Run
button, Xcode puts everything together correctly. This can affect
everything from trying to test InAppPurchase features to debugging
with Instruments. (And again, this is problematic for iOS which shares
the same expected atomic workflow.)
-Eric
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
