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. Несколько элементов должны быть разделены запятыми.

Указание 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 (или значений) удалены. Если задано несколько значений, они должны быть разделены запятыми.

$<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) для получения дополнительной информации.

Запросы к пути

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

END_OF_DOCUMENT_MARKER

$<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 и более ранние версии принимали только одну конфигурацию.

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

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

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

Действительно только в add_custom_command() и add_custom_target() как внешнее выражение генератора в аргументе. С генератором Ninja Multi-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>: Версия используемого компилятора CXX.

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

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

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

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

1 если версия компилятора CXX соответствует 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.

END_OF_DOCUMENT_MARKER

$<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.

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

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

$<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.

$<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.

$<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 соответствует любому из элементов, разделённых запятыми, в 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 является компилятором C++, и COMPILING_CXX_WITH_INTEL когда Intel является компилятором C++. Аналогично, когда компилятор 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

Этот параметр сообщает линковщику искать указанную фреймворк, используя параметр линковщика -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-цель типа ОБЪЕКТ или ИНТЕРФЕЙС проигнорирует аспект функции выражения и вместо этого будет связана стандартным способом.
Выражение генератора $<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 toolchain.

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

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

Если языковая переменная 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 типа ОБЪЕКТ или ИНТЕРФЕЙС проигнорирует аспект функции выражения и вместо этого будет слинкован стандартным образом.
Выражение генератора $<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.

$<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 не добавляется в качестве зависимости целевого объекта, для которого вычисляется это выражение, если выражение используется в add_custom_command() или add_custom_target().

$<TARGET_FILE_BASE_NAME:tgt>

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

Базовое имя tgt, т.е. $<TARGET_FILE_NAME: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.

$<TARGET_FILE_PREFIX:tgt>

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

Префикс имени файла целевого бинарника (например, lib).

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

$<TARGET_FILE_SUFFIX:tgt>

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

Суффикс имени файла целевого бинарника (расширение, например, .so или .exe).

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

$<TARGET_FILE_NAME:tgt>

Имя файла целевого бинарника.

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

$<TARGET_FILE_DIR: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.

$<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_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.

$<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.

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

$<INSTALL_PREFIX>: Содержимое префикса установки, когда целевой объект экспортируется через install(EXPORT), или когда вычисляется в свойстве INSTALL_NAME_DIR, аргументе INSTALL_NAME_DIR команды install(RUNTIME_DEPENDENCY_SET), аргументе 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 если config — 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.28/manual/cmake-generator-expressions.7.html