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, каталог, в котором должен быть выложен, клонирован и т.д. репозиторий. Если метод загрузки не указан, он должен указывать на существующий каталог, где внешний проект уже был распакован или клонирован/выложен.

Примечание

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

BINARY_DIR <dir>

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

INSTALL_DIR <dir>

Префикс установки, который будет помещён в <INSTALL_DIR> placeholder. Это не настраивает внешний проект на установку в указанный префикс. Для этого необходимо передать соответствующие аргументы шагу настройки внешнего проекта, например, используя <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.

Позволяет отключить часть извлечения во время загрузки, передав значение boolean 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). Это гарантирует, что если удалённый сервер изменит имя тега или перебазирует или перепишет историю ветки, локальная копия всё равно будет обновлена правильно. Однако в целом для многих причин предпочтительнее указывать хэш-код коммита:

• Если локальная копия уже содержит коммит, соответствующий хэшу, для проверки изменений каждый раз при повторном запуске CMake не требуется выполнение git fetch. Это может значительно ускорить процесс, если используются многие внешние проекты.
• Использование конкретного хэша 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. Если есть несохранённые локальные изменения, они будут заархивированы, а затем извлечены после перебазирования. Если перебазирование или извлечение заархивированных изменений завершается ошибкой, перебазирование будет прервано, и сборка завершится с ошибкой. Если 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>

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

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 истинно, шаг обновления выполняется, если какие-либо данные о шаге обновления или загрузки изменены. Кроме того, если используется метод загрузки/обновления Git, логика обновления будет изменена, чтобы пропустить попытки связаться с удалённым сервером. Если GIT_TAG указывает на ссылку, которая не известна локально, шаг обновления завершится с ошибкой.

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

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

BYPRODUCTS <file>...

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

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

ALWAYS <bool>

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

JOB_SERVER_AWARE <bool>

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

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

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. Оно выступает в качестве значения по умолчанию для опций целевых задач шагов и может сэкономить время, не нужно многократно указывать один и тот же набор целевых задач шагов при определении нескольких внешних проектов.

Добавлена в версии 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

Добавлена в версии 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