Visual Studio: составить список модулей на каждой платформе и конфигурации

Question

Я работаю над огромным проектом C++, ориентируясь на многие платформы с несколькими конфигурациями для каждой платформы.

Из-за длительного времени компиляции создайте весь проект на каждой платформе, чтобы проверить, успешно ли скомпилировано изменение, это не вариант.

Что я обычно делаю, это компиляция отдельных модулей cpp, которые я модифицировал на разных комбинациях платформы/конфигурации. Я хотел бы автоматизировать этот процесс, используя скрипт, расширение VS, независимо от того, я открыт для оценки различных параметров.

То, что мне нужно, это взять список файлов cpp и скомпилировать каждый файл для каждой платформы и каждой конфигурации (в основном, итерации по всей комбинации диспетчера конфигурации).

Возможно ли это? любое хорошее предложение о том, как подойти к проблеме?

---

EDIT:

Я знаю, что это путь далеко, чтобы быть идеальным решением, и будет обнаружить только подмножество ошибок. Мне все равно придется сталкиваться с ошибками связи, ошибки компилятора на других блоках cpp зависят от измененного заголовка и т. Д.

У меня также нет возможности изменить текущую систему сборки или генерацию проекта ,

Меня больше всего интересует местное решение, чтобы уменьшить количество возможных проблем и столкнуться с огромным процессом построения здания.

---

EDIT2

У нас есть система сборки. Это нужно рассматривать как оптимизацию системы предварительной сборки для моего личного рабочего процесса.

Причина:

запуская работу системы сборки требует времени. Это будет последний шаг, но вместо того, чтобы тратить часы на ожидание и, возможно, позже узнайте, что данный компилятор на данной платформе для конкретной конфигурации вызывает ошибку, было бы гораздо более эффективно прогнозировать эти выводы как можно больше.

Текущий ручной рабочий процесс:

1. Открыть каждый файл CPP я изменил
2. компиляции каждый файл CPP как единое целое (. Не строит проект на VS Build-> Compile)
3. Изменение платформы и/или конфигурации и повторить пункт 2 снова.

Это ручной рабочий процесс, который я хотел бы оптимизировать.

Answer 1

Я хотел бы предложить, что вы «просто» написать скрипт, чтобы сделать это (с помощью Python, например, что является очень мощным для такого рода это)

Вы могли:

• Разбирает. sln-файл для извлечения списка конфигураций, платформ (GlobalSection(SolutionConfigurationPlatforms)) и проектов (Project)
• При необходимости вы можете анализировать каждый проект, чтобы найти список исходных файлов (это проще, чем разбор .sln, как файлы vcxproj находятся в xml). Найдите ClCompile узлы xml, чтобы извлечь список .cpp-файлов.
• Затем вы можете определить, какие проекты нужны какие-то файлы, которые будут перекомпилированы (получение списка измененных файлов в качестве входных параметров сценария или на основе временной метки проверки)

Наконец, для восстановления, у вас есть два варианта:

• Вызов «MSBuild» перекомпилировать весь проект (vcxproj) (например msbuild project.vcxproj /p:Configuration=Debug;TargetFrameworkVersion=v3.5)
• Вы также можете перекомпилировать один файл (cl simple.cpp). Для этого вам нужно знать, каковы параметры сборки cl, чтобы убедиться, что вы скомпилируете файл точно так же, как и Visual Studio. Если вы ранее сделали полную сборку решения (это может быть проблемой для работы вашего скрипта), тогда вы сможете найти это из журналов Visual Studio (в целевой папке). В моих решениях я могу найти для каждого проекта (файл vcxproj) журнал построения для каждой конфигурации (в %OUTPUT_DIR%\lib\%libname%\%libname%.dir\%configuration%\%libname%.tlog\CL.command.1.tlog), этот файл сообщает точные аргументы cl, которые использовались для компиляции каждого файла проекта. Затем вы можете вручную вызвать команду cl, и это должно привести к перекомпиляции файла так же, как это сделала бы Visual Studio.

Additionnaly, вы можете добавить проект в свое решение Visual Studio, которое должно было бы запустить этот скрипт как пользовательскую команду.

Такой сценарий должен быть способен определить, какие проекты необходимо перестроить и перестроить.

Answer 2

Это очень общее требование, оно никогда не решается таким образом. То, что вы предлагаете, не совсем невозможно, но это, безусловно, очень больно. Вы не замечаете, что должно произойти, когда вы изменяете файл .h, что может привести к перекомпиляции связки файлов .cpp. И вы не рассматриваете ошибки компоновщика. В то время как у вас есть шанс обнаружить файлы .cpp, обнаружение зависимостей файлов #include очень серьезное. Вы не можете получить их из проекта или сделать файл. Компиляция с/showIncludes и анализ файлов трассировки сборки - вот что нужно. Ничего готового афайка.

Не делайте этого, вы пожалеете об этом. Используйте решение, которое все используют: вам нужен сервер сборки. Предпочтительно с функцией непрерывной интеграции, поэтому сервер запускает сборку для всех целевых платформ сразу же после регистрации кода. Многие на выбор, this Q+A рассказывает об этом.