ExternalProject

• Определение внешнего проекта

  • Параметры каталогов

  • Параметры шага загрузки

    • URL
    • Git
    • Subversion
    • Mercurial
    • CVS
  • Параметры шага обновления
  • Параметры шага патчинга
  • Параметры шага конфигурации
  • Параметры шага сборки
  • Параметры шага установки
  • Параметры шага тестирования
  • Параметры ведения журналов вывода
  • Параметры доступа к терминалу
  • Параметры целевых объектов
  • Разные параметры
• Получение свойств проекта
• Явное управление шагами
• Примеры

Определение внешнего проекта

ExternalProject_Add

Функция ExternalProject_Add() создает пользовательский целевой объект для управления шагами загрузки, обновления/патчинга, конфигурации, сборки, установки и тестирования внешнего проекта:

ExternalProject_Add(<name> [<option>...])

Отдельные шаги процесса можно запускать независимо (например, для отправки в CDash), а также определить дополнительные пользовательские шаги, управлять зависимостями между шагами. Можно также настроить структуру каталогов для управления внешним проектом. Функция поддерживает большое количество параметров для настройки поведения внешнего проекта.

Параметры каталогов

В большинстве случаев стандартная структура каталогов подходит. Это в основном деталь реализации, которую обычно не нужно изменять в основном проекте. Однако в некоторых ситуациях управление структурой каталогов может быть полезным или необходимым. Параметры каталогов потенциально более полезны с точки зрения того, что основной проект может использовать команду ExternalProject_Get_Property() для извлечения их значений, тем самым позволяя главному проекту ссылаться на артефакты сборки внешнего проекта.

PREFIX <dir>

Корневой каталог внешнего проекта. Если не указано иное, все остальные каталоги, связанные с внешним проектом, будут созданы внутри него.

TMP_DIR <dir>

Каталог для хранения временных файлов.

STAMP_DIR <dir>

Каталог для хранения отметки времени каждого шага. Лог-файлы отдельных шагов также создаются здесь, если не переопределен LOG_DIR (см. Параметры ведения журнала ниже).

LOG_DIR <dir>

Добавлена в версии 3.14.

Каталог для хранения логов каждого шага.

DOWNLOAD_DIR <dir>

Каталог для хранения загруженных файлов перед их распаковкой. Этот каталог используется только методом загрузки URL, все остальные методы загрузки используют SOURCE_DIR напрямую вместо этого.

SOURCE_DIR <dir>

Каталог назначения, в который будут распакованы загруженные содержимое, или, для методов загрузки, отличных от URL, каталог, в котором должен быть выполнен check out, клонирование и т. д. репозитория. Если метод загрузки не указан, этот параметр должен указывать на существующий каталог, в котором внешний проект уже был распакован или клонирован/проверился.

Примечание

Если метод загрузки указан, любое существующее содержимое каталога назначения может быть удалено. Только метод загрузки URL проверяет, отсутствует ли этот каталог или он пуст, прежде чем начать загрузку, и останавливается с ошибкой, если он не пуст. Все остальные методы загрузки безмолвно отбрасывают любое предыдущее содержимое каталога назначения.

BINARY_DIR <dir>

Указывает местоположение каталога сборки. Этот параметр игнорируется, если включен BUILD_IN_SOURCE.

INSTALL_DIR <dir>

Префикс установки, который будет помещен в заполнитель <INSTALL_DIR>. Это не настраивает фактически внешний проект для установки в указанный префикс. Для этого необходимо передать соответствующие аргументы в шаг конфигурации внешнего проекта, например, используя <INSTALL_DIR>.

Если какой-либо из вышеперечисленных ..._DIR параметров не указан, их значения вычисляются следующим образом. Если задан параметр PREFIX или установлено свойство каталога EP_PREFIX , то внешний проект собирается и устанавливается в указанный префикс:

TMP_DIR      = <prefix>/tmp
STAMP_DIR    = <prefix>/src/<name>-stamp
DOWNLOAD_DIR = <prefix>/src
SOURCE_DIR   = <prefix>/src/<name>
BINARY_DIR   = <prefix>/src/<name>-build
INSTALL_DIR  = <prefix>
LOG_DIR      = <STAMP_DIR>

В противном случае, если установлено свойство каталога EP_BASE , компоненты внешнего проекта хранятся в указанном базовом каталоге:

TMP_DIR      = <base>/tmp/<name>
STAMP_DIR    = <base>/Stamp/<name>
DOWNLOAD_DIR = <base>/Download/<name>
SOURCE_DIR   = <base>/Source/<name>
BINARY_DIR   = <base>/Build/<name>
INSTALL_DIR  = <base>/Install/<name>
LOG_DIR      = <STAMP_DIR>

Если не указан ни PREFIX, ни EP_PREFIX, ни EP_BASE , то значение PREFIX по умолчанию устанавливается в <name>-prefix. Относительные пути интерпретируются относительно CMAKE_CURRENT_BINARY_DIR в момент вызова ExternalProject_Add().

Параметры шага загрузки

Метод загрузки можно опустить, если параметр SOURCE_DIR используется для указания существующего непустого каталога. В противном случае, должен быть указан один из методов загрузки ниже (несколько методов загрузки не следует указывать) или предоставлен пользовательский DOWNLOAD_COMMAND.

DOWNLOAD_COMMAND <cmd>...

Переопределяет команду, используемую для шага загрузки (generator expressions поддерживаются). Если этот параметр указан, все остальные параметры загрузки будут игнорироваться. Передача пустой строки для <cmd> фактически отключает шаг загрузки.

URL

URL <url1> [<url2>...]

Список путей и/или URL(ов) внешнего проекта. Если предоставлено несколько URL, они будут перепробованы по очереди, пока не удастся подключиться к одному. URL может быть обычным путём в локальной файловой системе (в этом случае он должен быть единственным предоставленным URL) или любым URL для загрузки, поддерживаемым командой file(DOWNLOAD). Локальный путь к файловой системе может ссылаться на существующую директорию или на архивный файл, в то время как URL должен указывать на файл, который может рассматриваться как архив. Когда используется архив, он будет распакован автоматически, если опция DOWNLOAD_NO_EXTRACT не установлена, чтобы предотвратить это. Тип архива определяется по фактическому содержанию, а не на основе расширения файла.

Изменено в версии 3.7: Разрешено несколько URL.

URL_HASH <algo>=<hashValue>

