Частичные сборки по сравнению с полными сборками в Visual C ++

Question

Для большей части моей работы по разработке с Visual C ++ я использую частичные сборки, напримернажмите F7, и будут восстановлены только измененные файлы C ++ и их зависимости, за которыми последует добавочная ссылка.Прежде чем передавать версию на тестирование, я принимаю меры предосторожности и выполняю полную перестройку, которая в моем текущем проекте занимает около 45 минут.Я видел много постов и статей, пропагандирующих это действие, но интересно, необходимо ли это, и если да, то почему?Влияет ли это на поставляемый EXE-файл или связанный PDB (который мы также используем при тестировании)?Будет ли программное обеспечение функционировать как-то иначе с точки зрения тестирования?

Для релизных сборок я использую VS2005, инкрементную компиляцию и компоновку, предварительно скомпилированные заголовки.

Answer 1

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

Это само по себе кажется мне достаточной причиной для выполнения полной перестройки перед выпуском.

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

Answer 2

Система частичной сборки работает путем сверки дат исходных файлов с результатами сборки.Таким образом, он может сломаться, если вы, напримервосстановите более ранний файл из системы управления версиями.Более ранний файл имел бы дату изменения, более раннюю, чем продукт сборки, поэтому продукт не был бы перестроен.Чтобы защититься от этих ошибок, вам следует выполнить полную сборку, если это окончательная сборка.Однако, пока вы разрабатываете, инкрементные сборки, конечно, намного эффективнее.

Редактировать:И, конечно же, выполнение полной перестройки также защищает вас от возможных ошибок в системе инкрементной сборки.

Answer 3

Основная проблема заключается в том, что компиляция зависит от среды (флаги командной строки, доступные библиотеки и, возможно, некоторая Черная магия), и поэтому две компиляции будут иметь одинаковый результат, только если они выполняются в одинаковых условиях.При тестировании и развертывании вы хотите убедиться, что среды максимально контролируются и вы не получаете странного поведения из-за нечетного кода.Хороший пример - если вы обновляете системную библиотеку, затем перекомпилируете половину файлов - половина все еще пытается использовать старый код, половина - нет.В идеальном мире это либо сразу привело бы к ошибке, либо не вызвало бы никаких проблем, но, к сожалению, иногда ни того, ни другого не происходит.В результате выполнение полной перекомпиляции позволяет избежать множества проблем, связанных с поэтапным процессом сборки.

Answer 4

Я бы определенно рекомендовал это.Я несколько раз видел, как в большом решении Visual C ++ средство проверки зависимостей не обнаруживает некоторой зависимости от измененного кода.Когда это изменение относится к заголовочному файлу, который влияет на размер объекта, могут начать происходить очень странные вещи.Я уверен, что средство проверки зависимостей стало лучше в версии 2008, но я все равно не стал бы доверять ему для сборки релиза.

Answer 5

Самая большая причина не отправлять бинарный файл с постепенной привязкой заключается в том, что некоторые оптимизации отключены.Компоновщик оставит отступы между функциями (чтобы упростить их замену при следующей добавочной ссылке).Это добавляет некоторого раздувания двоичному файлу.Также могут быть дополнительные переходы, что изменяет схему доступа к памяти и может привести к дополнительной подкачке и / или промахам кэша.Более старые версии функций могут продолжать находиться в исполняемом файле, даже если они никогда не вызывались.Это также приводит к раздуванию двоичных файлов и снижению производительности.И вы, конечно, не можете использовать генерацию кода во время ссылки с инкрементным связыванием, поэтому вы упускаете дополнительные оптимизации.

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

Answer 6

В Visual Studio время от времени возникают некоторые проблемы с частичными (инкрементными) сборками (в основном я сталкивался с ошибками компоновки), поэтому очень полезно выполнить полную перестройку.

В случае длительного времени компиляции есть два решения:

1. Используйте инструмент параллельной компиляции и воспользуйтесь преимуществами вашего (предполагаемого) многоядерного оборудования.
2. Используйте машину сборки.Больше всего я использую отдельную машину сборки с настроенным CruiseControl, которая время от времени выполняет полную перестройку."Официальный" релиз, который я предоставляю команде тестирования и, в конечном счете, заказчику, всегда берется с компьютера сборки, а не из среды разработчика.