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