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

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

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

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


c++ build-automation visual-c++ incremental-build
person Can Gencer    schedule 11.03.2011    source источник
comment
Не могли бы вы подробнее рассказать об упомянутых вами ошибках? Мне трудно понять, почему частичная сборка вызывает проблемы с загрузкой DLL. Означает ли это, что вы всегда делаете чистую сборку своего проекта, чтобы он работал?   -  person rotoglup    schedule 11.03.2011
comment
У нас есть небольшой скрипт, который вызывает LoadLibrary () для всех .dll, просто чтобы убедиться, что все требования зависимостей соблюдены. Кажется, что это не работает для некоторых из .dll. Проблема, похоже, не возникает, если мы создаем через Visual Studio или при использовании msbuild из командной строки и двойном вызове. Но я думаю, что инкрементные сборки зависят от дат исходного кода, возможно, когда TeamCity обновит код из репозитория, дата, измененная в файле, также будет возвращена (мы используем ртутный). Я исследую это дальше.   -  person Can Gencer    schedule 11.03.2011

Ответы (4)


arrow_upward
1
arrow_downward

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

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

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

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

Также следует учитывать:

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

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

person murrekatt    schedule 11.03.2011

arrow_upward
2
arrow_downward

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

person Marius Bancila    schedule 11.03.2011
comment
спасибо за ссылку. Я думал о твердотельных накопителях, а также об обновлении процессора. Очевидно, что вы всегда можете добавить больше оборудования для решения проблемы, я надеялся найти способ заставить инкрементные сборки работать надежным образом, и если это сработает, это будет еще быстрее с новым оборудованием. - person Can Gencer; 11.03.2011
comment
Не хочу, чтобы вы запутались :), но есть и противоположные мнения насчет SSD, как этот от Джеффа Палермо. jeffreypalermo.com/blog/ - person Marius Bancila; 11.03.2011

arrow_upward
1
arrow_downward

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

person wilx    schedule 11.03.2011
comment
Да, мы используем недокументированный флаг параллельной сборки, и это немного помогло. Я попытаюсь настроить ramdisk или что-то подобное и посмотрю, поможет ли это процессу. - person Can Gencer; 11.03.2011
comment
@Can Gencer: Какой незаметный флаг параллельной сборки? Я имел в виду Инструменты - Параметры - Проекты и решения - Сборка и запуск - настройка максимального количества параллельных сборок проекта. Если вы используете MSBuild или VCBuild, у обоих есть несколько вариантов с одинаковым эффектом. - person wilx; 11.03.2011
comment
Вы имеете в виду параллельное строительство проектов. Я не пробовал это, так как я вспомнил, как давно читал, что это не очень надежно. Я дам ему попробовать. Я имел в виду флаг / MP для многоядерной компиляции. Он доступен в VS2008 и VS2005 как недокументированный флаг. msdn.microsoft.com/en-us/library/bb385193.aspx - person Can Gencer; 11.03.2011

arrow_upward
1
arrow_downward

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

Отдельно стоит упомянуть IncrediBuild. Решить проблему с помощью оборудования, особенно оборудования, которое у вас уже есть, - это быстрая победа.

person MSalters    schedule 11.03.2011
comment
Во всех проектах он настроен как Default, что, как я полагаю, означает, что он не включен. Incredibuild звучит интересно, разберемся с этим. - person Can Gencer; 11.03.2011