Re: [cmake-developers] iOS: direction to official support and questions
There's discussions related to problems with linking and multiple
architectures in the following recent thread too:
http://public.kitware.com/pipermail/cmake-developers/2017-August/030192.html
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.
On Wed, Aug 16, 2017 at 10:45 AM, Raffi Enficiaud <
raffi.enfici...@mines-paris.org> wrote:
> 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
Re: [cmake-developers] iOS: direction to official support and questions
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
[cmake-developers] Future of ccmake and cmake-gui
Hi, With !977 merged, it is possible to base ccmake and cmake-gui on top of the cmake server. For demonstration, I copied the contents of the Source/CursesDialog directory and added a proxy implementation of the classes `cmake` and `cmState`. The result is 100% compatible with `ccmake`. The same would be possible with cmake-gui. Shall we proceed in this direction? To make the server available everywhere, we should backport the code from C++14 to C++11. I think this is limited to replacing `std::make_shared`. For cmake-gui, the proxies could use Qt functionality (QProcess, QJsonDocument, etc.). As a result, cmake-gui would not have any build dependencies apart from Qt. It might be worth considering to move ccmake and cmake-gui to their own repositories. Cheers, Daniel -- 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] Passing lists with generator expression through add_custom_command
Le 15.08.17 à 16:48, Brad King a écrit :
On 08/13/2017 11:36 AM, Raffi Enficiaud wrote:
-DALL_DEPENDENCIES="${ALL_DEPENDENCIES_FILES}"
That is actually an unquoted argument whose value contains literal quotes.
See the cmake-language(7) manual for details on the syntax. Switch it to
"-DALL_DEPENDENCIES=${ALL_DEPENDENCIES_FILES}"
to quote the argument so that add_custom_command receives it unexpanded.
Then use the VERBATIM option to add_custom_command to make sure it is
re-escaped for the shell properly.
-Brad
Ahh, thanks! and sorry for the noise!
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
Re: [cmake-developers] Passing lists with generator expression through add_custom_command
On 08/13/2017 11:36 AM, Raffi Enficiaud wrote:
> -DALL_DEPENDENCIES="${ALL_DEPENDENCIES_FILES}"
That is actually an unquoted argument whose value contains literal quotes.
See the cmake-language(7) manual for details on the syntax. Switch it to
"-DALL_DEPENDENCIES=${ALL_DEPENDENCIES_FILES}"
to quote the argument so that add_custom_command receives it unexpanded.
Then use the VERBATIM option to add_custom_command to make sure it is
re-escaped for the shell properly.
-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
Re: [cmake-developers] Windows symbolic links handling
On 08/14/2017 06:35 AM, Manu wrote: > Recently I migrated from cmake 2.8.12 to cmake 3.8 and FILE(TIMESTAMP ...) > behaviour changed. Now it reports symbolic link timestamp instead of pointed > file timestamp. Can you track down when that happened? > patch to fix both get_filename_compoment and FILE(TIMESTAMP ...) > > What troubles me is that symlink under Windows is a feature introduced in > Windows Vista and the change for handling them will break Windows XP > compatibility. Is this acceptable? We still support running on XP. If any newer Windows APIs are needed they need to be looked up dynamically. Also, behavior changes for existing commands may need a policy. See also https://gitlab.kitware.com/cmake/cmake/issues/16926 for discussion of symbolic link APIs. -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
Re: [cmake-developers] Fwd: [CMake] cmake-gui on windows and qt5 dlls
On 08/14/2017 04:22 PM, Konstantin Podsvirov wrote: > 14.08.2017, 16:18, "Ben Boeckel" : >> On Mon, Aug 14, 2017 at 20:09:17 +1000, Craig Scott wrote: >>> moving cmake-gui and the Qt DLL's up to the top level? This may just be for >>> Windows, other platforms could stay as they are now. Would obviously have >>> to adjust not just the install location but also any internal code that >>> tries to work out where other files are located relative to the cmake-gui >>> executable. Things like the qt.conf file would also probably need some >>> adjustment. >> >> Git splits it between bin/ and cmd/ where cmd/ is meant to be in PATH. >> Then the structure doesn't need to change either. > > +1 Add script (.bat) to `cmd` subfolder to invoke tools from `bin` > on Windows (and add to PATH variable if needed). One could move `cmake-gui.exe` and `*.dll` files to some other out-of-the-way location and then have `bin/cmake-gui.exe` be a launcher that sets up the environment and runs the real `cmake-gui.exe`. -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
