diff options
author | Brad King <brad.king@kitware.com> | 2021-02-09 13:21:59 (GMT) |
---|---|---|
committer | Kitware Robot <kwrobot@kitware.com> | 2021-02-09 13:22:06 (GMT) |
commit | 40f4147224dd6f3839a224f89dc85f357176fd2f (patch) | |
tree | af6ba66a362f912eecd0f3cf2ec50c115c4b83f0 /Help | |
parent | 9b9075f7237c92acb70a9495b55f8ca356cf90fa (diff) | |
parent | 4d46b1401f9d1624fa5afc3995844d7aebc7ccf4 (diff) | |
download | CMake-40f4147224dd6f3839a224f89dc85f357176fd2f.zip CMake-40f4147224dd6f3839a224f89dc85f357176fd2f.tar.gz CMake-40f4147224dd6f3839a224f89dc85f357176fd2f.tar.bz2 |
Merge topic 'object-lib-multiarch'
4d46b1401f add_library(): Allow imported object libraries with multi-arch
1a915e8953 Tests: TargetObjects does not need any languages enabled
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5771
Diffstat (limited to 'Help')
-rw-r--r-- | Help/prop_tgt/IMPORTED_OBJECTS.rst | 86 | ||||
-rw-r--r-- | Help/prop_tgt/IMPORTED_OBJECTS_CONFIG.rst | 13 | ||||
-rw-r--r-- | Help/release/dev/object-lib-multiarch.rst | 8 |
3 files changed, 103 insertions, 4 deletions
diff --git a/Help/prop_tgt/IMPORTED_OBJECTS.rst b/Help/prop_tgt/IMPORTED_OBJECTS.rst index bbbcd86..f3577eb 100644 --- a/Help/prop_tgt/IMPORTED_OBJECTS.rst +++ b/Help/prop_tgt/IMPORTED_OBJECTS.rst @@ -3,11 +3,91 @@ IMPORTED_OBJECTS .. versionadded:: 3.9 -A :ref:`semicolon-separated list <CMake Language Lists>` of absolute paths to the object -files on disk for an :ref:`imported <Imported targets>` +A :ref:`semicolon-separated list <CMake Language Lists>` of absolute paths +to the object files on disk for an :ref:`imported <Imported targets>` :ref:`object library <object libraries>`. Ignored for non-imported targets. Projects may skip ``IMPORTED_OBJECTS`` if the configuration-specific -property :prop_tgt:`IMPORTED_OBJECTS_<CONFIG>` is set instead. +property :prop_tgt:`IMPORTED_OBJECTS_<CONFIG>` is set instead, except in +situations as noted in the section below. + + +Xcode Generator Considerations +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +.. versionadded:: 3.20 + +For Apple platforms, a project may be built for more than one architecture. +This is controlled by the :variable:`CMAKE_OSX_ARCHITECTURES` variable. +For all but the :generator:`Xcode` generator, CMake invokes compilers once +per source file and passes multiple ``-arch`` flags, leading to a single +object file which will be a universal binary. Such object files work well +when listed in the ``IMPORTED_OBJECTS`` of a separate CMake build, even for +the :generator:`Xcode` generator. But producing such object files with the +:generator:`Xcode` generator is more difficult, since it invokes the compiler +once per architecture for each source file. Unlike the other generators, +it does not generate universal object file binaries. + +A further complication with the :generator:`Xcode` generator is that when +targeting device platforms (iOS, tvOS or watchOS), the :generator:`Xcode` +generator has the ability to use either the device or simulator SDK without +needing CMake to be re-run. The SDK can be selected at build time. +But since some architectures can be supported by both the device and the +simulator SDKs (e.g. ``arm64`` with Xcode 12 or later), not all combinations +can be represented in a single universal binary. The only solution in this +case is to have multiple object files. + +``IMPORTED_OBJECTS`` doesn't support generator expressions, so every file +it lists needs to be valid for every architecture and SDK. If incorporating +object files that are not universal binaries, the path and/or file name of +each object file has to somehow encapsulate the different architectures and +SDKs. With the :generator:`Xcode` generator, Xcode variables of the form +``$(...)`` can be used to represent these aspects and Xcode will substitute +the appropriate values at build time. CMake doesn't interpret these +variables and embeds them unchanged in the Xcode project file. +``$(CURRENT_ARCH)`` can be used to represent the architecture, while +``$(EFFECTIVE_PLATFORM_NAME)`` can be used to differentiate between SDKs. + +The following shows one example of how these two variables can be used to +refer to an object file whose location depends on both the SDK and the +architecture: + +.. code-block:: cmake + + add_library(someObjs OBJECT IMPORTED) + + set_property(TARGET someObjs PROPERTY IMPORTED_OBJECTS + # Quotes are required because of the () + "/path/to/somewhere/objects$(EFFECTIVE_PLATFORM_NAME)/$(CURRENT_ARCH)/func.o" + ) + + # Example paths: + # /path/to/somewhere/objects-iphoneos/arm64/func.o + # /path/to/somewhere/objects-iphonesimulator/x86_64/func.o + +In some cases, you may want to have configuration-specific object files +as well. The :variable:`CMAKE_CFG_INTDIR` variable can be a convenient +way of capturing this in combination with the SDK: + +.. code-block:: cmake + + add_library(someObjs OBJECT IMPORTED) + set_property(TARGET someObjs PROPERTY IMPORTED_OBJECTS + "/path/to/somewhere/${CMAKE_CFG_INTDIR}/$(CURRENT_ARCH)/func.o" + ) + + # Example paths: + # /path/to/somewhere/Release-iphoneos/arm64/func.o + # /path/to/somewhere/Debug-iphonesimulator/x86_64/func.o + +When any Xcode variable or :variable:`CMAKE_CFG_INTDIR` is used, CMake is +not able to fully evaluate the path(s) at configure time. One consequence +of this is that the configuration-specific +:prop_tgt:`IMPORTED_OBJECTS_<CONFIG>` properties cannot be used, since +CMake cannot determine whether an object file exists at a particular +``<CONFIG>`` location. The ``IMPORTED_OBJECTS`` property must be used for +these situations and the configuration-specific aspects of the path must be +handled by using :variable:`CMAKE_CFG_INTDIR` or with another Xcode variable +``$(CONFIGURATION)``. diff --git a/Help/prop_tgt/IMPORTED_OBJECTS_CONFIG.rst b/Help/prop_tgt/IMPORTED_OBJECTS_CONFIG.rst index b12ca38..238395a 100644 --- a/Help/prop_tgt/IMPORTED_OBJECTS_CONFIG.rst +++ b/Help/prop_tgt/IMPORTED_OBJECTS_CONFIG.rst @@ -3,7 +3,18 @@ IMPORTED_OBJECTS_<CONFIG> .. versionadded:: 3.9 -<CONFIG>-specific version of :prop_tgt:`IMPORTED_OBJECTS` property. +``<CONFIG>``-specific version of :prop_tgt:`IMPORTED_OBJECTS` property. Configuration names correspond to those provided by the project from which the target is imported. + + +Xcode Generator Considerations +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Do not use this ``<CONFIG>``-specific property if you need to use Xcode +variables like ``$(CURRENT_ARCH)`` or ``$(EFFECTIVE_PLATFORM_NAME)`` in +the value. The ``<CONFIG>``-specific properties will be ignored in such +cases because CMake cannot determine whether a file exists at the +configuration-specific path at configuration time. For such cases, use +:prop_tgt:`IMPORTED_OBJECTS` instead. diff --git a/Help/release/dev/object-lib-multiarch.rst b/Help/release/dev/object-lib-multiarch.rst new file mode 100644 index 0000000..0d309d6 --- /dev/null +++ b/Help/release/dev/object-lib-multiarch.rst @@ -0,0 +1,8 @@ +object-lib-multiarch +-------------------- + +* The :command:`add_library` command previously prohibited imported object + libraries when using potentially multi-architecture configurations. + This mostly affected the :generator:`Xcode` generator, e.g. when targeting + iOS or one of the other device platforms. This restriction has now been + removed. |