Создать Visual Studio Project для сборки с помощью команды
У меня есть решение, где есть зависимость от sfx 7zip. Из-за желания сохранить все решение (плюс sfx) управляемым и скоординированным, я хочу создать новый проект для размещения всех исходных файлов, используемых sfx, и при сборке выполнить командную строку, которая сообщает 7zip для создания sfx из исходных файлов и поместите в вывод, чтобы затем на него можно было ссылаться в реальных проектах Visual Studio в том же решении.
Я думаю, что могу определить командную строку, используя события Build и предоставляя соответствующие макросы, чтобы гарантировать, что выходные данные 7zip будут помещены в целевую папку с соответствующим именем, чтобы затем на нее могли правильно ссылаться другие проекты VS. Но в чем я не уверен, так это в том, какой проект Visual Studio мне нужно использовать или какие шаги нужно предпринять, чтобы сообщить Visual Studio, что в этом проекте не будет никакого кода, который нужно скомпилировать, и он просто должен выполнить этот скрипт, который я даю. Это.
Самым близким, что я могу придумать, является проект Make VS, но я не знаю, правильно ли это, так как это никак не связано с Make.
Итак, какой шаблон проекта Visual Studio мне нужно использовать? Если пусто, то какую конфигурацию мне нужно выполнить, чтобы он не пытался искать некоторые файлы кода для компиляции, а вместо этого просто выполнял сценарии как часть сборки решения?
1 ответ
На данный момент кажется, что использование C++ Makefile Project работает. Мне пришлось сделать несколько конфигураций:
1) Мне нужно было указать "Тип конфигурации" проекта как "Утилиту". 2) Я использовал событие Pre-Build и предоставил команду для вызова пакетного файла, включенного в проект. Пакетный файл тогда заботится обо всем. 3) Обычно файлы, не относящиеся к C++, не рассматриваются для определения необходимости сборки или ее актуальности. Чтобы убедиться, что новая сборка выполняется, если редактируется командный файл или другие ключевые файлы, я установил для "Тип файла" этого файла значение "MakeFile". Даже если это не файл Make, он гарантирует, что любые изменения, внесенные в файл, вызовут новую сборку.
Недостатки, которые я нашел до сих пор:
1) C++ использует "Фильтры", а не папки. Поэтому хранение файлов в одной структуре каталогов - это большая PITA. Можно "включать" файлы и получать взаимно-однозначное сопоставление "Фильтров" и фактической структуры каталогов на диске, но это раздражает и утомительно. Жаль, что это был проект C#
2) Я немного опасаюсь того, как он обнаружит новые файлы или другие изменения для файлов, которые я явно не установил в "MakeFile". Я ожидаю, что исходный код будет стабильным, но я беспокоюсь, что, когда я пойму, что мне нужен новый файл и добавлю его, я могу забыть и не заметить, что сборка неправильно включает новый файл.
Я не уверен, что это лучший метод, но он работает для моей цели - иметь проект для управления внешними инструментами как часть более крупного процесса сборки.