Хеш загружаемого архивного файла. Аргумент должен быть в формате <algo>=<hashValue> где algo может быть любым из алгоритмов хэширования, поддерживаемых командой file(). Указание этой опции настоятельно рекомендуется для загрузки по URL, так как она гарантирует целостность загруженного содержимого. Она также используется для проверки ранее загруженного файла, позволяя избежать подключения к удалённому расположению, если в локальной директории уже есть файл из предыдущей загрузки, который соответствует указанному хэшу.

URL_MD5 <md5>

Эквивалентно URL_HASH MD5=<md5>.

DOWNLOAD_NAME <fname>

Имя файла, используемого для загруженного файла. Если не указано, имя файла определяется из конца URL. Эта опция редко необходима, имя по умолчанию, как правило, подходит и обычно не используется за пределами кода, внутреннего для модуля ExternalProject.

DOWNLOAD_EXTRACT_TIMESTAMP <bool>

Добавлена в версии 3.24.

Если задано со значением true, временные метки извлечённых файлов будут соответствовать временным меткам в архиве. Если false, временные метки извлечённых файлов будут отражать время, в которое было выполнено извлечение. Если URL загрузки изменится, временные метки, основанные на временных метках из архива, могут привести к тому, что зависимые цели не будут перестроены, когда это потенциально необходимо. Поэтому, если временные метки файлов не важны для проекта, используйте значение false для этой опции. Если DOWNLOAD_EXTRACT_TIMESTAMP не указано, значение по умолчанию — false. См. политику CMP0135.

DOWNLOAD_NO_EXTRACT <bool>

Добавлена в версии 3.6.

Разрешает отключение этапа извлечения при загрузке, передавая для этой опции логическое значение true. Если эта опция не указана, содержимое загруженного файла будет распаковано автоматически при необходимости. Если извлечение отключено, полный путь к загруженному файлу доступен как <DOWNLOADED_FILE> в последующих шагах или как свойство DOWNLOADED_FILE с помощью команды ExternalProject_Get_Property().

DOWNLOAD_NO_PROGRESS <bool>

Может использоваться для отключения регистрации прогресса загрузки. Если эта опция не указана, сообщения о прогрессе загрузки будут регистрироваться.

TIMEOUT <seconds>

Максимальное время, разрешённое для операций загрузки файлов.

INACTIVITY_TIMEOUT <seconds>

Добавлена в версии 3.19.

Прервать операцию после периода бездействия.

HTTP_USERNAME <username>

Добавлена в версии 3.7.

Имя пользователя для операции загрузки, если требуется аутентификация.

HTTP_PASSWORD <password>

Добавлена в версии 3.7.

Пароль для операции загрузки, если требуется аутентификация.

HTTP_HEADER <header1> [<header2>...]

Добавлена в версии 3.7.

Предоставляет произвольный список HTTP-заголовков для операции загрузки. Это может быть полезно для доступа к содержимому в системах, таких как AWS и т.д.

TLS_VERSION <min>

Добавлена в версии 3.30.

Укажите минимальную версию TLS для https:// URL. Если эта опция не предоставлена, будет использоваться значение переменной CMAKE_TLS_VERSION или переменной среды CMAKE_TLS_VERSION (см. file(DOWNLOAD)).

Эта опция также применяется к вызовам git clone, хотя поведение по умолчанию отличается. Если ни одна из опций TLS_VERSION, переменная CMAKE_TLS_VERSION, или переменная среды CMAKE_TLS_VERSION не указана, поведение будет определяться по умолчанию git или опцией конфигурации git http.sslVersion, которую пользователь мог установить на глобальном уровне.

TLS_VERIFY <bool>

Указывает, следует ли выполнять проверку сертификата для https:// URL. Если эта опция не указана, будет использоваться значение переменной CMAKE_TLS_VERIFY или переменной среды CMAKE_TLS_VERIFY (см. file(DOWNLOAD)). Если ни одна из этих переменных не установлена, проверка сертификатов не будет выполнена. В ситуациях, когда URL_HASH не может быть предоставлена, эта опция может быть альтернативным способом проверки.

Эта опция также применяется к вызовам git clone, хотя поведение по умолчанию отличается. Если ни одна из опций TLS_VERIFY, переменная CMAKE_TLS_VERIFY или переменная среды CMAKE_TLS_VERIFY не указана, поведение будет определяться по умолчанию git (true) или опцией конфигурации git http.sslVerify которую пользователь мог установить на глобальном уровне.

Изменено в версии 3.6: Ранее эта опция не применялась к вызовам git clone.

Изменено в версии 3.30: Ранее переменная среды CMAKE_TLS_VERIFY не проверялась.

TLS_CAINFO <file>

Укажите файл пользовательского сертификата, используемый, если включен TLS_VERIFY . Если эта опция не указана, будет использоваться значение переменной CMAKE_TLS_CAINFO (см. file(DOWNLOAD))

NETRC <level>

Добавлена в версии 3.11.

Указывает, должен ли файл .netrc использоваться для операции. Если эта опция не указана, будет использоваться значение переменной CMAKE_NETRC (см. file(DOWNLOAD)). Допустимые уровни:

IGNORED

Файл .netrc игнорируется. Это значение по умолчанию.

OPTIONAL

Файл .netrc является необязательным, и информация в URL имеет приоритет. Файл будет просканирован, чтобы найти информацию, которая не указана в URL.

REQUIRED

Файл .netrc обязателен, и информация в URL игнорируется.

NETRC_FILE <file>

Добавлена в версии 3.11.

Укажите альтернативный файл .netrc по сравнению с файлом в домашней директории, если уровень NETRC равен OPTIONAL или REQUIRED. Если эта опция не указана, будет использоваться значение переменной CMAKE_NETRC_FILE (см. file(DOWNLOAD))

Git

ПРИМЕЧАНИЕ: Требуется версия git 1.6.5 или более поздней, если используется этот метод загрузки.

GIT_REPOSITORY <url>

URL репозитория Git. Можно использовать любой URL, понятный команде git.

Изменено в версии 3.27: Относительный URL будет разрешен на основе удаленного сервера родительского проекта, с учётом CMP0150. См. документацию по политике, чтобы понять, как выбирается удалённый сервер, включая условия, при которых выбор удалённого сервера может завершиться ошибкой. Для удалённых серверов на файловой системе всегда должны использоваться абсолютные пути.

GIT_TAG <tag>

Имя ветки, тега или хэш коммита Git. Обратите внимание, что имена веток и тегов, как правило, должны быть указаны как имена удалённых ветвей (т.е. origin/myBranch вместо просто myBranch). Это гарантирует, что если удалённый сервер переместил тег или перебазировал или переписал историю ветки, локальная копия всё равно будет обновляться правильно. Однако в целом предпочтительнее указывать хэш коммита по ряду причин:

