Le 10.08.17 à 17:04, Brad King a écrit :
On 08/08/2017 08:08 AM, Raffi Enficiaud wrote:
I have looked a bit to the Android toolchains, and I have to say I found
those quite complicated as a first reading :)
This note may help:
https://gitlab.kitware.com/cmake/cmake/issues/16708#note_300971
Hi,
Thanks for the link and the answers!
I don't think iOS will need all the toolchain and stl selection logic.
Ideally CMake would gain iOS platform modules such that one could
set CMAKE_SYSTEM_NAME to `iOS`.
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_FIND_ROOT_PATH_MODE_PROGRAM ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
These last three lines tell the find commands to only look at
paths re-rooted under CMAKE_FIND_ROOT_PATH and CMAKE_SYSROOT.
If boost is not under one of those then it won't be found.
set(CMAKE_MACOSX_BUNDLE YES)
Is it possible to build any binary of any form on iOS without this?
You're right, I do not think this is possible.
If not then the iOS platform modules should set something to tell
the generators that this should always be enabled.
set(CMAKE_XCODE_ATTRIBUTE_CODE_SIGNING_REQUIRED "NO")
Similarly for this, but perhaps only during `try_compile`.
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_REQUIRED target property to
something else.
Is that correct?
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.
Concerning this "some mechanism" part, what do you have in mind? Would
it be an extra variable like
CMAKE_XCODE_ATTRIBUTE_CODE_SIGNING_REQUIRED_IN_TRY_COMPILE ?
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.
If you have an idea, good, otherwise I believe this is secondary right now.
I'm not familiar enough with iOS development to answer the rest of
your questions.
Me neither :)
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.
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.
From the posts I can read online, this is causing a lot of troubles,
especially when linking with libraries.
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.
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.
Example:
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:
'''
set(CMAKE_FIND_ROOT_PATH
${CMAKE_IOS_DEVELOPER_ROOT}
${CMAKE_IOS_SDK_ROOT}
${CMAKE_PREFIX_PATH}
/some/other/path
CACHE string "iOS find search path root")
# set up the default search directories for frameworks
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
)
'''
and later in our CMakeLists, we have eg.
'''
find_package(ZLIB REQUIRED)
'''
The selection of the SYSROOT is done then on the cmd line given to
CMake, and set up once.
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).
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.
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.
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?
* The fact that we have nice generator expressions can be used to
change the location of external libraries (and the overall link
interface) on the fly. I believe that might be used, we need to
intercept the IDE variable that encodes the current target, and
we might be able to use that variable jointly with the generator
expressions.
* can we teach find_package/find_library to look for all
similar libraries in a set of sysroots? taking back the same
example of find_package(ZLIB), if I have, several sysroots:
CMAKE_FIND_ROOT_PATH_IOS = /sysroot/1
CMAKE_FIND_ROOT_PATH_IOS_SIMULATOR = /sysroot/2
and a new variable listing all the target platforms:
CMAKE_SYSROOT_NAMES = "IOS;IOS_SIMULATOR"
I can think of a mechanism that teaches find_library to look
for the same library in all of those SYSROOTS.
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:
* for iPhone SDK
export
PATH="/Applications/Xcode8.1.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:/Applications/Xcode8.1.app/Contents/Developer/usr/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin"
* for iPhoneSimulatorSDK:
export
PATH="/Applications/Xcode8.1.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin:/Applications/Xcode8.1.app/Contents/Developer/usr/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin"
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.
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.
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
