Re: [cmake-developers] Linking Apple frameworks

[Eric Wing]

On 8/8/17, Brad King  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

Re: [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
-- 

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

[cmake-developers] iOS: direction to official support and questions

[Raffi Enficiaud]

Hi CMake ML,

I am quite new to the topic of making toolchain files. However I need to 
build a not so trivial application for iOS and I want to do it with 
CMake, and if possible walk toward an official support of iOS in CMake.


I have looked a bit to the Android toolchains, and I have to say I found 
those quite complicated as a first reading :)


The target application I am building uses Qt and Boost.

So far, I have managed to have an IOS toolchain file that is generating 
a looking good XCode project, that I can compile properly (up until 
signing).


I can share the toolchain file: it is a collection of things I have 
found on the internet, but trimmed from what I think was not necessary. 
It is still in a not so nice state, but I am currently cleaning it.


There are things that I think are weird though:

* I need to have:
```
set(CMAKE_FIND_ROOT_PATH
${CMAKE_IOS_DEVELOPER_ROOT}
${CMAKE_IOS_SDK_ROOT}
${CMAKE_PREFIX_PATH}
/path/to/boost_1_64_0_build/install
CACHE string  "iOS find search path root")
```

where this path is hard coded, and points to the fat static libraries 
prefix path of boost. If I remove this path, FindBoost does not find the 
boost libraries anymore (of course I am passing BOOST_ROOT). In 
addition, I have this:


```
set (CMAKE_SYSTEM_FRAMEWORK_PATH
${CMAKE_IOS_SDK_ROOT}/System/Library/Frameworks
${CMAKE_IOS_SDK_ROOT}/System/Library/PrivateFrameworks
${CMAKE_IOS_SDK_ROOT}/Developer/Library/Frameworks
)

set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
```

this looks ok to me, as we are cross compiling.
Is this a problem of FindBoost, or the combinations of the options that 
are not ok?


* I need to add:
```
set(CMAKE_MACOSX_BUNDLE YES)
set(CMAKE_XCODE_ATTRIBUTE_CODE_SIGNING_REQUIRED "NO")
```

and this comes from https://public.kitware.com/Bug/view.php?id=15329 . 
As I understand it, this is a problem of try_compile: as signing of 
application is required for generating a binary for iOS, this one fails 
very early when CMake discovers the capabilities of the compiler. Some 
people made a workaround by short-cutting the compiler checks, which is 
to me a wrong direction to take. As mentioned in this ticket, the right 
solution would be that the try_compile commands not to require signing 
of the binaries (or sthg similar).

This is explained here: http://public.kitware.com/Bug/view.php?id=12288

* is this one https://cmake.org/Bug/view.php?id=12640 addressed?

* I am seeing exchanges concerning the IOS_INSTALL_COMBINED. Does this 
has something to do with toolchain? What is meant by "installation" in 
this case? Sorry for my naive question, but I do not understand the 
workflow very well.


* how can I have unit tests of the toolchain in a CI fashion. Ideally, I 
would like to have a target cross-compiled with this toolchain, and then 
running the iPhoneSimulator, and check the result (return code, process, 
command whatever).

Does anyone have experience with this?

Thanks,
Raffi




--

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