Ответ 1
Мне не известно какое-либо общее решение в соответствии с указанными ограничениями - в частности, нужно создать много проектов из дерева исходных текстов.
Лучший вариант, который я вижу, - это фактически создание файлов проекта с помощью script.
- Создание отдельного проекта вручную (создание пустого проекта, затем добавление файлов),
- Настройте его как можно ближе (желательно с предварительно скомпилированными заголовками, конфигурациями сборки и т.д.).
- Используйте .vcproj, созданный как скелет для создаваемых файлов проекта.
Очень простой способ: список файлов, название проекта и т.д. со "странными токенами" и заполнение их вашим генератором. Если вы хотите быть хорошим парнем, вы можете, конечно, использовать некоторую библиотеку обработки XML.
Наш опыт:. На самом деле мы больше не сохраняем .vcproj и .sln в репозитории (git), но python script, который переназначает их из исходного дерева, вместе с VS 2008 "шаблоны шаблонов свойств" (или что бы они ни называли). Это помогает сделать общие корректировки.
Генерация проекта script содержит информацию обо всех специализированных проектах (например, они используют MFC/ATL, будут ли они создавать DLL или EXE, файлы для исключения).
Кроме того, этот script также содержит зависимости, которые подают фактическую сборку script.
Это работает довольно хорошо, проблемы незначительны: python requried в системах сборки, не забывая обновлять файлы проекта, мне нужно изучить некоторый python, чтобы внести коррективы в некоторые проекты.
@Michael Burr "Насколько сложны скрипты python и любые поддерживающие" шаблоны ", которые могут вам понадобиться?
Честно говоря, я не могу сказать, так как я дал задание другому dev (который выбрал python). Первоначальная задача состояла в том, чтобы предоставить сборку script, поскольку сборка VS2008 не была достаточно хороша для наших нужд, а старый командный файл не поддерживал распараллеливание. .vcproj поколение было добавлено позже. Насколько я понимаю, его script генерирует файлы .vcproj и .sln с нуля, но извлекает все настройки из отдельных листов свойств.
Плюсы:
-
Добавление новых конфигураций "на лету". В некоторых из проектов уже было шесть конфигураций, а планирование поддержки в Юникоде означало возможность удвоения их на некоторое время. Некоторые неудобные инструменты по-прежнему создаются как MBCS, поэтому некоторые библиотеки имеют 8 конфигураций. Настройка этого из рук - боль, теперь это меня больше не беспокоит.
-
Глобальные изменения, например. перемещая по относительным траекториям проекта, папку для файлов temp и для окончательных двоичных файлов, пока мы не найдем решение, в котором мы были довольны
-
Стабильность сборки. Слияние файлов проектов VC6 явилось заметным источником ошибок по разным причинам, а файлы проектов VC9 выглядели не лучше. Теперь все выглядит лучше: настройки компиляции/ссылки в листах свойств, обработка файлов в script. Кроме того, script в основном отображает варианты от нашего значения по умолчанию, в результате их легче читать, чем файл проекта.
В целом: я не вижу большой пользы, когда ваши проекты уже настроены, они довольно стабильны, и у вас нет реальных проблем. Однако при переходе к неизвестному (для нас: в основном, VC6 → VC9 и Unicode) гибкость значительно снижает риск экспериментов.
