Le 27.09.17 à 12:34, Brad King a écrit :
On 09/26/2017 05:05 PM, Raffi Enficiaud wrote:
Is it possible to source the default setup and to override some parts
when a toolchain is given on the command line?
The toolchain file is loaded very early, before any of the platform
information files. It is supposed to provide information, not consume it.
It is loaded too early to even know CMAKE_SYSTEM_NAME, because it is
supposed to provide this value.
Thanks for the answers!
From what I understand, I missed the point of the cross compilation
file a bit, and I should rather go for platform files.
For cross-compiling a project on iOS or iOS simulator, and since those 2
platforms are still Darwin, I believe that:
* from a user perspective:
* CMAKE_SYSTEM_NAME should be set to "Darwin"
* CMAKE_SYSTEM_VERSION should be set to iOS or iOS-simulator,
possibly with a version (like "Mac OSX 10.2" in Darwin.cmake)
* inside "Modules/Platform/Darwin.cmake"
* CMAKE_SYSTEM_PROCESSOR should default to armXX for iOS and
i386/x86_64 for the simulator
* I do not think that any other compiler than AppleClang is
supported, but we leave the detection as it is right now. This should
default to AppleClang anyway.
* the detection of the base SDKs should be performed inside
"Platform/Darwin.cmake"
* the file "Modules/Platform/Darwin-Clang.cmake" should check the
"CMAKE_SYSTEM_VERSION" to add appropriate flags when
CMAKE_SYSTEM_VERSION is iOS or simulator. This should include clang and
apple clang.
If things work ok and if I understand more or less the scope of those
files, the base SDKs will then be detected from the
"Modules/Platform/Darwin.cmake".
However, I just notice the existence of
"Modules/Platform/Darwin-Initialize.cmake" that is setting several
variables. When is this file sourced? should be before
"Modules/Platform/Darwin.cmake" but I failed to see from where.
I see several problems with this file if I were to make it iOS aware.
For instance it contains variables that are checking for the version,
but based only on the macOS scheme.
Should the CMAKE_SYSTEM_VERSION include the "iOS" or "iOSSimulator"
part? (like for instance "iOS-10.1" ?) or we stick to a clean version
name and:
1/ either we change the CMAKE_SYSTEM_NAME to DarwinIOS (we also need to
distinguish between real device and simulator)
2/ or we carry another variable IOS=TRUE and be careful inside the
Darwin specific platform files.
My preference goes for 2/ above because:
* having something like DarwinIOS would need to create a full new branch
of platform support, while the overlap with Darwin is almost 95%.
* iOS is clearly a Darwin platform, just another version, but version
carries more than a revision number (eg "10.5") that needs to be encoded
in another variable (eg. IOS=TRUE)
* we will benefit from all the build logic (Darwin, policies, etc) that
are currently working for OSX
Also, is it possible to check for policies directly from the toolchain
file, or is it too early?
In a project that starts with `cmake_minimum_required(...)` as its first
call (the recommended approach) then policies it sets will be available
when the toolchain file is first loaded by a following `project()` or
`enable_language()` command. However, toolchain files are not meant to
be general-purpose infrastructure shared by many projects. They are
meant to be specific to a project and host machine. Common info about
a platform belongs in CMake's modules, e.g. a Platform/iOS.cmake module
for use with CMAKE_SYSTEM_NAME set to "iOS". Lacking that, a toolchain
file trying to work without it will undoubtedly need to be hacky.
I believe if I integrate well with the platform files, all things would
be good again, and the policies will apply naturally (so no hack needed).
This is what I added in the toolchain file, but I feel like this is too
hacky:
set(CMAKE_BUILD_WITH_INSTALL_NAME_DIR TRUE)
set(CMAKE_INSTALL_NAME_DIR "@rpath/")
set(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
set(CMAKE_INSTALL_RPATH "@rpath/")
If that is universally needed when deploying to iOS then CMake should
be taught this information in a corresponding platform file.
I do not think this is universally needed, I just wanted to mimic the
default I got when compiling the same source tree but with the OSX
target platform. Without great success ...
Keeping
it in the toolchain file may work but is an example of the hacky nature
discussed above. OTOH this looks project-specific to me. One could
use `@executable_path/` in INSTALL_NAME_DIR for everything and not need
any rpath.
Yes, I was not convinced neither and totally fine with removing this.
and I need to also do this:
set_target_properties(mymainexecutable
PROPERTIES
BUILD_WITH_INSTALL_RPATH TRUE
INSTALL_RPATH "@executable_path/"
)
This encodes knowledge of the relative install destination of the
libraries to the executable, which only the project code itself
can know.
Here what I wanted to say is that the settings I am placing in the
toolchain file were not propagating to this bundle project for some
reason I failed to understand.
Your comments most welcome,
Raffi
PS: how should we proceed with the developments? Having a fork on Gitlab
based on master and start integrating from there would be ok? Do you
need a build machine first?
--
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
