Частичные сборки и полные сборки в Visual C++
Для большей части моей работы с Visual C++ я использую частичные сборки, например, нажимаю F7 и перестраиваем только измененные файлы C++ и их зависимости, а затем добавочную ссылку. Прежде чем передать версию на тестирование, я принимаю меры предосторожности, чтобы выполнить полное перестроение, которое занимает около 45 минут в моем текущем проекте. Я видел много постов и статей, пропагандирующих это действие, но удивляюсь, нужно ли это, и если да, то почему? Влияет ли это на поставляемый EXE или связанную с ним PDB (которую мы также используем при тестировании)? Будет ли программное обеспечение отличаться от точки зрения тестирования?
Для сборок релизов я использую VS2005, инкрементную компиляцию и компоновку, предварительно скомпилированные заголовки.
6 ответов
Разве не все сталкивались с этой моделью использования? Я получаю странные ошибки при сборке, и даже перед расследованием делаю полную перестройку, и проблема исчезает.
Само по себе это кажется достаточной причиной для полной перестройки перед выпуском.
Я думаю, что вы захотите включить в тестирование инкрементную сборку, которая без проблем завершается, - дело вкуса.
Система частичной сборки работает, проверяя даты файлов исходных файлов по результатам сборки. Так что он может сломаться, если вы, например, восстановите более ранний файл из системы контроля версий. Более ранний файл будет иметь измененную дату раньше, чем продукт сборки, поэтому продукт не будет перестроен. Чтобы защитить от этих ошибок, вы должны сделать полную сборку, если это окончательная сборка. Хотя, пока вы разрабатываете, инкрементные сборки, конечно, гораздо более эффективны.
Изменить: И, конечно, полное перестроение также защищает вас от возможных ошибок в системе инкрементной сборки.
Основная проблема заключается в том, что компиляция зависит от среды (флаги командной строки, доступные библиотеки и, возможно, некоторая черная магия), и поэтому две компиляции будут иметь одинаковый результат, только если они выполняются в одинаковых условиях. При тестировании и развертывании вы должны убедиться, что среды контролируются настолько, насколько это возможно, и вы не получаете странное поведение из-за нечетного кода. Хороший пример - если вы обновите системную библиотеку, а затем перекомпилируете половину файлов - половина все еще пытается использовать старый код, а половина - нет. В идеальном мире это либо сразу приведет к ошибке, либо не вызовет никаких проблем, но, к сожалению, иногда ничего из этого не происходит. В результате выполнение полной перекомпиляции позволяет избежать многих проблем, связанных с поэтапным процессом сборки.
Я определенно рекомендовал бы это. Я неоднократно видел, что с большим решением Visual C++ средство проверки зависимостей не может обнаружить некоторую зависимость от измененного кода. Когда это изменение относится к заголовочному файлу, который влияет на размер объекта, могут начаться очень странные вещи. Я уверен, что средство проверки зависимостей улучшилось в VS 2008, но я все еще не доверял бы ему для сборки выпуска.
Самая большая причина не отправлять инкрементно связанный двоичный файл состоит в том, что некоторые оптимизации отключены. Компоновщик оставит заполнение между функциями (чтобы было проще заменить их при следующей добавочной ссылке). Это добавляет некоторое раздувание к бинарному. Также могут быть дополнительные переходы, которые изменяют схему доступа к памяти и могут привести к дополнительным ошибкам при подкачке и / или кешировании. Старые версии функций могут по-прежнему находиться в исполняемом файле, даже если они никогда не вызываются. Это также приводит к двоичному раздутию и снижению производительности. И вы, конечно, не можете использовать генерацию кода времени соединения с добавочной связью, поэтому вы упускаете больше оптимизаций.
Если вы предоставляете отладочную версию тестеру, то это, вероятно, не имеет большого значения. Но ваши кандидаты на релиз должны создаваться с нуля в режиме релиза, предпочтительно на выделенном компьютере для сборки с контролируемой средой.
Visual Studio имеет некоторые проблемы с частичной (инкрементальной) сборкой (я чаще всего сталкивался с ошибками компоновки). Время от времени бывает очень полезно выполнить полную перестройку.
В случае длительного времени компиляции есть два решения:
- Используйте инструмент параллельной компиляции и используйте ваше (предполагаемое) многоядерное оборудование.
- Используйте сборочную машину. Больше всего я использую отдельную сборочную машину с настроенным CruiseControl, которая время от времени выполняет полную перестройку. "Официальный" выпуск, который я предоставляю группе тестирования и, в конечном итоге, заказчику, всегда берется из сборочной машины, а не из среды разработчика.