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