Как бороться с предварительно скомпилированными заголовками, случайно поврежденными при отмене сборки?
Я использую Visual C ++ 2012 с проектом, который интенсивно использует предварительно скомпилированные заголовки. Так тяжело, что печально / Zm переключатель используется.
Когда я отменяю сборку, я иногда получаю эту ошибку при следующей сборке:
error C1852: 'foo.pch' is not a valid precompiled header file
В девяти случаях из десяти все пройдет гладко, но когда это произойдет, я должен найти .pch и удалить его вручную перед перезапуском сборки.
Это меня немного раздражает. Есть ли способ предотвратить это? Патч от Microsoft? Или способ заставить Visual удалить .pch и автоматически перезапустить сборку при возникновении проблемы? Или какое-то другое решение, о котором я не думал?
РЕДАКТИРОВАТЬ: Вот версия Visual, я бегу:
Microsoft Visual Studio Professional 2012
Version 11.0.61030.00 Update 4
Решение
Это чисто догадка, так как я не сталкивался с этой проблемой.
Попытайтесь выяснить, как Visual обнаружил, что файл .pch поврежден (т. Е. Пустой файл, файл неправильно завершен, …). Если это следует четкому шаблону, напишите сценарий предварительной сборки, который анализирует все файлы .pch и удаляет поврежденные.
Другие решения
Я бы создал скрипт, который попытался бы перекомпилировать stdafx.cpp файл, но на этот раз, используя PCH вместо его генерации. То есть ожидаемый результат — успешная компиляция пустого файла. Если это не удается, удалите PCH. Теперь запустите этот скрипт как шаг перед сборкой.
Звучит довольно дорого, но очень надежно. Любая проблема загрузки PCH вызывает его регенерацию, даже обновления компилятора. Кроме того, ваш PCH теперь находится в файловом кеше, что означает, что фактическое использование немного дешевле.
Это может быть реализовано как скрипт сборки NMAKE с несколько необычными правилами.
Я последовал предложению Rockeye попытаться найти образец в этих поврежденных файлах. Оказывается, это очень просто: допустимые файлы начинаются с VCPCH0 Заголовок, поврежденные файлы нет.
Простая программа на C #, запускаемая как событие предварительной сборки неудачного проекта (ов) и удаляющее поврежденные файлы, решает проблему. Если кому-то интересно, источник Прямо здесь.