Инкрементальные сборки C ++ для непрерывной интеграции - PullRequest
3 голосов
/ 11 марта 2011

У нас есть довольно большой проект C ++, построенный в VS2005, который может занять до 40 минут для компиляции и сборки с нуля, и еще 10 минут для установщиков, поскольку программное обеспечение собирается как в 32-битной, так и в 64-битной конфигурации. Я хотел бы сократить это время, по крайней мере, до 10 минут, так как считаю, что важно получить быструю обратную связь по сборке при использовании непрерывной интеграции.

При использовании инкрементных сборок путем удаления окончательных связанных файлов, но не файлов .obj, процесс сборки, по-видимому, идет намного быстрее, однако иногда появляются ошибки, например, невозможность загрузки DLL-файлов. С чистой сборки все работает отлично. Я использую TeamCity как систему выбора CI.

Может быть, поведение инкрементной сборки лучше в более поздних версиях Visual Studio, и это может быть хорошей мотивацией для обновления? Кто-нибудь сталкивался с подобными проблемами?

Ответы [ 4 ]

2 голосов
/ 11 марта 2011

На самом деле я не могу ответить на ваш вопрос, но, поскольку вы хотите ускорить сборку, этот пост в блоге о быстрых сборках с Visual Studio 2010 и SSD может оказаться полезным.http://qualapps.blogspot.com/2010/09/lightning-fast-builds-with-visual.html

1 голос
/ 11 марта 2011

Хороший вопрос.

Когда я собирал систему CI для большого проекта C ++ для Microsoft Visual Studio 2003/2005/2008, я также встречал проблемы с инкрементными сборками.Особенно при использовании предварительно скомпилированных заголовков, кажется, не работает при всех обстоятельствах делать инкрементную сборку.Мне было бы интересно услышать, если у кого-то есть подробное объяснение этого, то есть, что работает, а что нет.

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

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

Другие вопросы, которые следует учитывать:

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

Существует множество вещей, которые могут бытьсделано для ускорения сборки, и в большинстве случаев я бы отнес их к инкрементным сборкам.

1 голос
/ 11 марта 2011

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

Я должен также упомянуть IncrediBuild.Бросить аппаратное обеспечение в проблему, особенно аппаратное обеспечение, которое у вас уже есть, - быстрая победа.

1 голос
/ 11 марта 2011

Мой опыт показывает, что часто, особенно для отладочных сборок, узким местом является дисковый ввод-вывод. Это помогает сжимать выходные и промежуточные файлы каталогов. Кроме того, я видел, что некоторые сборки работают быстрее, когда не используется функция инкрементного связывания (Включить инкрементное связывание - нет). Другим параметром, который следует учитывать, является отключение генерации информации о просмотре (Включить информацию о просмотре - нет). Кроме того, не забудьте использовать функцию параллельной компиляции в VS 2005. Поскольку часто узким местом является именно IO, он помогает использовать больше потоков сборки, чем процессоров.

...