Ответ 1
Пока я занимаюсь своими исследованиями, чтобы правильно задать вопрос, я нашел три решения. Учитывая, как трудно было найти эту информацию, я решил оставить вопрос и ответить здесь в любом случае.
1. Использование глобальной переменной CMAKE_MSVCIDE_RUN_PATH
Существует специальная переменная, предназначенная для решения этой точной проблемы - CMAKE_MSVCIDE_RUN_PATH. Если установлено, это приводит к тому, что строка добавляется к шагу пользовательской сборки script:
set PATH=<CMAKE_MSVCIDE_RUN_PATH>;%PATH%
Итак, все, что вам нужно, это что-то вроде этого в хорошем месте:
set(CMAKE_MSVCIDE_RUN_PATH ${LibFoo_RUNTIME_LIBRARY_DIRS})
Я первоначально заметил эту переменную только в источниках CMake, потому что раньше она была недокументирована до CMake 3.10. Таким образом, вы не сможете найти его в документации для старых версий CMake, но не волнуйтесь, это было поддерживаемое с 2006 года.
Преимущества:
▪ Может быть включен в одном центральном месте
▪ Никаких изменений вообще в каких-либо командах add_custom_command()
в другом месте не требуется
▪ Установлен только сам путь, никакие командные команды не должны быть явно записаны
▪ Очевидный выбор с четким названием и намерением
Недостатки:
▪ Глобальный для всего проекта CMake и всех пользовательских команд
▪ Работает только с "Visual Studio 9 2008" и выше генераторами
2. Установка PATH явно с использованием двух параметров COMMAND
Созданный script для этапа пользовательской сборки в Visual Studio содержит некоторый пролог, а затем сами команды, а затем некоторый эпилог. Не удалось бы просто добавить set PATH=...
перед реальной командой через другой параметр COMMAND
?
Документация для add_custom_command()
гласит:
COMMAND
Укажите командные строки для выполнения во время сборки. Если указано более одногоCOMMAND
, они будут исполняться по порядку, но не обязательно сгруппированы в оболочку с выражением состояния или пакет script.
Так что нет, это не гарантировано. Но генератор проекта Visual Studio на самом деле делает это как это, т.е. отдельные команды просто добавляются один за другим, поэтому следующее выполняет задание:
add_custom_command(OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/Table.h"
COMMAND set "PATH=${LibFoo_RUNTIME_LIBRARY_DIRS};%PATH%"
COMMAND TableGenerator "${CMAKE_CURRENT_BINARY_DIR}/Table.h"
DEPENDS TableGenerator)
Преимущества:
▪ PATH может быть изменен для каждой пользовательской команды явно
Недостатки:
▪ Опирается на недокументированное поведение генератора
▪ Необходимо переписать всю команду для Windows и сохранить обе версии в синхронизации.
▪ Каждая пользовательская команда должна быть явно изменена
3. Используя file(GENERATE ...)
для создания пользовательского script
Продолжается документация для add_custom_command()
, приведенная выше:
Чтобы запустить полный script, используйте команду
configure_file()
или командуfile(GENERATE)
для ее создания, а затем укажитеCOMMAND
, чтобы запустить его.
Это немного беспорядочно из-за дополнительных временных файлов и команд:
file(GENERATE OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/RunTableGenerator.cmd"
CONTENT "set PATH=${LibFoo_RUNTIME_LIBRARY_DIRS};%PATH%
%1 ${CMAKE_CURRENT_BINARY_DIR}/Table.h")
add_custom_command(OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/Table.h"
COMMAND "${CMAKE_CURRENT_BINARY_DIR}/RunTableGenerator.cmd" "$<TARGET_FILE:TableGenerator>"
DEPENDS TableGenerator)
Обратите внимание на неудобный способ отправки пути к исполняемому файлу в качестве аргумента. Это необходимо, потому что script записывается один раз, но TableGenerator
может быть в разных местах для разных конфигураций (отладка и выпуск). Если выражение генератора использовалось непосредственно в контенте, была бы напечатана ошибка CMake, и проект не будет правильно построен для всех, кроме одной конфигурации.
Преимущества:
▪ PATH может быть изменен для каждой пользовательской команды явно |
▪ Полностью документированное и рекомендуемое решение
Недостатки:
▪ Очень шумно в CMakefiles
▪ Необходимо переписать всю команду для Windows и сохранить обе версии в синхронизации.
▪ Каждая пользовательская команда должна быть явно изменена
4. Запустите пользовательскую команду через оболочку CMake
См. другой ответ, представленный Дивиром Ицхаки.
Я лично остановился на решении №1, потому что он был чистым и простым, даже до того, как он получил надлежащую документацию и поддерживался CMake в версии 3.10. Это должен быть лучший путь для вас, если вам не нужно делать что-то еще более особенное.