Смотрите последнее обновление статуса

Первоначальные условия

генератор кода, который генерирует множество исходных текстов на c ++, принимая один входной файл в качестве параметравходной файл может включать в себя другие входные файлы

уже решена задача получения списка выходных файлов, парсинга входных файлов codegen для получения полного списка входов codegen. То есть Команда add_custom_command впервые содержит правильный набор зависимостей:

add_custom_command(OUTPUT ${generatedSources}
                   COMMAND ${codegenCommand} ARGS ${codegenArgs}
                   DEPENDS ${codegenInputFiles})

Проблемный сценарий

текущая система работает хорошо, пока кто-то не изменит один из входных файлов codegen для включения нового входного файла или удаления включенного из существующего. В этом случае требуется обновить список входных файлов codegen, предоставленных add_custom_command, как зависимости, но я понятия не имею, как

Чего не хватает

возможность обновления зависимостей add_custom_command при перестройке проекта

Есть ли способ решить эту проблему без полной перестройки проекта?

ОБНОВЛЕНИЕ - Альтернативное (лучшее?) Описание проблемы

Я нашел похожий неотвеченный вопрос в списке рассылки cmake, разместите его здесь для большей ясности:http://article.gmane.org/gmane.comp.programming.tools.cmake.user/52279

Я пытаюсь заставить инструмент генерации кода вести себя "так же, как" исходный файл C по отношению к зависимостям. Под этим я подразумеваю, предположим, у вас есть файл C "a.c". Потому что он может #include файлы, каждый раз, когда содержимоеa.c изменения, его зависимости также могли измениться. Зависимости пересматриваются с -MMD. Я хотел бы каким-то образом подражать этому для моего генератора кода. Сначала я попробовал add_custom_command, который принимает фиксированный список DEPENDS, определенный во время определения пользовательской команды. Конкретно, я имею в виду что-то вроде этого:

function(add_generated_library)
   figure_out_dependencies(deps ${ARGN})
   add_custom_command(... DEPENDS ${deps})
endfunction()

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

ОБНОВЛЕНИЕ 2 - Возможное решение

Следующее, что я считаю фактами, - в Интернете есть голоса, касающиеся поддержки динамических зависимостей cmake, которая необходима для плавной интеграции многих нетривиальных инструментов генерации кода - не существует готового к использованию оптимального решения, как мы на самом деле нужно подключить поддержку пользовательских DSL к IMPLICIT_DEPENDS

Из руководства по cmake:

Опция IMPLICIT_DEPENDS запрашивает сканирование неявных зависимостей входного файла. Данный язык определяет язык программирования, для которого должен использоваться соответствующий сканер зависимостей. В настоящее время поддерживаются только сканеры языков C и CXX. Язык должен быть указан для каждого файла в списке IMPLICIT_DEPENDS.Зависимости, обнаруженные при сканировании, добавляются к зависимостям пользовательской команды во время сборки.

Решение ниже придерживается (надеюсь) следующих критериев:

избежать ненужного сканирования зависимостей при перестройкеизбежать ненужного запуска кода генератора при перестройкепозволяют предоставлять функции cmake клиентам для регистрации их моделей и создания кода / создания библиотек из этого кода без наложения каких-либо требований к структуре проекта (т. е. нет подпроекта, отвечающего за генерацию кода, модели распределяются по иерархии проекта с использованием политики, специфичной для проекта)

Идея решения

Невозможно зарегистрировать пользовательский языковой сканер, но можно повторно использовать существующий. Идея состоит в том, что зависимости / иерархия файлов пользовательских моделей отражаются как иерархия заголовочных файлов «C». Каждый узел иерархии добавляется при регистрации файла модели, а файл C включает файл модели соответствия. Если файл модели включает в себя изменения, C файл включает в себя изменения. Следовательно, каждый вызов codegen будет зависеть только от одного сгенерированного заголовка C, отражающего переданную модель. Каждый отраженный файл будет зависеть от файла модели и будет касаться изменения файла модели.

Подводя итог: возможно, моя формулировка не очень ясна на данный момент, но в отношении потребностей других людей, и сообщество помогло мне исследовать эту проблему, я опубликую общее решение (+ ссылка на github или новую страницу вики cmake) без моей Специфика проекта после его завершения (через 1-3 дня).