cmake-generator-expressions(7)

Введение
Пробелы и кавычки
Отладка
Справочник по выражениям генератора

Введение

Выражения генератора вычисляются во время генерации системы сборки, чтобы получить информацию, специфичную для каждой конфигурации сборки. Они имеют вид $<...>. Например:

target_include_directories(tgt PRIVATE /opt/include/$<CXX_COMPILER_ID>)

Это расширится до /opt/include/GNU, /opt/include/Clang, и т. д., в зависимости от используемого C++ компилятора.

Выражения генератора допускаются в контексте многих свойств целевых объектов, таких как LINK_LIBRARIES, INCLUDE_DIRECTORIES, COMPILE_DEFINITIONS и другие. Они также могут быть использованы при использовании команд для заполнения этих свойств, таких как target_link_libraries(), target_include_directories(), target_compile_definitions() и другие. Они позволяют условную компоновку, условные определения, используемые при компиляции, условные каталоги включения и многое другое. Условия могут быть основаны на конфигурации сборки, свойствах целевых объектов, информации о платформе или любой другой запрашиваемой информации.

Выражения генератора могут быть вложенными:

target_compile_definitions(tgt PRIVATE
  $<$<VERSION_LESS:$<CXX_COMPILER_VERSION>,4.2.0>:OLD_COMPILER>
)

Вышеприведенное расширится до OLD_COMPILER, если CMAKE_CXX_COMPILER_VERSION меньше 4.2.0.

Пробелы и кавычки

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

При использовании add_custom_command() или add_custom_target(), используйте параметры VERBATIM и COMMAND_EXPAND_LISTS, чтобы обеспечить надельное разделение и цитирование аргументов.

# WRONG: Embedded space will be treated as an argument separator.
# This ends up not being seen as a generator expression at all.
add_custom_target(run_some_tool
  COMMAND some_tool -I$<JOIN:$<TARGET_PROPERTY:tgt,INCLUDE_DIRECTORIES>, -I>
  VERBATIM
)

# Better, but still not robust. Quotes prevent the space from splitting the
# expression. However, the tool will receive the expanded value as a single
# argument.
add_custom_target(run_some_tool
  COMMAND some_tool "-I$<JOIN:$<TARGET_PROPERTY:tgt,INCLUDE_DIRECTORIES>, -I>"
  VERBATIM
)

# Nearly correct. Using a semicolon to separate arguments and adding the
# COMMAND_EXPAND_LISTS option means that paths with spaces will be handled
# correctly. Quoting the whole expression ensures it is seen as a generator
# expression. But if the target property is empty, we will get a bare -I
# with nothing after it.
add_custom_target(run_some_tool
  COMMAND some_tool "-I$<JOIN:$<TARGET_PROPERTY:tgt,INCLUDE_DIRECTORIES>,;-I>"
  COMMAND_EXPAND_LISTS
  VERBATIM
)

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

# The $<BOOL:...> check prevents adding anything if the property is empty,
# assuming the property value cannot be one of CMake's false constants.
set(prop "$<TARGET_PROPERTY:tgt,INCLUDE_DIRECTORIES>")
add_custom_target(run_some_tool
  COMMAND some_tool "$<$<BOOL:${prop}>:-I$<JOIN:${prop},;-I>>"
  COMMAND_EXPAND_LISTS
  VERBATIM
)

Наконец, приведенный выше пример можно выразить более простым и надежным способом, используя альтернативное выражение генератора:

add_custom_target(run_some_tool
  COMMAND some_tool "$<LIST:TRANSFORM,$<TARGET_PROPERTY:tgt,INCLUDE_DIRECTORIES>,PREPEND,-I>"
  COMMAND_EXPAND_LISTS
  VERBATIM
)

Распространённая ошибка – попытка разбить выражение генератора на несколько строк с отступами:

# WRONG: New lines and spaces all treated as argument separators, so the
# generator expression is split and not recognized correctly.
target_compile_definitions(tgt PRIVATE
  $<$<AND:
      $<CXX_COMPILER_ID:GNU>,
      $<VERSION_GREATER_EQUAL:$<CXX_COMPILER_VERSION>,5>
    >:HAVE_5_OR_LATER>
)

Вместо этого используйте вспомогательные переменные с хорошо выбранными именами, чтобы создать читаемое выражение:

set(is_gnu "$<CXX_COMPILER_ID:GNU>")
set(v5_or_later "$<VERSION_GREATER_EQUAL:$<CXX_COMPILER_VERSION>,5>")
set(meet_requirements "$<AND:${is_gnu},${v5_or_later}>")
target_compile_definitions(tgt PRIVATE
  "$<${meet_requirements}:HAVE_5_OR_LATER>"
)

Отладка

Поскольку выражения генератора вычисляются во время генерации системы сборки, а не во время обработки файлов CMakeLists.txt, нет возможности проверить их результат с помощью команды message(). Один из возможных способов создания сообщений об отладке – добавление пользовательской цели:

add_custom_target(genexdebug COMMAND ${CMAKE_COMMAND} -E echo "$<...>")

После выполнения cmake вы можете собрать целевой объект genexdebug, чтобы напечатать результат выражения $<...> (например, запустить команду cmake --build ... --target genexdebug).

Другой способ – записывать сообщения об отладке в файл с помощью file(GENERATE):

file(GENERATE OUTPUT filename CONTENT "$<...>")

Справочник по выражениям генератора

Примечание

Данный справочник отличается от большей части документации CMake тем, что опускает угловые скобки <...> вокруг заглушек, таких как condition, string, target, и т. д. Это сделано для того, чтобы избежать возможности неправильной интерпретации этих заглушек как выражений генератора.

Условные выражения

Фундаментальная категория выражений генератора связана с условной логикой. Поддерживаются две формы условных выражений генератора:

$<condition:true_string>: Вычисляется как true_string, если condition равно 1, или пустая строка, если condition вычисляется как 0. Любое другое значение для condition приводит к ошибке.

$<IF:condition,true_string,false_string>: Новое в версии 3.8.

Вычисляется как true_string, если condition равно 1, или false_string, если condition равно 0. Любое другое значение для condition приводит к ошибке.

Новое в версии 3.28: Это выражение генератора выполняет короткое замыкание, так что выражения генератора в false_string не будут вычисляться, когда condition равно 1, и выражения генератора в true_string не будут вычисляться, когда условие равно 0.

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

$<$<CONFIG:Debug>:DEBUG_MODE>

Булевые значения condition, отличные от 1 или 0, могут быть обработаны, обернув их в выражение генератора $<BOOL:...>.

$<BOOL:string>

Преобразует string в 0 или 1. Вычисляется как 0, если выполняется одно из следующих условий:

string пустое,
string – это регистронезависимое равенство 0, FALSE, OFF, N, NO, IGNORE, или NOTFOUND, или
string оканчивается на суффикс -NOTFOUND (регистрозависимое).

В противном случае вычисляется как 1.

Выражение генератора $<BOOL:...> часто используется, когда condition предоставляется переменной CMake:

$<$<BOOL:${HAVE_SOME_FEATURE}>:-DENABLE_SOME_FEATURE>

Логические операторы

Поддерживаются обычные логические операторы:

$<AND:conditions>: где conditions — это список логических выражений, разделённых запятыми, все из которых должны иметь значение 1 или 0. Весь выражение имеет значение 1, если все условия 1. Если хоть одно условие 0, то всё выражение имеет значение 0.

$<OR:conditions>: где conditions — это список логических выражений, разделённых запятыми. Все из которых должны иметь значение 1 или 0. Весь выражение имеет значение 1, если хотя бы одно из conditions имеет значение 1. Если все conditions имеют значение 0, то всё выражение имеет значение 0.

$<NOT:condition>: condition должно иметь значение 0 или 1. Результатом выражения является 0, если condition имеет значение 1, в противном случае 1.

Новое в версии 3.28: Логические операторы работают по принципу короткого замыкания, таким образом, выражения генератора в списке аргументов не будут вычисляться, если значение возврата можно определить сразу.

Основные выражения сравнения

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

Сравнения строк

$<STREQUAL:string1,string2>

1 если string1 и string2 равны, в противном случае 0. Сравнение чувствительно к регистру. Для выполнения сравнения без учёта регистра, объедините с выражением генератора для преобразования строк. Например, следующее выражение имеет значение 1 если ${foo} имеет любое из значений BAR, Bar, bar, и т.д.

$<STREQUAL:$<UPPER_CASE:${foo}>,BAR>

$<EQUAL:value1,value2>: 1 если value1 и value2 численно равны, в противном случае 0.

Сравнения версий

$<VERSION_LESS:v1,v2>: 1 если v1 является версией меньше v2, в противном случае 0.

$<VERSION_GREATER:v1,v2>: 1 если v1 является версией больше v2, в противном случае 0.

$<VERSION_EQUAL:v1,v2>: 1 если v1 имеет такую же версию, как v2, в противном случае 0.

$<VERSION_LESS_EQUAL:v1,v2>: Новое в версии 3.7.

1 если v1 является версией меньше или равно v2, в противном случае 0.

$<VERSION_GREATER_EQUAL:v1,v2>: Новое в версии 3.7.

1 если v1 является версией больше или равно v2, в противном случае 0.

Преобразования строк

$<LOWER_CASE:string>: Содержимое string преобразуется в нижний регистр.

$<UPPER_CASE:string>: Содержимое string преобразуется в верхний регистр.

$<MAKE_C_IDENTIFIER:...>: Содержимое ... преобразуется в идентификатор C. Преобразование выполняется согласно поведению команды string(MAKE_C_IDENTIFIER).

Выражения списков

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