• Если локальная копия уже содержит коммит, соответствующий хэшу, не требуется выполнять git fetch для проверки изменений каждый раз при повторном запуске CMake. Это может значительно ускорить процесс, если используются многие внешние проекты.
• Использование конкретного хэша Git гарантирует, что вся история основного проекта полностью прослеживается до определённой точки в развитии внешнего проекта. Если вместо этого используется имя ветки или тега, то проверка конкретного коммита основного проекта не обязательно фиксирует весь процесс сборки в определённую точку жизни внешнего проекта. Отсутствие такой детерминированной характеристики приводит к потере прослеживаемости и воспроизводимости в основном проекте.

Если включен GIT_SHALLOW, то GIT_TAG работает только с именами веток и тегов. Хэш коммита не разрешён.

Обратите внимание, что если не указано, GIT_TAG по умолчанию master, а не имя ветки Git по умолчанию.

GIT_REMOTE_NAME <name>

Необязательное имя удалённого сервера. Если этот параметр не указан, он по умолчанию origin.

GIT_SUBMODULES <module>...

Конкретные подмодули Git, которые также должны быть обновлены. Если этот параметр не указан, все подмодули Git будут обновлены.

Изменено в версии 3.16: Когда CMP0097 установлено в значение NEW, если это значение установлено в пустую строку, подмодули не будут инициализированы или обновлены.

GIT_SUBMODULES_RECURSE <bool>

Новое в версии 3.17.

Укажите, должны ли подмодули Git (если таковые имеются) обновляться рекурсивно, передав флаг --recursive команде git submodule update. Если не указано, значение по умолчанию — включено.

GIT_SHALLOW <bool>

Новое в версии 3.6.

При включении этого параметра, операция git clone получит параметр --depth 1. Это выполняет поверхностное клонирование, что позволяет избежать скачивания всей истории, а вместо этого извлекает только коммит, указанный параметром GIT_TAG.

GIT_PROGRESS <bool>

Новое в версии 3.8.

При включении этого параметра, операция git clone будет сообщать о своём прогрессе, передавая параметр --progress. Без этого параметра шаг клонирования для крупных проектов может показаться заторможенным, поскольку никаких сообщений не будет до завершения операции клонирования. Хотя этот параметр может использоваться для отображения прогресса, чтобы избежать видимости задержки сборки, он может также сделать сборку слишком шумной, если используется много внешних проектов.

GIT_CONFIG <option1> [<option2>...]

Новое в версии 3.8.

Укажите список параметров конфигурации для передачи в git clone. Каждый перечисленный параметр будет преобразован в собственный --config <option> в командной строке git clone, при этом каждый параметр должен быть в формате key=value.

GIT_REMOTE_UPDATE_STRATEGY <strategy>

Новое в версии 3.18.

Когда GIT_TAG ссылается на удалённую ветку, этот параметр можно использовать для указания поведения шага обновления. <strategy> должно быть одним из следующих:

CHECKOUT

Игнорировать локальную ветку и всегда переключаться на ветку, указанную параметром GIT_TAG.

REBASE

Попытаться перебазировать текущую ветку на указанную ветку GIT_TAG. Если есть несохранённые изменения в локальной ветке, они будут сначала сохранены в резерв (stash), а затем восстановлены после перебазирования. Если перебазирование или восстановление сохранённых изменений завершатся ошибкой, перебазирование будет прервано, и сборка будет остановлена с ошибкой. Если GIT_REMOTE_UPDATE_STRATEGY отсутствует, это стратегия по умолчанию, если стратегия по умолчанию не была переопределена с помощью CMAKE_EP_GIT_REMOTE_UPDATE_STRATEGY (см. ниже). Обратите внимание, что если ветка, указанная в GIT_TAG, отличается от отслеживаемой удалённой ветки, перебазирование не безопасно. В этом случае REBASE будет молчаливо рассматриваться как CHECKOUT вместо этого.

REBASE_CHECKOUT

То же, что и REBASE, за исключением того, что если перебазирование завершится ошибкой, будет создан аннотированный тег в исходном положении HEAD до перебазирования, а затем текущая ветка будет переключена на GIT_TAG так же, как и при стратегии CHECKOUT. Сообщение, хранящееся в аннотированном теге, будет содержать информацию о попытке, а имя тега будет включать отметку времени, так что каждый неудачный запуск добавит новый тег. Эта стратегия гарантирует, что никакие изменения не будут потеряны, но обновления всегда должны выполняться успешно, если GIT_TAG ссылается на действительный ref, если только нет несохранённых изменений, которые не могут быть успешно восстановлены.

Переменная CMAKE_EP_GIT_REMOTE_UPDATE_STRATEGY может быть установлена для переопределения стратегии по умолчанию. Эта переменная не должна устанавливаться проектом, она предназначена для установки пользователем. Она предназначена в первую очередь для использования в скриптах непрерывной интеграции, чтобы обеспечить, что при переписывании истории на удалённой ветке сборка не приведёт к непреднамеренным изменениям или сбоям сборки, возникшим в результате конфликтов во время перебазирования.

Subversion

SVN_REPOSITORY <url>

URL репозитория Subversion.

SVN_REVISION -r<rev>

Ревизия для извлечения из репозитория Subversion.

SVN_USERNAME <username>

Имя пользователя для извлечения и обновления Subversion.

SVN_PASSWORD <password>

Пароль для извлечения и обновления Subversion.

SVN_TRUST_CERT <bool>

Указывает, следует ли доверять сертификату сайта сервера Subversion. При включении параметр --trust-server-cert передаётся командам извлечения и обновления svn.

Mercurial

HG_REPOSITORY <url>

URL репозитория Mercurial.

HG_TAG <tag>

Имя ветки, тега или ID коммита Mercurial.

CVS

CVS_REPOSITORY <cvsroot>

CVSROOT репозитория CVS.

CVS_MODULE <mod>

Модуль для извлечения из репозитория CVS.

CVS_TAG <tag>

Тег для извлечения из репозитория CVS.

Параметры шага обновления

Всякий раз, когда CMake перевыполняется, по умолчанию исходные файлы внешнего проекта обновляются, если метод загрузки поддерживает обновления (например, репозиторий Git проверяется, если GIT_TAG не ссылается на конкретный коммит).

UPDATE_COMMAND <cmd>...

Переопределяет шаг обновления метода загрузки пользовательской командой. Команда может использовать generator expressions.

UPDATE_DISCONNECTED <bool>

Новое в версии 3.2.

