Распределенные сборки MSBuild/Visual Studio

Ответ 1

Go посмотрите http://www.xoreax.com/ для Incredibuild. Это не бесплатно, но мы используем его, и это довольно впечатляет. Он хорошо интегрирован в Visual Studio и чрезвычайно прост в использовании. Вы можете столкнуться с проблемой время от времени, но это определенно стоит посмотреть.

После того, как он был установлен, в Visual Studio принцип заключается в том, чтобы использовать меню "Build solution with Incredibuild" вместо "build solution". Все необходимые файлы прозрачно передаются на удаленные компьютеры, а выходные файлы загружаются обратно.

Ответ 2

Я потратил слишком много времени на протяжении последних десяти лет, делая сборки С++ Go Mo Faster, а параллельные сборки могут творить чудеса, но простые вещи иногда делают удивительную разницу.

Вы не указали много особенностей, поэтому я спрошу...

Какова величина проекта? Сколько исходных файлов и т.д. Метрика, которую я использовал в прошлом, должна составлять в среднем одну секунду на исходный модуль (.cpp). С источниками от 200 до более чем 32 000 (не опечатки!) Строк это хорошо работало как показатель в моем прошлом.

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

Вы строите монолитные статические библиотеки и приложения? Если это так, то иногда преобразование в библиотеки DLL приведет к снижению общего времени сборки, так как отдельные единицы связывания будут уменьшаться. Это особенно справедливо для оптимизированных построений с генерации кода link-time.

Эффективно ли используются ваши проекты с использованием предварительно скомпилированных заголовков? Если ваш проект настроен на автоматическое создание предварительно скомпилированных заголовков, то я утверждаю, что вы должны протестировать сборку, отключив все предварительно скомпилированные заголовки. В VS2k3 и VS2k5 я нашел это на самом деле быстрее, надежнее, чем автоматическое поколение. Правильные предварительно скомпилированные заголовки (созданные одним файлом, который делает только это и используется всеми другими файлами), по-видимому, являются курсом лучшей скорости сборки. К сожалению, это действительно черное искусство и несколько проб и ошибок, чтобы получить лучший контент PCH для данного проекта - и этот контент НЕ обязательно стабилен в течение всего жизненного цикла проекта.

Вышеуказанные вещи помогут вам в дополнение к вашему квесту parallelism.

Желаем удачи.

Ответ 3

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

Ответ 4

У Скотта Гензельмана есть пост на Parallel builds здесь. Не полностью распределен, но может помочь некоторым.

Также примечание msbuild не создает сами проекты С++. На самом деле он вызывает vcbuild, чтобы сделать для него грязную работу.

Ответ 5

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

С предыдущими версиями Visual Studio вы можете переопределить cl.exe, lib.exe и link.exe и создать свои собственные обертки. Этот метод был успешно использован для добавления компиляции и связывания неподдерживаемых типов платформ.

Ответ 6

TeamBuild даст вам распределенную систему сборки, которая прекрасно сочетается с Visual Studio.