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

Question

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

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

Answer 1

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

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

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

Answer 2

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

Answer 3

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

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

Answer 4

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

Answer 5

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

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

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

Answer 6

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

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