При включении этот параметр пропускает шаг обновления (но см. ниже изменение поведения, когда это не так). Он не препятствует шагу загрузки. Шаг обновления всё ещё может быть добавлен как целевой шаг (см. ExternalProject_Add_StepTargets()) и вызван вручную. Это полезно, если вы хотите позволить разработчикам строить проект, будучи отключёнными от сети (хотя сеть может всё ещё потребоваться для шага загрузки).

Изменено в версии 3.27: Если UPDATE_DISCONNECTED имеет значение true, шаг обновления будет выполнен, если какие-либо данные об обновлении или шаге загрузки изменены. Кроме того, если используется метод загрузки/обновления Git, логика обновления будет изменена для пропуска попыток связаться с удалённым сервером. Если GIT_TAG упоминает ref, который не известен локально, шаг обновления завершится фатальной ошибкой.

Если этот параметр присутствует, рекомендуется сделать его переменной кэша под контролем разработчика, а не жёстко заданным значением. Если этот параметр отсутствует, значение по умолчанию берется из свойства каталога EP_UPDATE_DISCONNECTED . Если оно тоже не определено, обновления выполняются в обычном режиме. Свойство каталога EP_UPDATE_DISCONNECTED предназначено для удобства управления поведением UPDATE_DISCONNECTED для всего раздела иерархии каталогов проекта и может быть более удобным способом предоставления разработчикам контроля над тем, выполнять ли обновления (предполагая, что проект также предоставляет переменную кэша или другой удобный способ установки свойства каталога).

Это может привести к автоматическому созданию целевого шага для шага download . См. политику CMP0114.

Параметры шага применения патчей

PATCH_COMMAND <cmd>...

Указывает пользовательскую команду для применения патчей к исходным файлам после обновления. По умолчанию команда применения патчей не определена. Обратите внимание, что определение подходящей команды, которая работает надёжно, особенно для методов загрузки, таких как Git, где изменение GIT_TAG не отбросит изменения от предыдущего патча, а команда применения патчей будет вызвана снова после обновления до нового тега, может быть довольно сложной.

Параметры шага конфигурации

Этап настройки выполняется после этапов загрузки и обновления. По умолчанию предполагается, что внешний проект — это проект CMake, но это можно переопределить при необходимости.

CONFIGURE_COMMAND <cmd>...

Команда настройки по умолчанию выполняет CMake с несколькими параметрами, основанными на основном проекте. Добавленные параметры, как правило, — это только те, которые необходимы для использования того же генератора, что и в основном проекте, но параметр CMAKE_GENERATOR может быть задан для переопределения этого. Проект отвечает за добавление любых деталей цепочки инструментов, флагов или других настроек, которые он хочет повторно использовать из основного проекта или каким-либо другим способом указать (см. CMAKE_ARGS, CMAKE_CACHE_ARGS и CMAKE_CACHE_DEFAULT_ARGS ниже).

Для внешних проектов, не являющихся проектами CMake, необходимо использовать параметр CONFIGURE_COMMAND для переопределения команды настройки по умолчанию (generator expressions поддерживаются). Для проектов, не требующих этапа настройки, укажите этот параметр с пустой строкой в качестве команды для выполнения.

CMAKE_COMMAND /.../cmake

Укажите альтернативную исполняемую программу cmake для этапа настройки (используйте абсолютный путь). Это, как правило, не рекомендуется, так как обычно желательно использовать ту же версию CMake во всем процессе сборки. Этот параметр игнорируется, если команда настройки была указана вручную с помощью CONFIGURE_COMMAND.

CMAKE_GENERATOR <gen>

Переопределите генератор CMake, используемый на этапе настройки. Без этого параметра будет использован тот же генератор, что и в основной сборке. Этот параметр игнорируется, если команда настройки была указана вручную с помощью параметра CONFIGURE_COMMAND.

CMAKE_GENERATOR_PLATFORM <platform>

Новое в версии 3.1.

Передайте имя платформы, специфичное для генератора, команде CMake (см. CMAKE_GENERATOR_PLATFORM). Указание этого параметра без параметра CMAKE_GENERATOR является ошибкой.

CMAKE_GENERATOR_TOOLSET <toolset>

Передайте имя набора инструментов, специфичное для генератора, команде CMake (см. CMAKE_GENERATOR_TOOLSET). Указание этого параметра без параметра CMAKE_GENERATOR является ошибкой.

CMAKE_GENERATOR_INSTANCE <instance>

Новое в версии 3.11.

Передайте команде CMake выбор конкретного экземпляра генератора (см. CMAKE_GENERATOR_INSTANCE). Указание этого параметра без параметра CMAKE_GENERATOR является ошибкой.

CMAKE_ARGS <arg>...

Указанные аргументы передаются в командную строку команды cmake. Это могут быть любые аргументы, которые понимает команда cmake, а не только значения кэша, определённые аргументами -D... (см. также CMake Options).

Новое в версии 3.3: Аргументы могут использовать generator expressions.

CMAKE_CACHE_ARGS <arg>...

Это альтернативный способ задания переменных кэша, когда могут возникнуть проблемы с длиной командной строки. Аргументы должны быть в формате -Dvar:STRING=value, которые затем преобразуются в команды CMake set() с использованием параметра FORCE. Эти команды set() записываются в скрипт предварительной загрузки, который затем применяется с помощью параметра командной строки cmake -C.

Новое в версии 3.3: Аргументы могут использовать generator expressions.

CMAKE_CACHE_DEFAULT_ARGS <arg>...

Новое в версии 3.2.

Это то же самое, что и параметр CMAKE_CACHE_ARGS, за исключением того, что команды set() не включают ключевое слово FORCE. Это означает, что значения действуют только как начальные значения по умолчанию и не переопределяют переменные, уже заданные в предыдущем запуске. Используйте этот параметр с осторожностью, так как это может привести к различному поведению в зависимости от того, запускается ли сборка с чистого каталога или используются предыдущие результаты сборки.

Новое в версии 3.15: Если генератор CMake — Green Hills MULTI, и он не переопределён, настройки основного проекта для набора инструментов GHS и переменных кэша настройки целевой системы будут перенесены во внешний проект.

SOURCE_SUBDIR <dir>

Новое в версии 3.7.

Когда параметр CONFIGURE_COMMAND не указан, этап настройки предполагает, что внешний проект имеет файл CMakeLists.txt в корне своей директории исходных кодов (т.е. в SOURCE_DIR). Параметр SOURCE_SUBDIR может быть использован для указания альтернативной директории в дереве исходных кодов в качестве корня дерева исходных кодов CMake. Это должен быть относительный путь, который будет интерпретироваться как относительный к SOURCE_DIR.