В каждом из следующих выражений генератора, связанных со списками, list не должно содержать запятых, если выражение генератора ожидает что-то после list. Например, выражение $<LIST:FIND,list,value> требует value после list. Поскольку запятая используется для разделения list и value, то list не может содержать запятую. Это ограничение не относится к команде list(), оно применимо только к выражениям генератора, работающим со списками.

Сравнения списков

$<IN_LIST:string,list>: Новое в версии 3.12.

1 если string является элементом в списке, разделённом точкой с запятой list, в противном случае 0. Используется сравнение, чувствительное к регистру.

Запросы к спискам

$<LIST:LENGTH,list>: Новое в версии 3.27.

Количество элементов в list.

$<LIST:GET,list,index,...>: Новое в версии 3.27.

Расширяется до списка элементов, указанных индексами из list.

$<LIST:SUBLIST,list,begin,length>: Новое в версии 3.27.

Подсписок заданного list . Если length равно 0, будет возвращён пустой список. Если length равно -1 или список меньше begin + length, будут возвращены оставшиеся элементы списка, начиная с begin.

$<LIST:FIND,list,value>: Новое в версии 3.27.

Индекс первого элемента в list с заданным value, или -1, если value не содержится в list.

Преобразования списков

$<LIST:JOIN,list,glue>: Новое в версии 3.27.

Преобразует list в одну строку со значением glue , вставленным между каждым элементом. По сути, это аналогичная операция, что и $<JOIN:list,glue>, но с другим поведением в отношении пустых элементов. $<LIST:JOIN,list,glue> сохраняет все пустые элементы, в то время как $<JOIN:list,glue> удаляет все пустые элементы из списка.

$<LIST:APPEND,list,item,...>: Новое в версии 3.27.

Список list с добавленными item. Несколько элементов должны быть разделены запятыми.

$<LIST:PREPEND,list,item,...>: Новое в версии 3.27.

Список list с вставленными item в начале. Если указано несколько элементов, они должны быть разделены запятыми, и порядок префиксов будет сохранён.

$<LIST:INSERT,list,index,item,...>

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

Список list с вставленными item (или несколькими элементами) в указанный index. Несколько элементов должны быть разделены запятыми.

Указание индекса за пределами допустимого диапазона является ошибкой. Допустимые индексы — от 0 до N, где N — длина списка включительно. Длина пустого списка равна 0.

$<LIST:POP_BACK,list>: Новое в версии 3.27.

Список list с удалённым последним элементом.

$<LIST:POP_FRONT,list>: Новое в версии 3.27.

Список list с удалённым первым элементом.

$<LIST:REMOVE_ITEM,list,value,...>: Новое в версии 3.27.

Список list со всеми вхождениями заданного value (или значений) удалены. Если указано несколько значений, они должны быть разделены запятыми.

