Visual Studio не обнаруживает, что exe устарел после восстановления исполнения

Question

Это немного странная ситуация. Вот что происходит.

Итак, у нас есть проект VS2008, который выводит количество файлов, находящихся под контролем исполнения. Эти файлы имеют установленный флаг записи.

Я компилирую проект в VS, что дает мне обновленные двоичные файлы на моей машине. Если я затем верну эти двоичные файлы с помощью Perforce, у меня будет версия двоичных файлов, которые были включены на Perforce (то есть старые).

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

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

Фактический процесс сборки использует инструмент сборки Unreal, так что за кулисами происходит немного магии, с которой я тоже не совсем знаком.

Редактировать: Это проект C / C ++, забыл упомянуть об этом.

Answer 1

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

Подобные проблемы наблюдаются, когда компилятор и хостинг файлов различаются, а их часы не синхронизированы.

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

Answer 2

У вас отключена опция клиента modtime (т. Е. Установлена ​​на nomodtime)? Если опция отключена, Perforce будет синхронизировать все файлы с использованием текущей даты и времени (включая, я полагаю, файлы, которые вы явно возвращаете), поэтому, если ваша система сборки просто проверяет временные метки файлов, она будет считать, что двоичный файл новее исходного файлы и объявить себя завершенным.

(Я намеренно отключаю modtime в моих клиентах, чтобы при синхронизации исходных файлов моя система сборки всегда перестраивала потенциально уязвимые двоичные файлы.)

Answer 3

Я сталкивался с подобными «проблемами» с SVN, так что это то, что является общим для большинства систем контроля версий:

Когда вы обновляете или возвращаете или каким-либо образом изменяете файлы под управлением версиями, они, как правило, отнимают время - так же, как при использовании касания. Итак, как отметил Коммодор, ваш двоичный файл теперь новее, чем что-либо еще, поэтому он «должен» обновляться.

У меня был похожий опыт при возврате исходного файла (особенно файла заголовка), и я не ожидал, что восстановление будет происходить, потому что я ожидал, что возврат будет похож на DOS COPY, а потому что рассматриваемый файл берет на себя В настоящее время VS считает, что двоичные файлы устарели, и перестраивает все, что зависит от исходного файла.

Это сделано так, что вы никогда не получите такие вещи, как библиотеки, созданные с разными версиями заголовков.

Вы можете попробовать «дотронуться» до критически важного файла (например, файла общего заголовка), чтобы вызвать перестройку, или просто попросить Visual Studio выполнить полную перестройку.

Да, и не помещайте файлы, являющиеся результатом сборки, под контроль версий - вам нужны только исходные файлы. Вам нужно хранить свои файлы в другом месте, возможно, в устаревших папках.