Новое в версии 3.14: Когда параметр BUILD_IN_SOURCE включен, параметр BUILD_COMMAND используется для указания альтернативной директории в дереве исходных кодов.

CONFIGURE_HANDLED_BY_BUILD <bool>

Новое в версии 3.20.

Включение этого параметра ослабляет зависимость этапа настройки от других внешних проектов до зависимости только по порядку. Это означает, что этап настройки будет выполнен после сборки его внешних зависимостей, но он не будет помечен как грязный, когда одна из его внешних зависимостей пересобирается. Этот параметр можно включить, когда этап сборки достаточно умен, чтобы определить, нужно ли перевыполнять этап настройки. CMake и Meson являются примерами систем сборки, этап сборки которых достаточно умен, чтобы знать, нужно ли перевыполнять этап настройки.

Параметры этапа сборки

Если этап настройки предположил, что внешний проект использует CMake в качестве своей системы сборки, то этап сборки также будет использовать CMake. В противном случае этап сборки предположит Makefile-основанную сборку и просто запустит make без аргументов в качестве этапа сборки по умолчанию. Это можно переопределить с помощью пользовательских команд сборки, если необходимо.

Если и основной проект, и внешний проект используют make в качестве своего инструмента сборки, этап сборки внешнего проекта вызывается как рекурсивный make с помощью $(MAKE). Это позволит передать некоторые настройки инструмента сборки от основного проекта внешнему проекту. Если либо основной проект, либо внешний проект не используют make, никакие настройки инструмента сборки не будут переданы внешнему проекту, за исключением тех, что установлены этапом настройки (т.е. запуск ninja -v в основном проекте не передаст -v в этап сборки внешнего проекта, даже если он также использует ninja в качестве своего инструмента сборки).

BUILD_COMMAND <cmd>...

Переопределяет команду сборки по умолчанию (generator expressions поддерживаются). Если этот параметр не задан, команда сборки по умолчанию будет выбрана для интеграции со основной сборкой наиболее подходящим образом (например, с использованием рекурсивного make для генераторов Makefile или cmake --build, если проект использует сборку CMake). Этот параметр может быть задан пустой строкой, чтобы сделать шаг сборки ничего не делающим.

BUILD_IN_SOURCE <bool>

При включении этого параметра сборка будет выполнена непосредственно в дереве исходных кодов внешнего проекта. Это следует обычно избегать, предпочтительнее использовать отдельный каталог сборки, но это может быть полезно, когда внешний проект предполагает сборку в исходном коде. Параметр BINARY_DIR не должен быть указан, если сборка выполняется в исходном коде.

BUILD_ALWAYS <bool>

Включение этого параметра заставляет шаг сборки всегда выполняться. Это может быть самый простой способ надёжно убедиться, что зависимости сборки внешнего проекта оцениваются, а не полагаться на метод по умолчанию, основанный на отметке времени успешного выполнения. Этот параметр обычно не нужен, если не ожидается, что разработчики будут изменять что-то, от чего зависит сборка внешнего проекта, способом, который не обнаруживается через зависимости целевых шагов (например, SOURCE_DIR используется без метода загрузки, и разработчики могут изменить исходные коды в SOURCE_DIR).

BUILD_BYPRODUCTS <file>...

Новое в версии 3.2.

Указывает файлы, которые будут сгенерированы командой сборки, но которые могут или могут не иметь своё время изменения, обновлённое последующими сборками. Это также может потребоваться для явного объявления зависимостей при использовании генератора Ninja. В конечном итоге эти файлы передаются как BYPRODUCTS в собственное вызов шага сборки add_custom_command(), который имеет дополнительную документацию.

BUILD_JOB_SERVER_AWARE <bool>

Новое в версии 3.28.

Указывает, что шаг сборки осведомлён о сервере задач GNU Make. См. документацию add_custom_command() по её параметру JOB_SERVER_AWARE для подробностей. Этот параметр актуален только при указании явного BUILD_COMMAND.

Параметры шага установки

Если шаг конфигурации предположил, что внешний проект использует CMake в качестве системы сборки, шаг установки также будет. В противном случае шаг установки предположит сборку на основе Makefile и просто выполнит make install как шаг сборки по умолчанию. Это может быть переопределено пользовательскими командами установки, если необходимо.

INSTALL_COMMAND <cmd>...

Шаг установки внешнего проекта вызывается как часть основной сборки. Он выполняется после шага сборки внешнего проекта и может быть до или после шага тестирования внешнего проекта (см. параметр TEST_BEFORE_INSTALL ниже). Правила установки внешнего проекта не являются частью правил установки основного проекта, поэтому, если что-либо из внешнего проекта должно быть установлено в рамках основной сборки, это нужно указать в основной сборке как дополнительные install() команды. Шаг установки по умолчанию собирает цель install внешнего проекта, но это можно переопределить с помощью пользовательской команды с помощью этого параметра (generator expressions поддерживаются). Передача пустой строки как <cmd> делает шаг установки ничего не делающим.

INSTALL_BYPRODUCTS <file>...

Новое в версии 3.26.

Указывает файлы, которые будут сгенерированы командой установки, но которые могут или могут не иметь своё время изменения, обновлённое последующими установками. Это также может потребоваться для явного объявления зависимостей при использовании генератора Ninja. В конечном итоге эти файлы передаются как BYPRODUCTS в собственный вызов шага установки add_custom_command(), который имеет дополнительную документацию.

Параметры шага тестирования

Шаг тестирования определён только если указан хотя бы один из следующих TEST_... параметров.

TEST_COMMAND <cmd>...

Переопределяет команду тестирования по умолчанию (generator expressions поддерживаются). Если этот параметр не задан, по умолчанию шаг тестирования собирает целевой test внешнего проекта. Этот параметр может быть задан <cmd> как пустая строка, что позволяет шагу тестирования всё ещё быть определённым, но он ничего не будет делать. Не указывайте ни один из других TEST_... параметров, если передаётся пустая строка как команда тестирования, но предпочтительнее опустить все TEST_... параметры полностью, если целевой объект шага тестирования не нужен.

TEST_BEFORE_INSTALL <bool>

При включении этого параметра шаг тестирования будет выполнен до шага установки. По умолчанию шаг тестирования выполняется после шага установки.

TEST_AFTER_INSTALL <bool>

Этот параметр в основном полезен как способ указать, что шаг тестирования желателен, но все параметры по умолчанию достаточны. Указание этого параметра с логическим значением true гарантирует, что шаг тестирования определён и что он выполняется после шага установки. Если оба TEST_BEFORE_INSTALL и TEST_AFTER_INSTALL включены, второй будет проигнорирован.

