IMPORTED_OBJECTS

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

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

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

Особенности генератора Xcode

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

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

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

Ниже приведён пример использования этих двух переменных для указания файла объекта, расположение которого зависит как от 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).