Используйте файлы, специфичные для предметной области, внутри проекта C++.

Question

Я разрабатываю DSL с собственным графическим редактором.Такие файлы имеют расширение .own.У меня также есть небольшой инструмент, который компилирует собственные файлы в файлы .h.

X.own --> X.h и X/*.h

Я написал простой файл .rules для запуска генерации.

Моя проблема заключается в следующем :Большинство моих исходных файлов включают X.h, но изменение X.own не означает, что сгенерированный X.h (или любой другой сгенерированный файл) будет другим.Генератор решает эту проблему за счет использования временных файлов и сравнения файлов.Но Visual Studio, похоже, не знает, как со всем этим справиться.Если я устанавливаю свойство «выходной файл(ы)» для нужного файла(ов), он всегда предполагает, что они будут изменены.Если я этого не сделаю, он генерирует процесс сборки, предполагая, что этого не произойдет!

Как я могу все исправить?

1) Запустите специальный инструмент сборки.

2) Вычисление процесса сборки на основе зависимостей

Answer 1

Ответ Джерико интересен, потому что он дает возможность запустить собственный инструмент, а затем сгенерировать зависимости сборки.Но это не очень удобно, потому что тогда вы потеряете все возможности использовать набор инструментов «настраиваемые инструменты сборки», с помощью которого вы можете

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

Не существует способа (по крайней мере, я его не нашел) «иметь все».Единственный способ, который я нашел, - это заставить пользовательский инструмент сборки возвращать ненулевое число при обновлении файлов с сообщением пользователю, объясняющим, что это нет ошибку и предложить ему снова запустить сборку.В следующий раз собственный инструмент сборки запускается снова (не оптимально, но инструмент, который я использую, довольно быстр), но не изменяет новый файл, и процесс сборки продолжается с использованием действительных зависимостей.

Примечание :описанный выше подход не работает с Incredibuild, который, похоже, игнорирует порядок сборки проекта.

Answer 2

Не используйте параметры пользовательского инструмента сборки, а вместо этого настройте их как событие перед сборкой решения (для этого может использоваться общая командная строка, как и в случае с пользовательским инструментом сборки).Таким образом, MSVS не будет проверять сгенерированные файлы.Пока они #included или указаны в обозревателе решений, они должны быть скомпилированы нормально, поскольку создание файлов .h произойдет до любой другой компиляции.

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

Существует хорошая диаграмма, показывающая, где найти эти параметры в свойствах решения. здесь