TEST_EXCLUDE_FROM_MAIN <bool>

Новое в версии 3.2.

Если включено, целевой ALL основного проекта не будет зависеть от шага тестирования. Это может быть полезным способом гарантировать, что шаг тестирования определён, но вызывается только при запросе вручную. Это может привести к автоматическому созданию целевого объекта шага как для install , так и для шага build . См. политику CMP0114.

Параметры ведения журналов вывода

Каждый из следующих LOG_... параметров может использоваться для обертывания соответствующего шага в скрипт, чтобы захватить его вывод в файлы. Файлы журналов будут созданы в LOG_DIR , если указано, в противном случае - в каталоге STAMP_DIR с именами файлов, специфичными для шага.

LOG_DOWNLOAD <bool>

При включении вывод шага загрузки записывается в файлы.

LOG_UPDATE <bool>

При включении вывод шага обновления записывается в файлы.

LOG_PATCH <bool>

Новое в версии 3.14.

При включении вывод шага применения исправлений записывается в файлы.

LOG_CONFIGURE <bool>

При включении вывод шага конфигурации записывается в файлы.

LOG_BUILD <bool>

При включении вывод шага сборки записывается в файлы.

LOG_INSTALL <bool>

При включении вывод шага установки записывается в файлы.

LOG_TEST <bool>

При включении вывод шага тестирования записывается в файлы.

LOG_MERGED_STDOUTERR <bool>

Новое в версии 3.14.

При включении stdout и stderr будут объединены для любого шага, вывод которого записывается в файлы.

LOG_OUTPUT_ON_FAILURE <bool>

Новое в версии 3.14.

Этот параметр имеет эффект только если включен хотя бы один из других LOG_<step> параметров. Если произошла ошибка для шага, вывод которого записан в файл, этот вывод будет напечатан в консоль, если LOG_OUTPUT_ON_FAILURE установлено в true. В случаях, когда записывается большой объём вывода, может быть напечатан только конец этого вывода в консоль.

Параметры доступа к терминалу

В некоторых случаях шаги могут получить прямой доступ к терминалу. Предоставление шагу доступа к терминалу может позволить ему получать ввод с терминала, если это необходимо, например, для аутентификационных данных, не предоставленных другими вариантами. С генератором Ninja эти параметры размещают шаги в console job pool. Каждый шаг может получить доступ к терминалу индивидуально с помощью следующих параметров:

USES_TERMINAL_DOWNLOAD <bool>

Предоставить шагу загрузки доступ к терминалу.

USES_TERMINAL_UPDATE <bool>

Предоставить шагу обновления доступ к терминалу.

USES_TERMINAL_PATCH <bool>

Добавлена в версии 3.23.

Предоставить шагу исправления доступ к терминалу.

USES_TERMINAL_CONFIGURE <bool>

Предоставить шагу конфигурации доступ к терминалу.

USES_TERMINAL_BUILD <bool>

Предоставить шагу сборки доступ к терминалу.

USES_TERMINAL_INSTALL <bool>

Предоставить шагу установки доступ к терминалу.

USES_TERMINAL_TEST <bool>

Предоставить шагу тестирования доступ к терминалу.

Параметры цели

DEPENDS <targets>...

Укажите другие цели, от которых зависит внешний проект. Другие цели будут обновлены до выполнения любого из шагов внешнего проекта. Поскольку внешний проект использует дополнительные пользовательские цели для каждого шага внутри, параметр DEPENDS является наиболее удобным способом обеспечения зависимости всех этих шагов от других целей. Простое выполнение add_dependencies(<name> <targets>) не сделает ни один из шагов зависимым от <targets>.

EXCLUDE_FROM_ALL <bool>

При включении этот параметр исключает внешний проект из целевой задачи ALL основного построения.

STEP_TARGETS <step-target>...

Генерировать пользовательские цели для указанных шагов. Это требуется, если шаги нужно запускать вручную или если их нужно использовать в качестве зависимостей других целей. Если этот параметр не указан, значение по умолчанию берётся из свойства каталога EP_STEP_TARGETS. Смотрите ExternalProject_Add_StepTargets() ниже для более подробного обсуждения последствий этого параметра.

INDEPENDENT_STEP_TARGETS <step-target>...

Устарело начиная с версии 3.19: Это разрешено только в том случае, если политика CMP0114 не установлена в NEW.

Генерирует пользовательские цели для указанных шагов и предотвращает применение к этим целям обычных зависимостей. Если этот параметр не указан, значение по умолчанию берётся из свойства каталога EP_INDEPENDENT_STEP_TARGETS. Этот параметр в основном полезен для того, чтобы позволить отдельным шагам выполняться независимо, например, для настройки CDash, где каждый шаг должен запускаться и отчитываться индивидуально, а не как одно целое построение. Смотрите ExternalProject_Add_StepTargets() ниже для дальнейшего обсуждения эффектов этого параметра.

Разные параметры

LIST_SEPARATOR <sep>

Для любого из различных параметров ..._COMMAND и CMAKE_ARGS, ExternalProject заменит <sep> на ; в указанных командных строках. Это можно использовать для обеспечения того, чтобы команда содержала буквенный ; в ней, в противном случае прямой вывод будет интерпретироваться как разделители аргументов API CMake вместо этого. Обратите внимание, что разделитель следует выбирать для предотвращения путаницы с другими использованиями последовательности, не являющимися разделителями списков. Например, использование LIST_SEPARATOR позволяет передавать списки значений в переменные кэша CMake в командной строке:

ExternalProject_Add(example
  ... # Download options, etc.
  LIST_SEPARATOR ","
  CMAKE_ARGS "-DCMAKE_PREFIX_PATH:STRING=${first_prefix},${second_prefix}"
)

COMMAND <cmd>...

Любой из других параметров ..._COMMAND может иметь дополнительные команды, присоединённые к ним, следуя за ними, по мере необходимости, такими же параметрами COMMAND ... (generator expressions поддерживаются). Например:

ExternalProject_Add(example
  ... # Download options, etc.
  BUILD_COMMAND ${CMAKE_COMMAND} -E echo "Starting $<CONFIG> build"
  COMMAND       ${CMAKE_COMMAND} --build <BINARY_DIR> --config $<CONFIG>
  COMMAND       ${CMAKE_COMMAND} -E echo "$<CONFIG> build complete"
)

Также следует отметить, что каждый шаг сборки создаётся с помощью вызова ExternalProject_Add_Step(). Смотрите документацию этой команды для автоматических подстановок, которые поддерживаются для некоторых параметров.

Получение свойств проекта

ExternalProject_Get_Property

Функция ExternalProject_Get_Property() извлекает свойства целевых задач внешнего проекта:

ExternalProject_Get_Property(<name> <prop1> [<prop2>...])

Функция сохраняет значения свойств в переменных с тем же именем. Имена свойств соответствуют именам аргументов ключевых слов ExternalProject_Add(). Например, каталог исходных данных можно извлечь следующим образом:

ExternalProject_Get_property(myExtProj SOURCE_DIR)
message("Source dir of myExtProj = ${SOURCE_DIR}")

Явное управление шагами

Функция ExternalProject_Add() сама по себе часто достаточна для включения внешнего проекта в основное построение. Некоторые сценарии требуют дополнительных действий для реализации желаемого поведения, например, добавления пользовательского шага или предоставления шагов в качестве вручную запускаемых целей. Функции ExternalProject_Add_Step(), ExternalProject_Add_StepTargets() и ExternalProject_Add_StepDependencies обеспечивают необходимый контроль на уровне шагов для реализации таких возможностей на уровне шагов.

ExternalProject_Add_Step

Функция ExternalProject_Add_Step() определяет дополнительный пользовательский шаг для внешнего проекта, определённого предыдущим вызовом ExternalProject_Add():

ExternalProject_Add_Step(<name> <step> [<option>...])

<name> совпадает с именем, переданным в исходном вызове ExternalProject_Add(). Указанный <step> не должен совпадать с одним из предопределённых шагов (mkdir, download, update, patch, configure, build, install или test). Поддерживаемые параметры:

COMMAND <cmd>...

Командная строка, которая должна быть выполнена в рамках этого пользовательского шага (generator expressions поддерживаются). Этот параметр может быть указан несколько раз, чтобы указать несколько команд, которые должны быть выполнены в порядке их следования.

COMMENT "<text>..."

Текст, который будет напечатан при выполнении пользовательского шага.

DEPENDEES <step>...

Другие шаги (пользовательские или предопределённые), от которых зависит этот шаг.

DEPENDERS <step>...

Другие шаги (пользовательские или предопределённые), которые зависят от этого нового пользовательского шага.

DEPENDS <file>...

Файлы, от которых зависит этот пользовательский шаг.

INDEPENDENT <bool>

Добавлена в версии 3.19.

Указывает, является ли этот шаг независимым от внешних зависимостей, указанных параметром DEPENDS в вызове ExternalProject_Add(). По умолчанию — FALSE. Шаги, помеченные как независимые, могут зависеть только от других шагов, помеченных как независимые. Смотрите политику CMP0114.

Обратите внимание, что использование термина «независимый» относится только к независимости от внешних целей, указанных параметром DEPENDS, и ортогонально зависимостям шага от других шагов.

Если для независимого шага создаётся целевой объект с помощью параметра STEP_TARGETS функции ExternalProject_Add() или функции ExternalProject_Add_StepTargets(), он не будет зависеть от внешних целей, но может зависеть от целей других шагов.

BYPRODUCTS <file>...

Добавлена в версии 3.2.

Файлы, которые будут сгенерированы этим пользовательским шагом, но у которых время модификации может или не может быть обновлено последующими сборками. Это также может быть необходимо для явного объявления зависимостей при использовании генератора Ninja. Этот список файлов в конечном итоге будет передан в качестве параметра BYPRODUCTS к add_custom_command(), используемой для реализации пользовательского шага внутри, что имеет дополнительную документацию.

ALWAYS <bool>

При включении этот параметр указывает, что пользовательский шаг должен всегда выполняться (т. е. что он всегда считается устаревшим).

JOB_SERVER_AWARE <bool>

Добавлена в версии 3.28.

Указывает, что пользовательский шаг учитывает сервер заданий GNU Make. Подробности см. в документации к параметру JOB_SERVER_AWARE команды add_custom_command().

EXCLUDE_FROM_MAIN <bool>

При включении этот параметр указывает, что основная цель внешнего проекта не зависит от пользовательского шага. Это может привести к автоматическому созданию целевых объектов шагов, от которых зависит этот шаг. Смотрите политику CMP0114.

WORKING_DIRECTORY <dir>

Указывает рабочую директорию, которая будет установлена перед выполнением команд пользовательского шага. Если этот параметр не указан, директория будет соответствовать значению CMAKE_CURRENT_BINARY_DIR в момент вызова ExternalProject_Add_Step().

LOG <bool>

Если установлено, это приводит к тому, что вывод от пользовательского шага сохраняется в файлы в LOG_DIR внешнего проекта, если он указан, или в STAMP_DIR.

USES_TERMINAL <bool>

При включении пользовательский шаг получает прямой доступ к терминалу, если это возможно.

Командная строка, комментарии, рабочая директория и побочные продукты каждого стандартного и пользовательского шага обрабатываются для замены маркеров <SOURCE_DIR>, <SOURCE_SUBDIR>, <BINARY_DIR>, <INSTALL_DIR> <TMP_DIR>, <DOWNLOAD_DIR> и <DOWNLOADED_FILE> соответствующими значениями свойств, определёнными в исходном вызове ExternalProject_Add().

Новое в версии 3.3: Замена маркеров расширена и включает побочные продукты.

Новое в версии 3.11: Маркер подстановки <DOWNLOAD_DIR>.

ExternalProject_Add_StepTargets

Функция ExternalProject_Add_StepTargets() генерирует цели для шагов, перечисленных в списке. Имя каждой созданной цели будет иметь вид <name>-<step>:

ExternalProject_Add_StepTargets(<name> <step1> [<step2>...])

Создание цели для шага позволяет использовать её в качестве зависимости другой цели или запускать её вручную. Наличие целей для конкретных шагов также позволяет управлять ими независимо друг от друга, указывая цели в командной строке сборки. Например, вы можете отправлять данные в панель мониторинга субпроекта, где хотите выполнить конфигурацию сборки, затем отправить данные на панель мониторинга, за которым следует этап сборки, а затем тесты. Если вы вызываете пользовательскую цель, которая зависит от шага где-то посредине цепочки зависимостей шагов, то все предыдущие шаги также будут выполнены, чтобы убедиться, что всё обновлено.

Внутренне, ExternalProject_Add() вызывает ExternalProject_Add_Step() для создания каждого шага. Если были указаны любые STEP_TARGETS, то ExternalProject_Add_StepTargets() также будет вызвано после ExternalProject_Add_Step(). Даже если шаг не указан в опции STEP_TARGETS, ExternalProject_Add_StepTargets() всё равно может быть вызвано позже для ручного определения цели для шага.

