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