Spec-Zone.ru › CMake

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

Spec-Zone.ru

Настройки Оффлайн Что нового Помощь О нас
Spec-Zone .ru
спецификации, руководства, описания, API