IMPORTED_OBJECTS

Список абсолютных путей к объектным файлам на диске, разделённый точкой с запятой, для импортированной объектной библиотеки.

Игнорируется для неимпортированных целей.

Проекты могут пропустить IMPORTED_OBJECTS если вместо этого установлено конфигурационно-зависимое свойство IMPORTED_OBJECTS_<CONFIG>, за исключением случаев, указанных в разделе ниже.

Учёт генератора Xcode

Для платформ Apple проект может быть скомпилирован для более чем одной архитектуры. Это контролируется переменной CMAKE_OSX_ARCHITECTURES. Для всех генераторов, кроме генератора Xcode, CMake вызывает компиляторы один раз на каждый исходный файл и передаёт несколько -arch флагов, что приводит к одному объектному файлу, который будет универсальной бинарной. Такие объектные файлы хорошо работают, когда они перечислены в IMPORTED_OBJECTS отдельного CMake сборки, даже для генератора Xcode. Но создание таких объектных файлов с помощью генератора Xcode сложнее, так как он вызывает компилятор один раз на каждую архитектуру для каждого исходного файла. В отличие от других генераторов, он не генерирует универсальные объектные бинарные файлы.

Ещё одна сложность с генератором Xcode заключается в том, что при нацеливании на платформы устройств (iOS, tvOS или watchOS) генератор Xcode может использовать SDK устройства или симулятора без необходимости повторного запуска CMake. SDK может быть выбран во время сборки. Но так как некоторые архитектуры могут быть поддерживаемы как SDK устройства, так и SDK симулятора (например, arm64 с Xcode 12 или новее), не все комбинации могут быть представлены в одной универсальной бинарной. В этом случае единственное решение — иметь несколько объектных файлов.

IMPORTED_OBJECTS не поддерживает выражения генератора, поэтому каждый перечисленный файл должен быть действительным для каждой архитектуры и SDK. При включении объектных файлов, которые не являются универсальными бинарными, путь и/или имя файла каждого объектного файла должны как-то оборачивать различные архитектуры и SDK. С генератором Xcode можно использовать переменные Xcode вида $(...), чтобы представить эти аспекты, и Xcode заменит соответствующие значения во время сборки. CMake не интерпретирует эти переменные и включает их без изменений в файл проекта Xcode. $(CURRENT_ARCH) может использоваться для представления архитектуры, а $(EFFECTIVE_PLATFORM_NAME) может использоваться для различения SDK.

Следующий пример показывает, как можно использовать эти две переменные для ссылки на объектный файл, чьё расположение зависит как от SDK, так и от архитектуры:

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

В некоторых случаях вам может потребоваться иметь также конфигурационно-зависимые объектные файлы. Для этого часто используется переменная Xcode $(CONFIGURATION) и её можно использовать в сочетании с другими перечисленными выше:

add_library(someObjs OBJECT IMPORTED)
set_property(TARGET someObjs PROPERTY IMPORTED_OBJECTS
  "/path/to/somewhere/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME)/$(CURRENT_ARCH)/func.o"
)

# Example paths:
#   /path/to/somewhere/Release-iphoneos/arm64/func.o
#   /path/to/somewhere/Debug-iphonesimulator/x86_64/func.o

Когда используется любая переменная Xcode, CMake не может полностью оценить путь(и) во время конфигурации. Одним из последствий этого является то, что конфигурационно-зависимые свойства IMPORTED_OBJECTS_<CONFIG> не могут быть использованы, так как CMake не может определить, существует ли объектный файл по указанному <CONFIG> пути. В этих ситуациях необходимо использовать свойство IMPORTED_OBJECTS, а конфигурационно-зависимые аспекты пути должны обрабатываться переменной Xcode $(CONFIGURATION).