<div dir="ltr">There's discussions related to problems with linking and multiple architectures in the following recent thread too:<div><br></div><div><a href="http://public.kitware.com/pipermail/cmake-developers/2017-August/030192.html">http://public.kitware.com/pipermail/cmake-developers/2017-August/030192.html</a><br></div><div><br></div><div>Eric highlights a number of similar issues to those you've mentioned. Have a read through the whole thread to get a deeper understanding, but it sounds like you're already familiar with at least some of the problems.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 16, 2017 at 10:45 AM, Raffi Enficiaud <span dir="ltr"><<a href="mailto:raffi.enficiaud@mines-paris.org" target="_blank">raffi.enficiaud@mines-paris.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Le 10.08.17 à 17:04, Brad King a écrit :<span class=""><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 08/08/2017 08:08 AM, Raffi Enficiaud wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I have looked a bit to the Android toolchains, and I have to say I found<br>
those quite complicated as a first reading :)<br>
</blockquote>
<br>
This note may help:<br>
<br>
<a href="https://gitlab.kitware.com/cmake/cmake/issues/16708#note_300971" rel="noreferrer" target="_blank">https://gitlab.kitware.com/cm<wbr>ake/cmake/issues/16708#note_30<wbr>0971</a><br>
</blockquote>
<br></span>
Hi,<br>
Thanks for the link and the answers!<span class=""><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I don't think iOS will need all the toolchain and stl selection logic.<br>
<br>
Ideally CMake would gain iOS platform modules such that one could<br>
set CMAKE_SYSTEM_NAME to `iOS`.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
set(CMAKE_FIND_ROOT_PATH<br>
${CMAKE_IOS_DEVELOPER_ROOT}<br>
${CMAKE_IOS_SDK_ROOT}<br>
${CMAKE_PREFIX_PATH}<br>
/path/to/boost_1_64_0_build/i<wbr>nstall<br>
CACHE string "iOS find search path root")<br>
```<br>
<br>
where this path is hard coded, and points to the fat static libraries<br>
prefix path of boost. If I remove this path, FindBoost does not find the<br>
boost libraries anymore (of course I am passing BOOST_ROOT). In<br>
addition, I have this:<br>
<br>
set(CMAKE_FIND_ROOT_PATH_MODE_<wbr>PROGRAM ONLY)<br>
set(CMAKE_FIND_ROOT_PATH_MODE_<wbr>LIBRARY ONLY)<br>
set(CMAKE_FIND_ROOT_PATH_MODE_<wbr>INCLUDE ONLY)<br>
</blockquote>
<br>
These last three lines tell the find commands to only look at<br>
paths re-rooted under CMAKE_FIND_ROOT_PATH and CMAKE_SYSROOT.<br>
If boost is not under one of those then it won't be found.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
set(CMAKE_MACOSX_BUNDLE YES)<br>
</blockquote>
<br>
Is it possible to build any binary of any form on iOS without this?<br>
</blockquote>
<br></span>
You're right, I do not think this is possible.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If not then the iOS platform modules should set something to tell<br>
the generators that this should always be enabled.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
set(CMAKE_XCODE_ATTRIBUTE_CODE<wbr>_SIGNING_REQUIRED "NO")<br>
</blockquote>
<br>
Similarly for this, but perhaps only during `try_compile`.<br>
</blockquote>
<br></span>
What I understand from this variable is that, it sets the default of CODE_SIGNING_REQUIRED to "NO", and this can be overriden per target by setting the XCODE_ATTRIBUTE_CODE_SIGNING_R<wbr>EQUIRED target property to something else.<br>
<br>
Is that correct?<br>
<br>
I believe that for iOS developments, the default should rather be the opposite, and the try_compile should be informed of not trying to sign the app, via "some mechanism" as you suggested.<br>
<br>
Concerning this "some mechanism" part, what do you have in mind? Would it be an extra variable like CMAKE_XCODE_ATTRIBUTE_CODE_SIG<wbr>NING_REQUIRED_IN_TRY_COMPILE ?<br>
<br>
What I fail to understand here, is the purpose of the "try_compile" that is performed at the beginning. Isn't this try_compile supposed to compile source files only, without trying to link nor bundle anything? If this is the case, signing the result is irrelevant, and I do not understand why this fails.<br>
<br>
If you have an idea, good, otherwise I believe this is secondary right now.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm not familiar enough with iOS development to answer the rest of<br>
your questions.<br>
</blockquote>
<br></span>
Me neither :)<br>
<br>
Currently the main issue I am seeing is the multiarch/multisysroot target of XCode that is kind of lost when using CMake. By multiarch/multisysroot, I mean that Xcode is able to switch from iPhoneSimulatorXY to iPhoneXY without changing the project, and within the same view.<br>
<br>
The switching means changing the target architecture, as well as changing the SYSROOT. I checked the command lines emitted by XCode, and it changes the "-isysroot" flag based on the type of target.<br>
<br>
>From the posts I can read online, this is causing a lot of troubles, especially when linking with libraries.<br>
<br>
For users' libraries, the workaround is to have fat libraries by combining all the target archs into one with lipo. The compilation is done with different "-isysroot" then. What I understood is that Apple is discouraging this, and this is for me not a proper solution neither, but might work.<br>
<br>
The real problem seems to be when linking to system libraries, those that are under sysroot, and I cannot find a good answer to this.<br>
<br>
Example:<br>
<br>
Suppose in the toolchain file, we have something like this, where CMAKE_IOS_SDK_ROOT depends on the fact that we use the simulator or not:<br>
<br>
'''<span class=""><br>
set(CMAKE_FIND_ROOT_PATH<br>
${CMAKE_IOS_DEVELOPER_ROOT}<br>
${CMAKE_IOS_SDK_ROOT}<br>
${CMAKE_PREFIX_PATH}<br></span>
/some/other/path<span class=""><br>
CACHE string "iOS find search path root")<br>
<br></span>
# set up the default search directories for frameworks<span class=""><br>
set (CMAKE_SYSTEM_FRAMEWORK_PATH<br>
${CMAKE_IOS_SDK_ROOT}/System/L<wbr>ibrary/Frameworks<br>
${CMAKE_IOS_SDK_ROOT}/System/L<wbr>ibrary/PrivateFrameworks<br>
${CMAKE_IOS_SDK_ROOT}/Develope<wbr>r/Library/Frameworks<br>
)<br></span>
'''<br>
<br>
and later in our CMakeLists, we have eg.<br>
<br>
'''<br>
find_package(ZLIB REQUIRED)<br>
'''<br>
<br>
The selection of the SYSROOT is done then on the cmd line given to CMake, and set up once.<br>
<br>
The library that is found by ZLIB are related to CMAKE_IOS_SDK_ROOT, that is a constant in a build tree. Although Xcode can reroot the SYSROOT depending on the target device/arch (simulator/non-simulator).<br>
<br>
Even if later XCode is able to switch sysroots on the command line, depending on the target, the libraries we are linking to are constant, and not honoring the dynamically determined sysroot anymore.<br>
<br>
I believe this problem is going beyond XCode itself, as eg. Visual starts integrating more technologies (Xamarin, Android, Arduino, etc) to their IDE, and at some point the developers will want to use a simulator for those developments.<br>
<br>
My current concerns are about the design of CMake. Do you think the current design of CMake can possibly address this issue nicely, or the only possibilities are workarounds?<br>
<br>
* The fact that we have nice generator expressions can be used to<br>
change the location of external libraries (and the overall link<br>
interface) on the fly. I believe that might be used, we need to<br>
intercept the IDE variable that encodes the current target, and<br>
we might be able to use that variable jointly with the generator<br>
expressions.<br>
* can we teach find_package/find_library to look for all<br>
similar libraries in a set of sysroots? taking back the same<br>
example of find_package(ZLIB), if I have, several sysroots:<br>
<br>
CMAKE_FIND_ROOT_PATH_IOS = /sysroot/1<br>
CMAKE_FIND_ROOT_PATH_IOS_SIMUL<wbr>ATOR = /sysroot/2<br>
<br>
and a new variable listing all the target platforms:<br>
<br>
CMAKE_SYSROOT_NAMES = "IOS;IOS_SIMULATOR"<br>
<br>
I can think of a mechanism that teaches find_library to look<br>
for the same library in all of those SYSROOTS.<br>
<br>
<br>
Concerning the variable sent by the IDE and that might encode the current target, we have for instance this as a prelude to the compilation shell script:<br>
<br>
* for iPhone SDK<br>
export PATH="/Applications/Xcode8.1.a<wbr>pp/Contents/Developer/Platform<wbr>s/iPhoneOS.platform/Developer/<wbr>usr/bin:/Applications/Xcode8.<wbr>1.app/Contents/Developer/usr/<wbr>bin:/usr/local/bin:/usr/bin:/<wbr>bin:/usr/sbin:/sbin"<br>
<br>
* for iPhoneSimulatorSDK:<br>
export PATH="/Applications/Xcode8.1.a<wbr>pp/Contents/Developer/Platform<wbr>s/iPhoneSimulator.platform/<wbr>Developer/usr/bin:/Application<wbr>s/Xcode8.1.app/Contents/<wbr>Developer/usr/bin:/usr/local/<wbr>bin:/usr/bin:/bin:/usr/sbin:/<wbr>sbin"<br>
<br>
That is a poor solution for finding out for what current target platform we are compiling, and I hope it would be possible to retrieve the current ZLIB library we should link to based on $PATH. But I do not know if generator expressions are that flexible. This happens right before the compiler is executed, and cmake cannot be involved or called there. I am not even sure that we can modify the scripts that XCode generate for compilation.<br>
<br>
As you can see, those problems are not that Xcode or iOS specific, and maybe there is an elegant solution already in place, but I cannot find any.<br>
<br>
Thanks,<br>
Raffi<div class="HOEnZb"><div class="h5"><br>
<br>
-- <br>
<br>
Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
<br>
Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" rel="noreferrer" target="_blank">http://www.cmake.org/Wiki/CMak<wbr>e_FAQ</a><br>
<br>
Kitware offers various services to support the CMake community. For more information on each offering, please visit:<br>
<br>
CMake Support: <a href="http://cmake.org/cmake/help/support.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/su<wbr>pport.html</a><br>
CMake Consulting: <a href="http://cmake.org/cmake/help/consulting.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/co<wbr>nsulting.html</a><br>
CMake Training Courses: <a href="http://cmake.org/cmake/help/training.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/tr<wbr>aining.html</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensou<wbr>rce/opensource.html</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://public.kitware.com/mailman/listinfo/cmake-developers" rel="noreferrer" target="_blank">http://public.kitware.com/mail<wbr>man/listinfo/cmake-developers</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Craig Scott<br><div>Melbourne, Australia</div><div><a href="https://crascit.com" target="_blank">https://crascit.com</a><br></div></div></div></div></div></div></div>
</div>