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

Question

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

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

Answer 1

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

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

Answer 2

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

Answer 3

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

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

Answer 4

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

Answer 5

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

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

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

Answer 6

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

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

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