CMP0114
Добавлено в версии 3.19.
Целевые объекты этапов ExternalProject полностью принимают на себя свои этапы.
Параметр ExternalProject_Add() STEP_TARGETS и функция ExternalProject_Add_StepTargets() могут использоваться для создания целевых объектов сборки для отдельных этапов внешнего проекта.
В CMake 3.18 и более ранних версиях целевые объекты этапов имеют некоторые ограничения:
- Целевые объекты этапов всегда зависят от целевых объектов, указанных параметром
ExternalProject_Add()DEPENDS, хотя не всем этапам они нужны. Чтобы разрешить создание целевых объектов этапов без этих зависимостей, можно использовать параметрExternalProject_Add()INDEPENDENT_STEP_TARGETSили параметрExternalProject_Add_StepTargets()NO_DEPENDS. Однако добавлять такие «независимые» целевые объекты этапов имеет смысл только для определённых этапов, таких какdownload,updateиpatch, поскольку им не нужны зависимости сборки внешнего проекта. Кроме того, нет смысла создавать независимые целевые объекты для этапов, зависящих от не независимых этапов. Эти правила не обеспечиваются, и проекты, которые их не соблюдают, могут генерировать системы сборки с запутанным поведением, зависящим от генератора. -
Целевые объекты этапов содержат копии пользовательских команд, реализующих соответствующие этапы, отдельно от копий в основном целевом объекте, созданном командой
ExternalProject_Add(), а основной целевой объект не зависит от целевых объектов этапов. При параллельных сборках, одновременно запускающих основной целевой объект и целевые объекты этапов, несколько копий команд этапов могут выполняться параллельно, создавая условия гонки.Кроме того, до введения политики
CMP0113целевые объекты этапов, создаваемые генераторами Makefile, также содержат все пользовательские команды, от которых зависит соответствующий этап. Это может приводить к повторному выполнению этих этапов даже при последовательной сборке.
В CMake 3.19 и более поздних версиях модуль ExternalProject использует обновлённую структуру, призванную устранить эти проблемы:
-
Каждый этап классифицируется как «независимый», если он не зависит от других целевых объектов, указанных параметром
ExternalProject_Add()DEPENDS. Предопределённые этапы классифицируются автоматически по умолчанию:- Этапы
download,updateиpatchявляются независимыми. - Этапы
configure,build,testиinstallне являются независимыми.
Для пользовательских этапов команда
ExternalProject_Add_Step()предоставляет параметрINDEPENDENT, позволяющий пометить их как независимые. Помечать этап как независимый нельзя, если он зависит от других этапов, которые не являются независимыми. Обратите внимание: термин «независимый» здесь означает только независимость от внешних целевых объектов и не связан с зависимостями этапа от других этапов. - Этапы
- Целевые объекты этапов, созданные параметром
ExternalProject_Add()STEP_TARGETSили функциейExternalProject_Add_Step(), теперь являются независимыми тогда и только тогда, когда их этапы помечены как независимые. ПараметрExternalProject_Add()INDEPENDENT_STEP_TARGETSи параметрExternalProject_Add_StepTargets()NO_DEPENDSбольше не допускаются. -
После создания целевые объекты этапов полностью отвечают за хранение пользовательских команд, реализующих соответствующие этапы. Основной целевой объект, созданный командой
ExternalProject_Add(), зависит от целевых объектов этапов, а целевые объекты этапов зависят друг от друга. Зависимости на уровне целевых объектов соответствуют зависимостям на уровне файлов, используемым пользовательскими командами для каждого этапа.При использовании параметра
ExternalProject_Add()UPDATE_DISCONNECTEDилиTEST_EXCLUDE_FROM_MAIN, а также при использовании параметраExternalProject_Add_Step()EXCLUDE_FROM_MAINдля пользовательского этапа некоторые целевые объекты этапов могут создаваться автоматически. Они необходимы для хранения этапов, от которых обычно зависят основной целевой объект и отделённые целевые объекты этапов.
Политика CMP0114 обеспечивает совместимость с проектами, которые не были обновлены с учётом нового поведения. Поведение OLD для этой политики заключается в использовании описанного выше поведения CMake 3.18 и более ранних версий. Поведение NEW для этой политики заключается в использовании описанного выше поведения, предпочтительного в CMake 3.19 и более поздних версиях.
Эта политика введена в версии CMake 3.19. Её можно задать с помощью cmake_policy() или cmake_minimum_required(). Если она не задана, CMake выдаёт предупреждение и использует поведение OLD.
Примечание
Поведение политики OLD по определению считается устаревшим и может быть удалено в будущей версии CMake.
© 2000–2026 Kitware, Inc. and Contributors
Licensed under the BSD 3-clause License.
https://cmake.org/cmake/help/latest/policy/CMP0114.html