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

Question

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

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

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

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

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

1) Запустить пользовательский инструмент для сборки

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

Answer 1

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

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

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

Answer 2

Ответ jheriko интересен, поскольку он позволяет запускать пользовательский инструмент, а затем генерировать зависимости для сборки. Но это не очень удобно, потому что тогда вы теряете все возможности использовать набор инструментов "custom build tools", в котором вы можете

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

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

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