END_OF_DOCUMENT_MARKER ```

$<LIST:REMOVE_AT,list,index,...>: Новое в версии 3.27.

Список list с удалённым элементом по каждому указанному index.

$<LIST:REMOVE_DUPLICATES,list>: Новое в версии 3.27.

Список list со всеми дублированными элементами удалены. Относительный порядок элементов сохраняется, но если обнаруживаются дубликаты, сохраняется только первый экземпляр. Результат совпадает с $<REMOVE_DUPLICATES:list>.

$<LIST:FILTER,list,INCLUDE|EXCLUDE,regex>: Новое в версии 3.27.

Список элементов из list, которые соответствуют (INCLUDE) или не соответствуют (EXCLUDE) регулярному выражению regex. Результат совпадает с $<FILTER:list,INCLUDE|EXCLUDE,regex>.

$<LIST:TRANSFORM,list,ACTION[,SELECTOR]>

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

Список list преобразован путём применения ACTION ко всем или, при указании SELECTOR, к выбранным элементам списка.

Примечание

Подкоманда TRANSFORM не изменяет количество элементов в списке. Если указан SELECTOR, будут изменены только некоторые элементы, остальные останутся такими же, как до преобразования.

ACTION определяет действие, которое должно быть применено к элементам списка. Действия имеют точно такой же смысл, как и в команде list(TRANSFORM). ACTION должно быть одним из следующих:

APPEND, PREPEND

Добавить, вставить указанное значение в каждый элемент списка.

$<LIST:TRANSFORM,list,(APPEND|PREPEND),value[,SELECTOR]>

TOLOWER, TOUPPER

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

$<LIST:TRANSFORM,list,(TOLOWER|TOUPPER)[,SELECTOR]>

STRIP

Удалить начальные и конечные пробелы из каждого элемента списка.

$<LIST:TRANSFORM,list,STRIP[,SELECTOR]>

REPLACE:

Сопоставить регулярное выражение как можно больше раз и заменить выражение замены на соответствие для каждого элемента списка.

$<LIST:TRANSFORM,list,REPLACE,regular_expression,replace_expression[,SELECTOR]>

SELECTOR определяет, какие элементы списка будут преобразованы. Одновременно может быть указан только один тип селектора. При указании SELECTOR должно быть одним из следующих:

AT

Указать список индексов.

$<LIST:TRANSFORM,list,ACTION,AT,index[,index...]>

FOR

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

$<LIST:TRANSFORM,list,ACTION,FOR,start,stop[,step]>

REGEX

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

$<LIST:TRANSFORM,list,ACTION,REGEX,regular_expression>

$<JOIN:list,glue>: Объединяет list с содержимым строки glue вставленной между каждым элементом. По концепции эта операция аналогична $<LIST:JOIN,list,glue>, но они ведут себя по-разному при работе с пустыми элементами. $<LIST:JOIN,list,glue> сохраняет все пустые элементы, тогда как $<JOIN,list,glue> удаляет все пустые элементы из списка.

$<REMOVE_DUPLICATES:list>: Новое в версии 3.15.

Удаляет дублированные элементы в данном list. Относительный порядок элементов сохраняется, и если обнаруживаются дубликаты, сохраняется только первый экземпляр. Результат совпадает с $<LIST:REMOVE_DUPLICATES,list>.

$<FILTER:list,INCLUDE|EXCLUDE,regex>: Новое в версии 3.15.

Включает или удаляет элементы из list которые соответствуют регулярному выражению regex. Результат совпадает с $<LIST:FILTER,list,INCLUDE|EXCLUDE,regex>.

Порядок списка

$<LIST:REVERSE,list>: Новое в версии 3.27.

Список list с элементами в обратном порядке.

$<LIST:SORT,list[,(COMPARE:option|CASE:option|ORDER:option)]...>

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

Список list отсортированный в соответствии с указанными опциями.

Используйте одну из COMPARE опций для выбора метода сравнения для сортировки:

STRING: Сортирует список строк в алфавитном порядке. Это поведение по умолчанию, если не задана опция COMPARE.
FILE_BASENAME: Сортирует список путей к файлам по их именам файлов.
NATURAL: Сортирует список строк с использованием естественного порядка (см. страницу руководства для strverscmp(3)), так что смежные цифры сравниваются как целые числа. Например, следующий список 10.0 1.1 2.1 8.0 2.0 3.1 будет отсортирован как 1.1 2.0 2.1 3.1 8.0 10.0 если выбран сравнение NATURAL, тогда как он будет отсортирован как 1.1 10.0 2.0 2.1 3.1 8.0 с сравнением STRING.

Используйте одну из CASE опций для выбора чувствительной или нечувствительной к регистру сортировки:

SENSITIVE: Элементы списка сортируются в чувствительном к регистру режиме. Это поведение по умолчанию, если не задана опция CASE.
INSENSITIVE: Элементы списка сортируются в режиме нечувствительном к регистру. Порядок элементов, которые различаются только прописными/строчными буквами, не определён.

Для управления порядком сортировки можно указать одну из ORDER опций:

ASCENDING: Сортирует список в порядке возрастания. Это поведение по умолчанию, если не задана опция ORDER.
DESCENDING: Сортирует список в порядке убывания.

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

$<LIST:SORT,list,CASE:SENSITIVE,COMPARE:STRING,ORDER:DESCENDING>

Выражения путей

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

Для всех выражений генератора в этом разделе пути должны быть в формате cmake. Выражение генератора $<PATH:CMAKE_PATH> может быть использовано для преобразования пути в стиле операционной системы в путь в стиле cmake.

Сравнение путей

$<PATH_EQUAL:path1,path2>

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

Сравнивает лексические представления двух путей. Никакая нормализация на пути не выполняется. Возвращает 1 если пути равны, 0 в противном случае.

См. cmake_path(COMPARE) для получения дополнительной информации.

Запросы к путям

Эти выражения предоставляют возможности генерации времени, эквивалентные параметрам запроса Query команды cmake_path(). Все пути должны быть в формате CMake.

$<PATH:HAS_*,path>

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

Следующие операции возвращают 1 если указанный компонент пути присутствует, 0 в противном случае. Смотрите Структура и терминология путей для понимания каждого компонента пути.

$<PATH:HAS_ROOT_NAME,path>
$<PATH:HAS_ROOT_DIRECTORY,path>
$<PATH:HAS_ROOT_PATH,path>
$<PATH:HAS_FILENAME,path>
$<PATH:HAS_EXTENSION,path>
$<PATH:HAS_STEM,path>
$<PATH:HAS_RELATIVE_PART,path>
$<PATH:HAS_PARENT_PATH,path>

Обратите внимание на следующие частные случаи:

Для HAS_ROOT_PATH, истинный результат будет возвращён только если хотя бы один из root-name или root-directory не пуст.
Для HAS_PARENT_PATH, корневой каталог также считается имеющим родительский каталог, который будет самим собой. Результат истинный, за исключением случая, если путь состоит только из имени файла.

$<PATH:IS_ABSOLUTE,path>: Новое в версии 3.24.

Возвращает 1 если путь абсолютный, 0 в противном случае.

$<PATH:IS_RELATIVE,path>: Новое в версии 3.24.

Это вернёт противоположное значение IS_ABSOLUTE.

$<PATH:IS_PREFIX[,NORMALIZE],path,input>

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

Возвращает 1, если path является префиксом input, 0 в противном случае.

При указании опции NORMALIZE, path и input нормализуются перед проверкой.

Разложение пути

Эти выражения предоставляют возможности генерации, эквивалентные параметрам Разложения команды cmake_path(). Все пути ожидаются в формате CMake.

$<PATH:GET_*,...>

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

Следующие операции извлекают разные компоненты или группы компонентов из пути. Обратитесь к Структуре пути и терминологии для определения значения каждого компонента пути.

Изменено в версии 3.27: Все операции теперь принимают список путей в качестве аргумента. При указании списка путей операция будет применена к каждому пути.

$<PATH:GET_ROOT_NAME,path...>
$<PATH:GET_ROOT_DIRECTORY,path...>
$<PATH:GET_ROOT_PATH,path...>
$<PATH:GET_FILENAME,path...>
$<PATH:GET_EXTENSION[,LAST_ONLY],path...>
$<PATH:GET_STEM[,LAST_ONLY],path...>
$<PATH:GET_RELATIVE_PART,path...>
$<PATH:GET_PARENT_PATH,path...>

Если запрашиваемый компонент отсутствует в пути, возвращается пустая строка.

Преобразования путей

Эти выражения предоставляют возможности генерации, эквивалентные параметрам Модификации и Генерации команды cmake_path(). Все пути ожидаются в формате CMake.

$<PATH:CMAKE_PATH[,NORMALIZE],path...>

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

Возвращает path. Если path является системным путём, он преобразуется в путь CMake со слешами (/). В Windows учитывается маркер длинного имени файла.

При указании опции NORMALIZE, путь нормализуется после преобразования.

$<PATH:APPEND,path...,input,...>

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

Возвращает все аргументы input , добавленные к path с использованием / в качестве directory-separator. В зависимости от input, значение path может быть проигнорировано.

См. cmake_path(APPEND) для получения дополнительных сведений.

$<PATH:REMOVE_FILENAME,path...>

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

Возвращает path с удалённым компонентом имени файла (как возвращает $<PATH:GET_FILENAME>). После удаления любые завершающие directory-separator остаются нетронутыми, если они присутствуют.

См. cmake_path(REMOVE_FILENAME) для получения дополнительных сведений.

$<PATH:REPLACE_FILENAME,path...,input>

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

Возвращает path с компонентом имени файла, заменённым на input. Если path не имеет компонента имени файла (т.е. $<PATH:HAS_FILENAME> возвращает 0 ), path остаётся неизменным.

См. cmake_path(REPLACE_FILENAME) для получения дополнительных сведений.

$<PATH:REMOVE_EXTENSION[,LAST_ONLY],path...>

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

Возвращает path с удалённым расширением, если оно есть.

См. cmake_path(REMOVE_EXTENSION) для получения дополнительных сведений.

$<PATH:REPLACE_EXTENSION[,LAST_ONLY],path...,input>

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

Возвращает path с заменённым расширением на input, если оно есть.

См. cmake_path(REPLACE_EXTENSION) для получения дополнительных сведений.

$<PATH:NORMAL_PATH,path...>: Новое в версии 3.24.

Возвращает path нормализованный в соответствии с процедурой, описанной в Нормализации.

$<PATH:RELATIVE_PATH,path...,base_directory>

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

Возвращает path, изменённый для относительности к аргументу base_directory.

См. cmake_path(RELATIVE_PATH) для получения дополнительных сведений.

$<PATH:ABSOLUTE_PATH[,NORMALIZE],path...,base_directory>

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

Возвращает path в абсолютном формате. Если path является относительным путём ($<PATH:IS_RELATIVE> возвращает 1), он вычисляется относительно каталога, указанного в аргументе base_directory.

При указании опции NORMALIZE, путь нормализуется после вычисления пути.

См. cmake_path(ABSOLUTE_PATH) для получения дополнительных сведений.

Пути оболочки

$<SHELL_PATH:...>: Новое в версии 3.4.

Содержимое ... преобразуется в стиль пути оболочки. Например, в оболочках Windows слеши преобразуются в обратные слеши, а буквы диска преобразуются в пути POSIX в оболочках MSYS. ... должен быть абсолютным путём.

Новое в версии 3.14: ... может быть списком путей, разделённых точкой с запятой, в этом случае каждый путь преобразуется индивидуально, и создаётся результат со значащим разделителем путей (: в POSIX и ; в Windows). Обязательно заключайте аргумент, содержащий этот genex, в двойные кавычки в коде CMake, чтобы ; не разделял аргументы.

Выражения конфигурации

$<CONFIG>: Имя конфигурации. Используйте его вместо устаревшего выражения генератора CONFIGURATION.

$<CONFIG:cfgs>: 1 если конфигурация совпадает с одним из элементов в списке через запятую cfgs, иначе 0. Это сравнение выполняется без учёта регистра. Сопоставление в MAP_IMPORTED_CONFIG_<CONFIG> также учитывается при оценке выражения на свойстве целевого IMPORTED объекта.

Изменено в версии 3.19: Для cfgs могут быть указаны несколько конфигураций. CMake 3.18 и более ранние версии принимали только одну конфигурацию.

END_OF_DOCUMENT_MARKER

$<OUTPUT_CONFIG:...>: Новое в версии 3.20.

Допустимо только в add_custom_command() и add_custom_target() в качестве внешнего выражения генератора в аргументе. При использовании генератора Ninja Multi-Config, выражения генератора в ... вычисляются с использованием «output config» пользовательской команды. При использовании других генераторов, содержимое ... вычисляется в обычном режиме.

$<COMMAND_CONFIG:...>: Новое в версии 3.20.

Допустимо только в add_custom_command() и add_custom_target() в качестве внешнего выражения генератора в аргументе. При использовании генератора Ninja Multi-Config, выражения генератора в ... вычисляются с использованием «command config» пользовательской команды. При использовании других генераторов, содержимое ... вычисляется в обычном режиме.

Средства разработки и языковые выражения

Платформа

$<PLATFORM_ID>: Идентификатор платформы CMake текущей системы. См. также переменную CMAKE_SYSTEM_NAME.

$<PLATFORM_ID:platform_ids>: 1 если идентификатор платформы CMake соответствует одному из значений в списке, разделенном запятыми, platform_ids, иначе 0. См. также переменную CMAKE_SYSTEM_NAME.

Версия компилятора

См. также переменную CMAKE_<LANG>_COMPILER_VERSION, которая тесно связана с выражениями в этом подразделе.

$<C_COMPILER_VERSION>: Версия используемого компилятора C.

$<C_COMPILER_VERSION:version>: 1 если версия компилятора C соответствует version, иначе 0.

$<CXX_COMPILER_VERSION>: Версия используемого компилятора C++.

$<CXX_COMPILER_VERSION:version>: 1 если версия компилятора C++ соответствует version, иначе 0.

$<CUDA_COMPILER_VERSION>: Новое в версии 3.15.

Версия используемого компилятора CUDA.

$<CUDA_COMPILER_VERSION:version>: Новое в версии 3.15.

1 если версия компилятора C++ соответствует version, иначе 0.

$<OBJC_COMPILER_VERSION>: Новое в версии 3.16.

Версия используемого компилятора OBJC.

$<OBJC_COMPILER_VERSION:version>: Новое в версии 3.16.

1 если версия компилятора OBJC соответствует version, иначе 0.

$<OBJCXX_COMPILER_VERSION>: Новое в версии 3.16.

Версия используемого компилятора OBJCXX.

$<OBJCXX_COMPILER_VERSION:version>: Новое в версии 3.16.

1 если версия компилятора OBJCXX соответствует version, иначе 0.

$<Fortran_COMPILER_VERSION>: Версия используемого компилятора Fortran.

$<Fortran_COMPILER_VERSION:version>: 1 если версия компилятора Fortran соответствует version, иначе 0.

$<HIP_COMPILER_VERSION>: Новое в версии 3.21.

Версия используемого компилятора HIP.

$<HIP_COMPILER_VERSION:version>: Новое в версии 3.21.

1 если версия компилятора HIP соответствует version, иначе 0.

$<ISPC_COMPILER_VERSION>: Новое в версии 3.19.

Версия используемого компилятора ISPC.

$<ISPC_COMPILER_VERSION:version>: Новое в версии 3.19.

1 если версия компилятора ISPC соответствует version, иначе 0.

Язык и идентификатор компилятора

См. также переменную CMAKE_<LANG>_COMPILER_ID, которая тесно связана с большинством выражений в этом подразделе.

$<C_COMPILER_ID>: Идентификатор компилятора C, используемый CMake.

$<C_COMPILER_ID:compiler_ids>: где compiler_ids — список, разделенный запятыми. 1 если идентификатор компилятора C, используемый CMake, соответствует одному из значений в compiler_ids, иначе 0.

Изменено в версии 3.15: Можно указать несколько compiler_ids. В CMake 3.14 и ранее допускался только один идентификатор компилятора.

$<CXX_COMPILER_ID>: Идентификатор компилятора C++, используемый CMake.

$<CXX_COMPILER_ID:compiler_ids>: где compiler_ids — список, разделенный запятыми. 1 если идентификатор компилятора C++, используемый CMake, соответствует одному из значений в compiler_ids, иначе 0.

Изменено в версии 3.15: Можно указать несколько compiler_ids. В CMake 3.14 и ранее допускался только один идентификатор компилятора.

$<CUDA_COMPILER_ID>: Новое в версии 3.15.

Идентификатор компилятора CUDA, используемый CMake.

$<CUDA_COMPILER_ID:compiler_ids>: Новое в версии 3.15.

где compiler_ids — список, разделенный запятыми. 1 если идентификатор компилятора CUDA, используемый CMake, соответствует одному из значений в compiler_ids, иначе 0.

$<OBJC_COMPILER_ID>: Новое в версии 3.16.

Идентификатор компилятора OBJC, используемый CMake.

$<OBJC_COMPILER_ID:compiler_ids>: Новое в версии 3.16.

где compiler_ids — список, разделенный запятыми. 1 если идентификатор компилятора Objective-C, используемый CMake, соответствует одному из значений в compiler_ids, иначе 0.

$<OBJCXX_COMPILER_ID>: Новое в версии 3.16.

Идентификатор компилятора OBJCXX, используемый CMake.

END_OF_DOCUMENT_MARKER

$<OBJCXX_COMPILER_ID:compiler_ids>: Новые в версии 3.16.

где compiler_ids — список, разделенный запятыми. 1 если идентификатор компилятора Objective-C++ CMake совпадает с любым из элементов в compiler_ids, в противном случае 0.

$<Fortran_COMPILER_ID>: Идентификатор компилятора Fortran, используемый CMake.

$<Fortran_COMPILER_ID:compiler_ids>: где compiler_ids — список, разделенный запятыми. 1 если идентификатор компилятора Fortran CMake совпадает с любым из элементов в compiler_ids, в противном случае 0.

Изменено в версии 3.15: Можно указать несколько compiler_ids. CMake 3.14 и более ранние версии принимали только один идентификатор компилятора.

$<HIP_COMPILER_ID>: Новые в версии 3.21.

Идентификатор компилятора HIP, используемый CMake.

$<HIP_COMPILER_ID:compiler_ids>: Новые в версии 3.21.

где compiler_ids — список, разделенный запятыми. 1 если идентификатор компилятора HIP CMake совпадает с любым из элементов в compiler_ids, в противном случае 0.

$<ISPC_COMPILER_ID>: Новые в версии 3.19.

Идентификатор компилятора ISPC, используемый CMake.

$<ISPC_COMPILER_ID:compiler_ids>: Новые в версии 3.19.

где compiler_ids — список, разделенный запятыми. 1 если идентификатор компилятора ISPC CMake совпадает с любым из элементов в compiler_ids, в противном случае 0.

$<COMPILE_LANGUAGE>: Новые в версии 3.3.

Язык компиляции исходных файлов при оценке параметров компиляции. См. соответствующее булево выражение $<COMPILE_LANGUAGE:language> для заметок о переносимости этого генераторного выражения.

$<COMPILE_LANGUAGE:languages>

Новые в версии 3.3.

Изменено в версии 3.15: Для languages можно указать несколько языков. CMake 3.14 и более ранние версии принимали только один язык.

1 если язык, используемый для компиляции блока, совпадает с любым из элементов, разделенных запятыми, в списке languages, в противном случае 0. Это выражение можно использовать для задания параметров компиляции, определений компиляции и каталогов включаемых файлов для исходных файлов конкретного языка в целевом объекте. Например:

add_executable(myapp main.cpp foo.c bar.cpp zot.cu)
target_compile_options(myapp
  PRIVATE $<$<COMPILE_LANGUAGE:CXX>:-fno-exceptions>
)
target_compile_definitions(myapp
  PRIVATE $<$<COMPILE_LANGUAGE:CXX>:COMPILING_CXX>
          $<$<COMPILE_LANGUAGE:CUDA>:COMPILING_CUDA>
)
target_include_directories(myapp
  PRIVATE $<$<COMPILE_LANGUAGE:CXX,CUDA>:/opt/foo/headers>
)

Это задает использование параметра компиляции -fno-exceptions, определение компиляции COMPILING_CXX и каталог включаемых файлов cxx_headers только для C++. Также задано определение компиляции COMPILING_CUDA для CUDA.

Обратите внимание, что в генераторах Visual Studio и Xcode нет возможности представить определения компиляции или каталоги включаемых файлов для всего целевого объекта отдельно для языков C и CXX. Также в генераторах Visual Studio нет возможности представить флаги компиляции отдельно для языков C и CXX. В этих генераторах выражения для источников C и C++ будут вычисляться с использованием CXX если есть какие-либо источники C++, и в противном случае с использованием C. Обходным путём является создание отдельных библиотек для каждого языка исходного файла:

add_library(myapp_c foo.c)
add_library(myapp_cxx bar.cpp)
target_compile_options(myapp_cxx PUBLIC -fno-exceptions)
add_executable(myapp main.cpp)
target_link_libraries(myapp myapp_c myapp_cxx)

$<COMPILE_LANG_AND_ID:language,compiler_ids>

Новые в версии 3.15.

1 если язык, используемый для компиляции блока, совпадает с language и идентификатор компилятора language CMake совпадает с любым из элементов, разделенных запятыми, в compiler_ids, в противном случае 0. Это выражение является сокращенной формой комбинации $<COMPILE_LANGUAGE:language> и $<LANG_COMPILER_ID:compiler_ids>. Это выражение можно использовать для задания параметров компиляции, определений компиляции и каталогов включаемых файлов для исходных файлов конкретной комбинации языка и компилятора в целевом объекте. Например:

add_executable(myapp main.cpp foo.c bar.cpp zot.cu)
target_compile_definitions(myapp
  PRIVATE $<$<COMPILE_LANG_AND_ID:CXX,AppleClang,Clang>:COMPILING_CXX_WITH_CLANG>
          $<$<COMPILE_LANG_AND_ID:CXX,Intel>:COMPILING_CXX_WITH_INTEL>
          $<$<COMPILE_LANG_AND_ID:C,Clang>:COMPILING_C_WITH_CLANG>
)

Это задает использование различных определений компиляции, основанных на идентификаторе компилятора и языке компиляции. В этом примере будет определение компиляции COMPILING_CXX_WITH_CLANG когда Clang является компилятором CXX и COMPILING_CXX_WITH_INTEL когда Intel является компилятором CXX. Аналогично, когда компилятор C — Clang, он увидит только определение COMPILING_C_WITH_CLANG.

Без генераторного выражения COMPILE_LANG_AND_ID тот же логика записывается так:

target_compile_definitions(myapp
  PRIVATE $<$<AND:$<COMPILE_LANGUAGE:CXX>,$<CXX_COMPILER_ID:AppleClang,Clang>>:COMPILING_CXX_WITH_CLANG>
          $<$<AND:$<COMPILE_LANGUAGE:CXX>,$<CXX_COMPILER_ID:Intel>>:COMPILING_CXX_WITH_INTEL>
          $<$<AND:$<COMPILE_LANGUAGE:C>,$<C_COMPILER_ID:Clang>>:COMPILING_C_WITH_CLANG>
)

Особенности компиляции

$<COMPILE_FEATURES:features>: Новые в версии 3.1.

где features — список, разделенный запятыми. Принимает значение 1 если все features доступны для целевого объекта 'head', и 0 в противном случае. Если это выражение используется при оценке реализации компоновки целевого объекта, и любая зависимость по транзитивному пути увеличивает требуемый C_STANDARD или CXX_STANDARD для целевого объекта 'head', то выдается ошибка. См. руководство cmake-compile-features(7) для получения информации об особенностях компиляции и списке поддерживаемых компиляторов.

Контекст компиляции

$<COMPILE_ONLY:...>

Новые в версии 3.27.

Содержимое ..., при сборе Требований для использования целевых объектов, иначе — пустая строка. Это предназначено для использования в INTERFACE_LINK_LIBRARIES и LINK_LIBRARIES свойствах целевого объекта, обычно заполняемых с помощью команды target_link_libraries(). Обеспечивает требования компиляции без требований к компоновке.

Сценарии использования включают в себя использование только заголовков, где известно, что все использования не имеют требований к компоновке (например, все-inline или C++ шаблоны библиотек).

Обратите внимание, что для правильной оценки этого выражения требуется, чтобы политика CMP0099 была установлена в NEW.

Язык компоновки и идентификатор

$<LINK_LANGUAGE>: Новые в версии 3.18.

Язык компоновки целевого объекта при оценке параметров компоновки. См. соответствующее булево выражение $<LINK_LANGUAGE:languages> для заметок о переносимости этого генераторного выражения.

Примечание

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

$<LINK_LANGUAGE:languages>

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

1 если язык, используемый для этапа компоновки, совпадает с любым из значений, перечисленных через запятую в languages, в противном случае 0. Это выражение можно использовать для указания библиотек компоновки, опций компоновки, каталогов компоновки и зависимостей компоновки для конкретного языка в целевом объекте. Например:

add_library(api_C ...)
add_library(api_CXX ...)
add_library(api INTERFACE)
target_link_options(api   INTERFACE $<$<LINK_LANGUAGE:C>:-opt_c>
                                    $<$<LINK_LANGUAGE:CXX>:-opt_cxx>)
target_link_libraries(api INTERFACE $<$<LINK_LANGUAGE:C>:api_C>
                                    $<$<LINK_LANGUAGE:CXX>:api_CXX>)

add_executable(myapp1 main.c)
target_link_options(myapp1 PRIVATE api)

add_executable(myapp2 main.cpp)
target_link_options(myapp2 PRIVATE api)

Это указывает на использование целевого объекта api для компоновки целевых объектов myapp1 и myapp2. На практике, myapp1 будет компоноваться с целевым объектом api_C и опцией -opt_c, потому что будет использоваться C в качестве языка компоновки. А myapp2 будет компоноваться с api_CXX и опцией -opt_cxx, потому что CXX будет языком компоновки.

Примечание

Для определения языка компоновки целевого объекта необходимо собрать, транзитивно, все целевые объекты, которые будут с ним компоноваться. Таким образом, для свойств библиотек компоновки будет выполнено двойное вычисление. Во время первого вычисления выражения $<LINK_LANGUAGE:..> всегда возвращают 0. Язык компоновки, вычисленный после этого первого прохода, будет использован для второго прохода. Чтобы избежать противоречий, необходимо, чтобы второй проход не изменял язык компоновки. Кроме того, чтобы избежать непредвиденных побочных эффектов, необходимо указывать полные сущности в качестве части выражения $<LINK_LANGUAGE:..>. Например:

add_library(lib STATIC file.cxx)
add_library(libother STATIC file.c)

# bad usage
add_executable(myapp1 main.c)
target_link_libraries(myapp1 PRIVATE lib$<$<LINK_LANGUAGE:C>:other>)

# correct usage
add_executable(myapp2 main.c)
target_link_libraries(myapp2 PRIVATE $<$<LINK_LANGUAGE:C>:libother>)

В этом примере, для myapp1, первый проход неожиданно определит, что язык компоновки — это CXX, потому что вычисление выражения генератора будет пустой строкой, поэтому myapp1 будет зависеть от целевого объекта lib, который является C++. Напротив, для myapp2, первое вычисление даст C в качестве языка компоновки, поэтому второй проход правильно добавит целевой объект libother в качестве зависимости компоновки.

$<LINK_LANG_AND_ID:language,compiler_ids>

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

1 если язык, используемый для этапа компоновки, совпадает с language и идентификатор компилятора CMake языка компоновщика совпадает с любым из значений, перечисленных через запятую в compiler_ids, в противном случае 0. Это выражение является сокращенной формой сочетания $<LINK_LANGUAGE:language> и $<LANG_COMPILER_ID:compiler_ids>. Это выражение можно использовать для указания библиотек компоновки, опций компоновки, каталогов компоновки и зависимостей компоновки для конкретной комбинации языка и компоновщика в целевом объекте. Например:

add_library(libC_Clang ...)
add_library(libCXX_Clang ...)
add_library(libC_Intel ...)
add_library(libCXX_Intel ...)

add_executable(myapp main.c)
if (CXX_CONFIG)
  target_sources(myapp PRIVATE file.cxx)
endif()
target_link_libraries(myapp
  PRIVATE $<$<LINK_LANG_AND_ID:CXX,Clang,AppleClang>:libCXX_Clang>
          $<$<LINK_LANG_AND_ID:C,Clang,AppleClang>:libC_Clang>
          $<$<LINK_LANG_AND_ID:CXX,Intel>:libCXX_Intel>
          $<$<LINK_LANG_AND_ID:C,Intel>:libC_Intel>)

Это задаёт использование различных библиотек компоновки, основываясь на идентификаторе компилятора и языке компоновки. В этом примере, целевой объект libCXX_Clang будет зависимостью, когда Clang или AppleClang является компоновщиком CXX, и libCXX_Intel, когда Intel является компоновщиком CXX. Аналогично, когда компоновщик C является Clang или AppleClang, целевой объект libC_Clang будет добавлен в качестве зависимости компоновки, а libC_Intel, когда Intel является компоновщиком C.

См. примечание, касающееся $<LINK_LANGUAGE:language> для ограничений по использованию этого выражения генератора.

Особенности компоновки

$<LINK_LIBRARY:feature,library-list>

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

Укажите набор библиотек для связывания с целевым объектом, а также feature, который содержит информацию о том, как они должны быть связаны. Например:

add_library(lib1 STATIC ...)
add_library(lib2 ...)
target_link_libraries(lib2 PRIVATE "$<LINK_LIBRARY:WHOLE_ARCHIVE,lib1>")

Это указывает, что lib2 должен быть связан с lib1 и использовать функцию WHOLE_ARCHIVE при этом.

Имена функций чувствительны к регистру и могут содержать только буквы, цифры и символы подчеркивания. Имена функций, определённые в верхнем регистре, зарезервированы для встроенных функций CMake. Предопределённые встроенные библиотечные функции:

DEFAULT

Эта функция соответствует стандартному связыванию, по существу эквивалентному отсутствию какой-либо функции. Обычно она используется только с LINK_LIBRARY_OVERRIDE и LINK_LIBRARY_OVERRIDE_<LIBRARY> свойствами целевого объекта.

WHOLE_ARCHIVE

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

Linux.
Все варианты BSD.
SunOS.
Все варианты Apple. Библиотека должна быть указана как имя целевого объекта CMake, имя файла библиотеки (например, libfoo.a), или путь к файлу библиотеки (например, /path/to/libfoo.a). Из-за ограничения Apple Linker, она не может быть указана как простое имя библиотеки, например, foo, где foo не является целевым объектом CMake.
Windows. При использовании MSVC или похожей инструментальной цепочки, версия MSVC должна быть больше 1900.
Cygwin.
MSYS.

FRAMEWORK

Этот параметр сообщает Linker искать указанную фреймворк, используя параметр linkera -framework. Он может быть использован только на платформах Apple, и только с линкером, понимающим используемый параметр (т.е. линкер, предоставленный Xcode, или совместимый с ним).

Фреймворк может быть указан как целевой объект фреймворка CMake, как простое имя фреймворка, или как путь к файлу. Если указан целевой объект, для этого целевого объекта должно быть установлено свойство целевого объекта FRAMEWORK в значение true. Для пути к файлу, если он содержит часть директории, эта директория будет добавлена как путь поиска фреймворка.

add_library(lib SHARED ...)
target_link_libraries(lib PRIVATE "$<LINK_LIBRARY:FRAMEWORK,/path/to/my_framework>")

# The constructed linker command line will contain:
#   -F/path/to -framework my_framework

Пути к файлам должны соответствовать одному из следующих шаблонов (* — это символ подстановки, а необязательные части показаны как [...]):

[/path/to/]FwName[.framework]
[/path/to/]FwName.framework/FwName[suffix]
[/path/to/]FwName.framework/Versions/*/FwName[suffix]

Обратите внимание, что CMake распознаёт и автоматически обрабатывает целевые объекты фреймворка, даже без использования выражения $<LINK_LIBRARY:FRAMEWORK,...>. Выражение генератора всё равно можно использовать с целевым объектом CMake, если проект хочет быть явным в этом, но это не требуется. Команда линкера может иметь некоторые различия при использовании или не использовании выражения генератора, но конечный результат должен быть одинаковым. С другой стороны, если указан путь к файлу, CMake автоматически распознает некоторые пути, но не все случаи. Проект может захотеть использовать $<LINK_LIBRARY:FRAMEWORK,...> для путей к файлам, чтобы ожидаемое поведение было понятным.

Новое в версии 3.25: Свойство целевого объекта FRAMEWORK_MULTI_CONFIG_POSTFIX_<CONFIG>, а также suffix имени библиотеки фреймворка теперь поддерживаются функциями FRAMEWORK.

NEEDED_FRAMEWORK

Это аналогично функции FRAMEWORK, за исключением того, что это вынуждает линкер связываться с фреймворком, даже если из него не используются никакие символы. Она использует параметр -needed_framework и имеет те же ограничения линковщика, что и FRAMEWORK.

REEXPORT_FRAMEWORK

Это аналогично функции FRAMEWORK, за исключением того, что это сообщает линкеру, что фреймворк должен быть доступен клиентам, связывающимся с создаваемой библиотекой. Она использует параметр -reexport_framework и имеет те же ограничения линковщика, что и FRAMEWORK.

WEAK_FRAMEWORK

Это аналогично функции FRAMEWORK, за исключением того, что она вынуждает линкер пометить фреймворк и все ссылки на него как слабые импорты. Она использует параметр -weak_framework и имеет те же ограничения линковщика, что и FRAMEWORK.

NEEDED_LIBRARY

Это аналогично функции NEEDED_FRAMEWORK, за исключением того, что она предназначена для использования с целевыми объектами или библиотеками, не являющимися фреймворками (только для платформ Apple). Она использует параметр -needed_library или -needed-l соответственно, и имеет те же ограничения линковщика, что и NEEDED_FRAMEWORK.

REEXPORT_LIBRARY

Это аналогично функции REEXPORT_FRAMEWORK, за исключением того, что она предназначена для использования с целевыми объектами или библиотеками, не являющимися фреймворками (только для платформ Apple). Она использует параметр -reexport_library или -reexport-l соответственно, и имеет те же ограничения линковщика, что и REEXPORT_FRAMEWORK.

WEAK_LIBRARY

Это аналогично функции WEAK_FRAMEWORK, за исключением того, что она предназначена для использования с целевыми объектами или библиотеками, не являющимися фреймворками (только для платформ Apple). Она использует параметр -weak_library или -weak-l соответственно, и имеет те же ограничения линковщика, что и WEAK_FRAMEWORK.

Встроенные и пользовательские функции библиотеки определяются в терминах следующих переменных:

Значение, используемое для каждой из этих переменных, — это значение, установленное в конце области директории, в которой был создан целевой объект. Использование:

Если языковая переменная CMAKE_<LANG>_LINK_LIBRARY_USING_<FEATURE>_SUPPORTED равна true, то feature должна быть определена соответствующей переменной CMAKE_<LANG>_LINK_LIBRARY_USING_<FEATURE>.
Если какая-либо языковая feature не поддерживается, то переменная CMAKE_LINK_LIBRARY_USING_<FEATURE>_SUPPORTED должна быть true и feature должна быть определена соответствующей переменной CMAKE_LINK_LIBRARY_USING_<FEATURE>.

Следует отметить следующие ограничения:

Выражение library-list может указывать на CMake-цели или библиотеки. Любая CMake-цель типа OBJECT или INTERFACE проигнорирует аспект функции в выражении и будет связана стандартным способом.
Генераторское выражение $<LINK_LIBRARY:...> может использоваться только для указания ссылочных библиотек. На практике это означает, что оно может встречаться в свойствах цели LINK_LIBRARIES, INTERFACE_LINK_LIBRARIES и INTERFACE_LINK_LIBRARIES_DIRECT, а также в командах target_link_libraries() и link_libraries().
Если генераторское выражение $<LINK_LIBRARY:...> появляется в свойстве INTERFACE_LINK_LIBRARIES цели, оно будет включено в импортированную цель, сгенерированную командой install(EXPORT). Ответственность по определению используемой этим выражением функции связи лежит на среде, использующей этот импорт.
Каждая цель или библиотека, участвующая в шаге связи, должна иметь не более одного вида функциональности библиотеки. Отсутствие функции также несовместимо со всеми другими функциями. Например:
```
add_library(lib1 ...)
add_library(lib2 ...)
add_library(lib3 ...)