Опция STEP_TARGETS для ExternalProject_Add() является обычно самым простым способом гарантировать создание целей для конкретных шагов, которые нас интересуют. Для пользовательских шагов ExternalProject_Add_StepTargets() необходимо вызывать явно, если цель также должна быть создана для этого пользовательского шага. Альтернативой этим двум вариантам является заполнение свойства каталога EP_STEP_TARGETS. Оно действует как значение по умолчанию для опций целей шагов и может сэкономить время, не нужно будет многократно указывать те же наборы целей шагов, когда определяются несколько внешних проектов.

New in version 3.19: Если CMP0114 установлено в значение NEW, цели шагов полностью отвечают за выполнение пользовательских команд, реализующих их шаги. Основная цель, созданная ExternalProject_Add зависит от целей шагов, а цели шагов зависят друг от друга. Зависимости на уровне целей соответствуют зависимостям на уровне файлов, используемым пользовательскими командами для каждого шага. Цели шагов, созданных с помощью опции INDEPENDENT ExternalProject_Add_Step() не зависят от внешних целей, указанных в опции DEPENDS ExternalProject_Add(). Предопределённые шаги mkdir, download, update, и patch независимы.

Если CMP0114 не равно NEW, доступно следующее устаревшее поведение:

• Может быть указана устаревшая опция NO_DEPENDS, сразу после <name> и перед первым шагом. Если опция NO_DEPENDS указана, цель шага не будет зависеть от зависимостей внешнего проекта (т. е. от любых зависимостей пользовательской цели <name> внешнего проекта, созданной с помощью ExternalProject_Add()). Это обычно безопасно для шагов download, update и patch, так как им обычно не требуется обновление и построение зависимостей. Однако использование NO_DEPENDS для любого из других предопределённых шагов может нарушить параллельную сборку. Используйте NO_DEPENDS только в тех случаях, когда точно известно, что указанные шаги не имеют зависимостей. Для пользовательских шагов подумайте, требуют ли пользовательские команды, чтобы зависимости были сконфигурированы, построены и установлены.
• Опция INDEPENDENT_STEP_TARGETS для ExternalProject_Add() или свойство каталога EP_INDEPENDENT_STEP_TARGETS говорит функции о вызове ExternalProject_Add_StepTargets() внутри с помощью опции NO_DEPENDS для указанных шагов.

ExternalProject_Add_StepDependencies

New in version 3.2.

Функция ExternalProject_Add_StepDependencies() может использоваться для добавления зависимостей к шагу. Добавляемые зависимости должны быть целями, которые CMake уже знает (это могут быть обычные исполняемые или библиотечные цели, пользовательские цели или даже цели шагов другого внешнего проекта):

ExternalProject_Add_StepDependencies(<name> <step> <target1> [<target2>...])

Эта функция заботится о настройке зависимостей как на уровне целей, так и на уровне файлов и гарантирует, что параллельная сборка не будет нарушена. Она должна использоваться вместо add_dependencies() при добавлении зависимостей для некоторых целей шагов, сгенерированных модулем ExternalProject.

Примеры

Следующий пример демонстрирует, как загрузить и собрать гипотетический проект под названием FooBar с github:

include(ExternalProject)
ExternalProject_Add(foobar
  GIT_REPOSITORY    git@github.com:FooCo/FooBar.git
  GIT_TAG           origin/release/1.2.3
)

Для примера также определите второй гипотетический внешний проект под названием SecretSauce, который загружается с веб-сервера. Приведены два URL-адреса, чтобы воспользоваться более быстрой внутренней сетью, если она доступна, с откатом на более медленный внешний сервер. Проект является типичным проектом Makefile без шага конфигурации, поэтому некоторые из команд по умолчанию переопределяются. Требуется только собрать цель sauce:

find_program(MAKE_EXE NAMES gmake nmake make)
ExternalProject_Add(secretsauce
  URL               http://intranet.somecompany.com/artifacts/sauce-2.7.tgz
                    https://www.somecompany.com/downloads/sauce-2.7.zip
  URL_HASH          MD5=d41d8cd98f00b204e9800998ecf8427e
  CONFIGURE_COMMAND ""
  BUILD_COMMAND     ${MAKE_EXE} sauce
)

Предположим, что шаг сборки secretsauce требует, чтобы foobar уже был собран. Это можно обеспечить следующим образом:

ExternalProject_Add_StepDependencies(secretsauce build foobar)

Другой вариант — создать пользовательскую цель для шага сборки foobar и сделать secretsauce зависимой от неё, а не от всего проекта foobar. Это означает, что нужно собрать только foobar, не нужно запускать шаги установки или тестирования перед сборкой secretsauce. Зависимость также может быть определена вместе с проектом secretsauce:

ExternalProject_Add_StepTargets(foobar build)
ExternalProject_Add(secretsauce
  URL               http://intranet.somecompany.com/artifacts/sauce-2.7.tgz
                    https://www.somecompany.com/downloads/sauce-2.7.zip
  URL_HASH          MD5=d41d8cd98f00b204e9800998ecf8427e
  CONFIGURE_COMMAND ""
  BUILD_COMMAND     ${MAKE_EXE} sauce
  DEPENDS           foobar-build
)

Вместо вызова ExternalProject_Add_StepTargets(), цель может быть определена вместе с самим проектом foobar:

ExternalProject_Add(foobar
  GIT_REPOSITORY git@github.com:FooCo/FooBar.git
  GIT_TAG        origin/release/1.2.3
  STEP_TARGETS   build
)

Если многие внешние проекты должны иметь один и тот же набор целей шагов, настройка свойства каталога может быть более удобной. Цель шага build может быть создана автоматически, задав свойство каталога EP_STEP_TARGETS перед созданием внешних проектов с помощью ExternalProject_Add():

set_property(DIRECTORY PROPERTY EP_STEP_TARGETS build)

Наконец, предположим, что secretsauce предоставляет скрипт под названием makedoc, который может использоваться для генерации собственной документации. Предположим также, что скрипт ожидает, что каталог вывода будет единственным параметром, и что он должен выполняться из каталога исходного кода secretsauce. Пользовательский шаг и пользовательская цель для запуска скрипта могут быть определены следующим образом:

ExternalProject_Add_Step(secretsauce docs
  COMMAND           <SOURCE_DIR>/makedoc <BINARY_DIR>
  WORKING_DIRECTORY <SOURCE_DIR>
  COMMENT           "Building secretsauce docs"
  ALWAYS            TRUE
  EXCLUDE_FROM_MAIN TRUE
)
ExternalProject_Add_StepTargets(secretsauce docs)

Затем пользовательский шаг может быть запущен из основной сборки следующим образом:

cmake --build . --target secretsauce-docs