Пользовательские правила сборки в Visual Studio, с несколькими выходами - PullRequest
Новая
       38

Пользовательские правила сборки в Visual Studio, с несколькими выходами

2 голосов
/ 15 сентября 2011

У нас есть проект C ++, который использует собственную систему объектно-реляционного отображения, в которой таблицы определяются в файлах .tbl.Затем они запускаются через генератор кода, который создает для каждого файл .h и .cpp.

Я пытаюсь настроить для этого настраиваемое правило сборки в Visual Studio 2008 и 2010.

Это то, что у меня есть, пока: 

<?xml version="1.0" encoding="utf-8"?>
<VisualStudioToolFile
    Name="z_dbbld"
    Version="8.00"
    >
    <Rules>
        <CustomBuildRule
            Name="z_dbbld"
            DisplayName="z_dbbld"
            CommandLine="$(SolutionDir)\tools\z_dbbld $(InputName)"
            Outputs="$(InputName).cpp"
            FileExtensions="*.tbl"
            ExecutionDescription="z_dbbld  $(InputName)"
            >
            <Properties>
            </Properties>
        </CustomBuildRule>
    </Rules>
</VisualStudioToolFile>

Проблема в зависимостях.Когда я запускаю сборку на чистой проверке, где ни один из файлов не существует, я получаю ошибки «Не удается открыть файл включения» для файлов .h, сгенерированных этим правилом.в "$ (InputName) .h", и я все еще получаю ошибки.

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

Есть идеи?

Ответы [ 2 ]

0 голосов
/ 23 октября 2011

Ответ, данный sblom, является правильным, но он не объясняет причину.

Для каждого правила сборки (пользовательского или собственного) система сборки VS должна знать полный список входов и выходов, чтобыон может решить, какую часть проекта нужно собрать.

Ваше правило сборки объявляет сгенерированный файл .cpp как выходной, поэтому VS знает об этом и автоматически создаст этот файл для вас.Поскольку вы не указали файл заголовка, VS не знает об этом, поэтому любые исходные файлы, содержащие этот заголовок, не будут знать, где его получить, и не смогут его построить.Чтобы обойти сборку, работающую в этой ситуации, нужно добавить каталог, в котором находится этот .h файл, к вашему пути включения, и тогда будет работать #include этого файла.По сути, вы позволяете VS узнать об этом файле по-другому.

И наоборот, если вы измените правило сборки, объявляя файл заголовка как выходной, то включающие его исходные файлы будут знать, где получить этот файл.from, но теперь VS не знает о вашем файле .cpp, поэтому он не будет его собирать.Обходной путь для этого случая заключается в явном добавлении сгенерированного файла .cpp в ваш проект в качестве исходного файла.Как и в приведенном выше случае, вы используете хитрость, чтобы заставить систему сборки распознавать сгенерированный файл.

Но хотя приведенные выше обходные пути помогут вам начать работу, они не являются лучшим решением, поскольку они просто компенсируют VSне зная о файле.Лучший способ решить эту проблему - объявить файлы .cpp и .h как выходные данные в вашем правиле, разделив их точкой с запятой.Это позволит VS применять правильное поведение к обоим файлам.

0 голосов
/ 21 октября 2011

Я думаю, вам нужно указать выходные файлы в основной части сборки (глядя на самое последнее предложение http://msdn.microsoft.com/en-us/library/hefydhhy.aspx). Вероятно, самый простой способ сделать это - добавить ссылку на файлы, когда они существуют, а затем удалите их и посмотрите, выполняется ли шаг codegen так, как должен.

...