# lib1 will be associated with feature1
target_link_libraries(lib2 PUBLIC "$<LINK_LIBRARY:feature1,lib1>")

# lib1 is being linked with no feature here. This conflicts with the
# use of feature1 in the line above and would result in an error.
target_link_libraries(lib3 PRIVATE lib1 lib2)
```
Если невозможно использовать одну и ту же функцию на протяжении всего процесса сборки для данной цели или библиотеки, можно использовать свойства целей LINK_LIBRARY_OVERRIDE и LINK_LIBRARY_OVERRIDE_<LIBRARY> для разрешения таких несовместимостей.
Генераторское выражение $<LINK_LIBRARY:...> не гарантирует, что список указанных целей и библиотек будет сохранен вместе. Для управления конструкциями, такими как --start-group и --end-group, поддерживаемыми GNU-линкером ld, используйте генераторское выражение LINK_GROUP.

$<LINK_GROUP:feature,library-list>

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

Указывает группу библиотек для связывания с целевым объектом, вместе с feature, определяющим, как эта группа должна быть связана. Например:

add_library(lib1 STATIC ...)
add_library(lib2 ...)
target_link_libraries(lib2 PRIVATE "$<LINK_GROUP:RESCAN,lib1,external>")

Это указывает, что lib2 должен быть связан с lib1 и external, и что обе эти библиотеки должны быть включены в командную строку компоновщика в соответствии с определением RESCAN функции.

Имена функций чувствительны к регистру и могут содержать только буквы, цифры и символы подчеркивания. Имена функций, определённые заглавными буквами, зарезервированы для собственных встроенных функций CMake. В настоящее время существует только одна предопределённая встроенная функция группы:

RESCAN

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

Обычно статическая библиотека ищется только один раз в порядке, в котором она указана в командной строке. Если символ в этой библиотеке необходим для разрешения неразрешённого символа, к которому обращается объект в библиотеке, которая появляется позже в командной строке, компоновщик не сможет разрешить эту ссылку. Объединяя статические библиотеки с помощью RESCAN функции, они все будут повторно просматриваться до тех пор, пока не будут разрешены все возможные ссылки. Это будет использовать такие параметры компоновщика, как --start-group и --end-group, или на SunOS, -z rescan-start и -z rescan-end.

Использование этой функции имеет значительные затраты производительности. Лучше всего использовать её только в случае неизбежных циклических ссылок между двумя или более статическими библиотеками.

Эта функция доступна при использовании инструментальных цепочек, нацеленных на Linux, BSD и SunOS. Она также может быть использована при нацеливании на платформы Windows, если используется GNU инструментальная цепочка.

Встроенные и пользовательские функции группы определены в терминах следующих переменных:

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

Если языковая переменная CMAKE_<LANG>_LINK_GROUP_USING_<FEATURE>_SUPPORTED имеет значение true, то feature должна быть определена соответствующей переменной CMAKE_<LANG>_LINK_GROUP_USING_<FEATURE>.
Если какая-либо языковая feature не поддерживается, тогда переменная CMAKE_LINK_GROUP_USING_<FEATURE>_SUPPORTED должна иметь значение true, и feature должна быть определена соответствующей переменной CMAKE_LINK_GROUP_USING_<FEATURE>.

Генераторное выражение LINK_GROUP совместимо с генераторным выражением LINK_LIBRARY. Библиотеки, участвующие в группе, могут быть указаны с помощью генераторного выражения LINK_LIBRARY.

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

add_library(lib1 ...)
add_library(lib2 ...)
add_library(lib3 ...)
add_library(lib4 ...)
add_library(lib5 ...)

target_link_libraries(lib3 PUBLIC  "$<LINK_GROUP:feature1,lib1,lib2>")
target_link_libraries(lib4 PRIVATE "$<LINK_GROUP:feature1,lib1,lib3>")
# lib4 will be linked with the groups {lib1,lib2} and {lib1,lib3}.
# Both groups specify the same feature, so this is fine.

target_link_libraries(lib5 PRIVATE "$<LINK_GROUP:feature2,lib1,lib3>")
# An error will be raised here because both lib1 and lib3 are part of two
# groups with different features.

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

add_library(lib1 ...)
add_library(lib2 ...)
add_library(lib3 ...)
add_library(lib4 ...)

target_link_libraries(lib3 PUBLIC lib1)

target_link_libraries(lib4 PRIVATE lib3 "$<LINK_GROUP:feature1,lib1,lib2>")
# lib4 will only be linked with lib3 and the group {lib1,lib2}

Поскольку lib1 является частью группы, определённой для lib4, эта группа затем применяется обратно к использованию lib1 для lib3. Конечный результат будет таким, как будто отношение связывания для lib3 было указано следующим образом:

target_link_libraries(lib3 PUBLIC "$<LINK_GROUP:feature1,lib1,lib2>")

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

add_library(lib1A ...)
add_library(lib1B ...)
add_library(lib2A ...)
add_library(lib2B ...)
add_library(lib3 ...)

# Non-group linking relationships, these are non-circular so far
target_link_libraries(lib1A PUBLIC lib2A)
target_link_libraries(lib2B PUBLIC lib1B)

# The addition of these groups creates circular dependencies
target_link_libraries(lib3 PRIVATE
  "$<LINK_GROUP:feat,lib1A,lib1B>"
  "$<LINK_GROUP:feat,lib2A,lib2B>"
)

Из-за групп, определённых для lib3, отношения связывания для lib1A и lib2B фактически расширяются до эквивалента:

target_link_libraries(lib1A PUBLIC "$<LINK_GROUP:feat,lib2A,lib2B>")
target_link_libraries(lib2B PUBLIC "$<LINK_GROUP:feat,lib1A,lib1B>")

Это создаёт циклическую зависимость между группами: lib1A --> lib2B --> lib1A.

Также следует учитывать следующие ограничения:

library-list может указывать целевые объекты или библиотеки CMake. Любой целевой объект CMake типа OBJECT или INTERFACE проигнорирует аспект функции выражения и вместо этого будет связан стандартным способом.
$<LINK_GROUP:...> генераторное выражение может быть использовано только для указания связуемых библиотек. На практике это означает, что оно может появляться в свойствах целевого объекта LINK_LIBRARIES, INTERFACE_LINK_LIBRARIES и INTERFACE_LINK_LIBRARIES_DIRECT, а также быть указано в командах target_link_libraries() и link_libraries().
Если генераторное выражение $<LINK_GROUP:...> появляется в свойстве INTERFACE_LINK_LIBRARIES целевого объекта, оно будет включено в импортированный целевой объект, сгенерированный командой install(EXPORT). Ответственность за определение функции связи, используемой этим выражением, лежит на среде, потребляющей этот импорт.

Контекст компоновки

$<LINK_ONLY:...>: Новое в версии 3.1.

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

Новое в версии 3.24: LINK_ONLY также может быть использовано в свойстве целевого объекта LINK_LIBRARIES. См. политику CMP0131.

$<DEVICE_LINK:list>: Новое в версии 3.18.

Возвращает список, если это шаг компоновки устройства, в противном случае пустой список. Шаг компоновки устройства контролируется свойствами CUDA_SEPARABLE_COMPILATION и CUDA_RESOLVE_DEVICE_SYMBOLS и политикой CMP0105. Это выражение может быть использовано только для указания параметров компоновки.

$<HOST_LINK:list>: Новое в версии 3.18.

Возвращает список, если это обычный шаг компоновки, в противном случае пустой список. Это выражение в основном полезно, когда участвует и шаг компоновки устройства (см. генераторское выражение $<DEVICE_LINK:list>). Это выражение может быть использовано только для указания параметров компоновки.

Выражения, зависящие от целевого объекта

Эти запросы относятся к целевому объекту tgt. Если не указано иное, это может быть любой исполняемый артефакт, а именно:

Исполняемый целевой объект, созданный с помощью add_executable().
Целевой объект динамической библиотеки (.so, .dll но не их .lib библиотеки импорта), созданный с помощью add_library().
Целевой объект статической библиотеки, созданный с помощью add_library().

В дальнейшем фраза "имя файла tgt" означает имя файла tgt исполняемого объекта. Это следует отличать от фразы "имя целевого объекта", которая просто представляет собой строку tgt.

$<TARGET_EXISTS:tgt>: Новая версия 3.12.

Возвращает значение 1, если tgt существует как целевой объект CMake, иначе 0.

$<TARGET_NAME_IF_EXISTS:tgt>

Новая версия 3.12.

Имя целевого объекта tgt, если целевой объект существует, и пустую строку в противном случае.

Обратите внимание, что tgt не добавляется в качестве зависимости целевого объекта, для которого вычисляется это выражение.

$<TARGET_NAME:...>: Помечает ... как имя целевого объекта. Это необходимо при экспорте целевых объектов в несколько зависимых наборов экспорта. ... должно быть буквенным именем целевого объекта, оно не может содержать выражения генератора.

$<TARGET_PROPERTY:tgt,prop>

Значение свойства prop для целевого объекта tgt.

Изменено в версии 3.26: При оценке в рамках Требований по использованию целевых объектов, обычно в свойстве целевого объекта INTERFACE_*, поиск имени tgt происходит в каталоге целевого объекта, указывающего требование, а не в каталоге целевого объекта, для которого оценивается выражение.

$<TARGET_PROPERTY:prop>: Значение свойства prop для целевого объекта, для которого оценивается выражение. Обратите внимание, что для выражений генератора в Требованиях по использованию целевых объектов это целевой объект, использующий требование, а не целевой объект, указывающий требование.

$<TARGET_OBJECTS:tgt>: Новая версия 3.1.

Список объектов, полученных в результате построения tgt. Обычно это используется для целевых объектов объектных библиотек.

$<TARGET_POLICY:policy>: 1 если policy было NEW при создании целевого объекта «head», иначе 0. Если policy не задано, будет выведено сообщение об ошибке для политики. Это выражение генератора работает только для подмножества политик.

$<TARGET_FILE:tgt>

Полный путь к файлу tgt исполняемого объекта.

Обратите внимание, что tgt не добавляется в качестве зависимости целевого объекта, для которого оценивается это выражение, за исключением случаев использования выражения в add_custom_command() или add_custom_target().

$<TARGET_FILE_BASE_NAME:tgt>

Новая версия 3.15.

Основное имя файла tgt, т.е. $<TARGET_FILE_NAME:tgt> без префикса и суффикса. Например, если имя файла tgt исполняемого объекта равно libbase.so, основное имя — base.

См. также свойства целевых объектов OUTPUT_NAME, ARCHIVE_OUTPUT_NAME, LIBRARY_OUTPUT_NAME и RUNTIME_OUTPUT_NAME и их конфигурационные варианты OUTPUT_NAME_<CONFIG>, ARCHIVE_OUTPUT_NAME_<CONFIG>, LIBRARY_OUTPUT_NAME_<CONFIG> и RUNTIME_OUTPUT_NAME_<CONFIG>.

Также могут учитываться свойства целевых объектов <CONFIG>_POSTFIX и DEBUG_POSTFIX.

Обратите внимание, что tgt не добавляется в качестве зависимости целевого объекта, для которого оценивается это выражение.

$<TARGET_FILE_PREFIX:tgt>

Новая версия 3.15.

Префикс имени файла tgt (например, lib).

См. также свойство целевого объекта PREFIX.

$<TARGET_FILE_SUFFIX:tgt>

Новая версия 3.15.

Суффикс имени файла tgt (расширение, например, .so или .exe).

См. также свойство целевого объекта SUFFIX.

$<TARGET_FILE_NAME:tgt>

Имя файла tgt.

Обратите внимание, что tgt не добавляется в качестве зависимости целевого объекта, для которого оценивается это выражение (см. политику CMP0112).

$<TARGET_FILE_DIR:tgt>

Директория файла tgt исполняемого объекта.

$<TARGET_IMPORT_FILE:tgt>

Новая версия 3.27.

Полный путь к файлу импорта компоновщика. На платформах DLL это был бы файл .lib. Для исполняемых файлов на AIX и для динамических библиотек на macOS это мог бы быть, соответственно, файл импорта .imp или .tbd, в зависимости от значения свойства ENABLE_EXPORTS.

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

END_OF_DOCUMENT_MARKER

$<TARGET_IMPORT_FILE_BASE_NAME:tgt>

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

Базовое имя файла импорта компоновщика для целевого объекта tgt без префикса или суффикса. Например, если имя файла целевого объекта libbase.tbd, то базовое имя равно base.

См. также свойства целевого объекта OUTPUT_NAME и ARCHIVE_OUTPUT_NAME и их конфигурационные варианты OUTPUT_NAME_<CONFIG> и ARCHIVE_OUTPUT_NAME_<CONFIG>.

Также можно учитывать свойства целевого объекта <CONFIG>_POSTFIX и DEBUG_POSTFIX.

Обратите внимание, что tgt не добавляется в качестве зависимости целевого объекта, на котором вычисляется это выражение.

$<TARGET_IMPORT_FILE_PREFIX:tgt>

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

Префикс файла импорта целевого объекта tgt.

См. также свойство целевого объекта IMPORT_PREFIX.

$<TARGET_IMPORT_FILE_SUFFIX:tgt>

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

Суффикс файла импорта целевого объекта tgt.

Суффикс соответствует расширению файла (например, .lib или .tbd).

См. также свойство целевого объекта IMPORT_SUFFIX.

$<TARGET_IMPORT_FILE_NAME:tgt>

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

Имя файла импорта целевого объекта tgt.

$<TARGET_IMPORT_FILE_DIR:tgt>

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

Директория файла импорта целевого объекта tgt.

$<TARGET_LINKER_FILE:tgt>

Файл, используемый при компоновке целевого объекта tgt. Обычно это библиотека, которую tgt представляет (.a, .lib, .so), но для динамической библиотеки на платформах DLL это будет файл импорта DLL.

Новое в версии 3.27: На macOS это может быть файл импорта динамической библиотеки, в зависимости от значения свойства ENABLE_EXPORTS.

Это выражение генератора эквивалентно выражениям генератора $<TARGET_LINKER_LIBRARY_FILE> или $<TARGET_LINKER_IMPORT_FILE>, в зависимости от характеристик целевого объекта и платформы.

$<TARGET_LINKER_FILE_BASE_NAME:tgt>

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

Базовое имя файла, используемого для компоновки целевого объекта tgt, т.е. $<TARGET_LINKER_FILE_NAME:tgt> без префикса и суффикса. Например, если имя файла целевого объекта libbase.a, то базовое имя равно base.

См. также свойства целевого объекта OUTPUT_NAME, ARCHIVE_OUTPUT_NAME и LIBRARY_OUTPUT_NAME и их конфигурационные варианты OUTPUT_NAME_<CONFIG>, ARCHIVE_OUTPUT_NAME_<CONFIG> и LIBRARY_OUTPUT_NAME_<CONFIG>.

Также можно учитывать свойства целевого объекта <CONFIG>_POSTFIX и DEBUG_POSTFIX.

$<TARGET_LINKER_FILE_PREFIX:tgt>

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

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

См. также свойства целевого объекта PREFIX и IMPORT_PREFIX.

$<TARGET_LINKER_FILE_SUFFIX:tgt>

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

Суффикс файла, используемого для компоновки, где tgt - имя целевого объекта.

Суффикс соответствует расширению файла (например, ".so" или ".lib").

См. также свойства целевого объекта SUFFIX и IMPORT_SUFFIX.

$<TARGET_LINKER_FILE_NAME:tgt>

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

Обратите внимание, что tgt не добавляется в качестве зависимости целевого объекта, на котором вычисляется это выражение (см. политику CMP0112).

$<TARGET_LINKER_FILE_DIR:tgt>

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

$<TARGET_LINKER_LIBRARY_FILE:tgt>: Новое в версии 3.27.

Файл, используемый при компоновке целевого объекта tgt непосредственно с использованием библиотеки, а не файла импорта. Обычно это библиотека, которую tgt представляет (.a, .so, .dylib). Таким образом, на платформах DLL это будет пустая строка.

END_OF_DOCUMENT_MARKER

$<TARGET_LINKER_LIBRARY_FILE_BASE_NAME:tgt>

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

Базовое имя файла библиотеки, используемого для линковки целевого объекта tgt, т.е. $<TARGET_LINKER_LIBRARY_FILE_NAME:tgt> без префикса и суффикса. Например, если имя целевого файла libbase.a, то базовое имя равно base.

См. также свойства целевого объекта OUTPUT_NAME, ARCHIVE_OUTPUT_NAME и LIBRARY_OUTPUT_NAME и их конфигурационно-зависимые варианты OUTPUT_NAME_<CONFIG>, ARCHIVE_OUTPUT_NAME_<CONFIG> и LIBRARY_OUTPUT_NAME_<CONFIG>.

Также можно рассмотреть свойства целевого объекта <CONFIG>_POSTFIX и DEBUG_POSTFIX.

Обратите внимание, что tgt не добавляется как зависимость целевого объекта, для которого вычисляется это выражение.

$<TARGET_LINKER_LIBRARY_FILE_PREFIX:tgt>

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

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

См. также свойство целевого объекта PREFIX.

$<TARGET_LINKER_LIBRARY_FILE_SUFFIX:tgt>

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

Суффикс файла библиотеки, используемого для линковки целевого объекта tgt.

Суффикс соответствует расширению файла (например, ".a" или ".dylib").

См. также свойство целевого объекта SUFFIX.

$<TARGET_LINKER_LIBRARY_FILE_NAME:tgt>

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

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

$<TARGET_LINKER_LIBRARY_FILE_DIR:tgt>

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

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

$<TARGET_LINKER_IMPORT_FILE:tgt>: Новое в версии 3.27.

Файл, используемый при линковке с целевым объектом tgt с использованием файла импорта. Это обычно файл импорта, который представляет tgt (.lib, .tbd). Таким образом, если в шаге линковки файл импорта не участвует, возвращается пустая строка.

$<TARGET_LINKER_IMPORT_FILE_BASE_NAME:tgt>

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

Базовое имя файла импорта, используемого для линковки целевого объекта tgt, т.е. $<TARGET_LINKER_IMPORT_FILE_NAME:tgt> без префикса и суффикса. Например, если имя целевого файла libbase.tbd, то базовое имя равно base.

См. также свойства целевого объекта OUTPUT_NAME и ARCHIVE_OUTPUT_NAME, и их конфигурационно-зависимые варианты OUTPUT_NAME_<CONFIG> и ARCHIVE_OUTPUT_NAME_<CONFIG>.

Также можно рассмотреть свойства целевого объекта <CONFIG>_POSTFIX и DEBUG_POSTFIX.

$<TARGET_LINKER_IMPORT_FILE_PREFIX:tgt>

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

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

См. также свойство целевого объекта IMPORT_PREFIX.

$<TARGET_LINKER_IMPORT_FILE_SUFFIX:tgt>

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

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

Суффикс соответствует расширению файла (например, ".lib" или ".tbd").

См. также свойство целевого объекта IMPORT_SUFFIX.

$<TARGET_LINKER_IMPORT_FILE_NAME:tgt>

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

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

$<TARGET_LINKER_IMPORT_FILE_DIR:tgt>

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

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

$<TARGET_SONAME_FILE:tgt>: Файл с soname (.so.3) где tgt — имя целевого объекта.

$<TARGET_SONAME_FILE_NAME:tgt>

Имя файла с soname (.so.3).

Обратите внимание, что tgt не добавляется как зависимость целевого объекта, для которого вычисляется это выражение (см. политику CMP0112).

$<TARGET_SONAME_FILE_DIR:tgt>

Директория файла с soname (.so.3).

$<TARGET_SONAME_IMPORT_FILE:tgt>: Новое в версии 3.27.

Файл импорта с soname (.3.tbd) где tgt — имя целевого объекта.

$<TARGET_SONAME_IMPORT_FILE_NAME:tgt>

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

Имя файла импорта с soname (.3.tbd).

$<TARGET_SONAME_IMPORT_FILE_DIR:tgt>

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

Директория файла импорта с soname (.3.tbd).

$<TARGET_PDB_FILE:tgt>

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

Полный путь к файлу базы данных программы, сгенерированному линковщиком (.pdb), где tgt — имя целевого объекта.

См. также свойства целевого объекта PDB_NAME и PDB_OUTPUT_DIRECTORY и их конфигурационно-специфические варианты PDB_NAME_<CONFIG> и PDB_OUTPUT_DIRECTORY_<CONFIG>.

$<TARGET_PDB_FILE_BASE_NAME:tgt>

Новые в версии 3.15.

Базовое имя файла базы данных программы, сгенерированного линковщиком (.pdb), где tgt — имя целевого объекта.

Базовое имя соответствует имени файла PDB целевого объекта (см. $<TARGET_PDB_FILE_NAME:tgt>) без префикса и суффикса. Например, если имя файла целевого объекта — base.pdb, базовое имя — base.

См. также свойство целевого объекта PDB_NAME и его конфигурационно-специфический вариант PDB_NAME_<CONFIG>.

Также можно учесть свойства целевого объекта <CONFIG>_POSTFIX и DEBUG_POSTFIX.

Обратите внимание, что tgt не добавляется в качестве зависимости целевого объекта, на котором вычисляется данное выражение.

$<TARGET_PDB_FILE_NAME:tgt>

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

Имя файла базы данных программы, сгенерированного линковщиком (.pdb).

$<TARGET_PDB_FILE_DIR:tgt>

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

Директория файла базы данных программы, сгенерированного линковщиком (.pdb).

$<TARGET_BUNDLE_DIR:tgt>

Новые в версии 3.9.

Полный путь к каталогу пакета (/path/to/my.app, /path/to/my.framework, или /path/to/my.bundle), где tgt — имя целевого объекта.

$<TARGET_BUNDLE_DIR_NAME:tgt>

Новые в версии 3.24.

Имя каталога пакета (my.app, my.framework, или my.bundle), где tgt — имя целевого объекта.

$<TARGET_BUNDLE_CONTENT_DIR:tgt>

Новые в версии 3.9.

Полный путь к каталогу содержимого пакета, где tgt — имя целевого объекта. Для macOS SDK он указывает на /path/to/my.app/Contents, /path/to/my.framework, или /path/to/my.bundle/Contents. Для всех остальных SDK (например, iOS) он указывает на /path/to/my.app, /path/to/my.framework, или /path/to/my.bundle из-за плоской структуры пакета.

$<TARGET_RUNTIME_DLLS:tgt>

Новые в версии 3.21.

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

Это выражение генератора может быть использовано для копирования всех DLL, от которых зависит целевой объект, в его выходной каталог в пользовательской команде POST_BUILD с помощью команды cmake -E copy -t. Например:

find_package(foo CONFIG REQUIRED) # package generated by install(EXPORT)

add_executable(exe main.c)
target_link_libraries(exe PRIVATE foo::foo foo::bar)
add_custom_command(TARGET exe POST_BUILD
  COMMAND ${CMAKE_COMMAND} -E copy -t $<TARGET_FILE_DIR:exe> $<TARGET_RUNTIME_DLLS:exe>
  COMMAND_EXPAND_LISTS
)

Примечание

Импортированные целевые объекты поддерживаются только в том случае, если они знают расположение файлов .dll. Импортированная SHARED библиотека должна иметь свойство IMPORTED_LOCATION, установленное на свой файл .dll. Подробнее см. раздел add_library импортированные библиотеки. Многие модули поиска (UNKNOWN) создают импортированные целевые объекты и поэтому будут проигнорированы.

На платформах, поддерживающих пути во время выполнения (RPATH), обратитесь к свойству целевого объекта INSTALL_RPATH. На платформах Apple обратитесь к свойству целевого объекта INSTALL_NAME_DIR.

$<TARGET_RUNTIME_DLL_DIRS:tgt>

Новые в версии 3.27.

Список каталогов, содержащих DLL, от которых зависит целевой объект во время выполнения (см. TARGET_RUNTIME_DLLS). Он определяется местоположениями всех целевых объектов SHARED в транзитивных зависимостях целевого объекта. Использование этого выражения генератора для целевых объектов, отличных от исполняемых файлов, SHARED библиотек и MODULE библиотек, является ошибкой. На платформах, не поддерживающих DLL, это выражение всегда оценивается как пустая строка.

Это выражение генератора, например, может быть использовано для создания пакетного файла с помощью file(GENERATE), который соответственно задает переменную среды PATH.

Выражения экспорта и установки

$<INSTALL_INTERFACE:...>: Содержание ... при экспорте свойства с помощью install(EXPORT), в противном случае пустая строка.

$<BUILD_INTERFACE:...>: Содержание ... при экспорте свойства с помощью export(), или когда целевой объект используется другим целевым объектом в той же системе сборки. В противном случае расширяется до пустой строки.

$<BUILD_LOCAL_INTERFACE:...>: Новые в версии 3.26.

Содержание ... когда целевой объект используется другим целевым объектом в той же системе сборки. В противном случае расширяется до пустой строки.

END_OF_DOCUMENT_MARKER

$<INSTALL_PREFIX>: Содержимое префикса установки, когда целевой объект экспортируется через install(EXPORT), или когда оно вычисляется в свойстве INSTALL_NAME_DIR или аргументе INSTALL_NAME_DIR команды install(RUNTIME_DEPENDENCY_SET), в противном случае пусто.

Изменено в версии 3.27: Вычисляется как содержимое префикса установки в аргументе code команды install(CODE) или аргументе file команды install(SCRIPT).

Многоуровневая оценка выражений

$<GENEX_EVAL:expr>: Введено в версии 3.12.

Содержимое expr вычисляется как выражение генератора в текущем контексте. Это позволяет использовать выражения генератора, результаты вычисления которых также являются выражениями генератора.

$<TARGET_GENEX_EVAL:tgt,expr>

Введено в версии 3.12.

Содержимое expr вычисляется как выражение генератора в контексте целевого объекта tgt. Это позволяет использовать пользовательские свойства целевых объектов, которые сами содержат выражения генератора.

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

add_library(foo ...)

set_property(TARGET foo PROPERTY
  CUSTOM_KEYS $<$<CONFIG:DEBUG>:FOO_EXTRA_THINGS>
)

add_custom_target(printFooKeys
  COMMAND ${CMAKE_COMMAND} -E echo $<TARGET_PROPERTY:foo,CUSTOM_KEYS>
)

Эта упрощённая реализация пользовательской команды printFooKeys неверна, потому что свойство целевого объекта CUSTOM_KEYS не вычисляется, и содержимое передаётся как есть (т.е. $<$<CONFIG:DEBUG>:FOO_EXTRA_THINGS>).

Для получения ожидаемого результата (т.е. FOO_EXTRA_THINGS если конфигурация Debug), необходимо вычислить результат $<TARGET_PROPERTY:foo,CUSTOM_KEYS>. Это достигается следующими изменениями:

add_custom_target(printFooKeys
  COMMAND ${CMAKE_COMMAND} -E
    echo $<TARGET_GENEX_EVAL:foo,$<TARGET_PROPERTY:foo,CUSTOM_KEYS>>
)

Экранированные символы

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

$<ANGLE-R>: Литеральный >. Используется, например, для сравнения строк, содержащих >.

$<COMMA>: Литеральный ,. Используется, например, для сравнения строк, содержащих ,.

$<SEMICOLON>: Литеральный ;. Используется для предотвращения расширения списка в аргументе с ;.

Устаревшие выражения

$<CONFIGURATION>: Имя конфигурации. Устарело начиная с CMake 3.0. Используйте CONFIG вместо него.

© 2000–2024 Kitware, Inc. and Contributors
Licensed under the BSD 3-clause License.
https://cmake.org/cmake/help/v3.29/manual/cmake-generator-expressions.7.html