Почему в инкрементных сборках «make» не используются алгоритмы хеширования?

Я начинающий, makeи мне интересно, когда использовать make clean.

Один коллега сказал мне, что инкрементные сборки с makeиспользованием временных меток файлов. Таким образом, если вы извлекаете старую версию файла в вашей VCS, у нее будет «старая» временная метка, и она будет помечена как «нет необходимости перекомпилировать этот файл». Тогда этот файл не будет включен в следующую сборку.
По словам того же коллеги, это будет поводом для использования make clean.

В любом случае, я примерно получил ответ на вопрос «когда использовать make clean» из других вопросов StackExchange, но другой мой вопрос:

Почему инкрементные сборки используют makeвременные метки файлов, а не SHA-1, например? Git, например, показывает, что мы можем успешно определить, был ли файл изменен с использованием SHA-1.
Это из-за проблем со скоростью?

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

Более серьезно, однако, хэш не передал бы ту же семантику. Если вы знаете, что файл T был создан из зависимости D с хеш-кодом H _1, а затем обнаруживаете, что D теперь хеширует H ₂ , вам следует пересобрать T ? Вероятно, да, но также может быть, что H ₂ фактически ссылается на более старую версию файла. Отметки времени определяют порядок, а хэши сопоставимы только по равенству.

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

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

Хэширование всего проекта происходит очень медленно. Вы должны прочитать каждый байт каждого файла. Git не хеширует каждый файл каждый раз, когда вы запускаете a git status. Кроме того, проверки VCS обычно не устанавливают время модификации файла в исходное авторское время. Резервное восстановление будет, если вы позаботитесь об этом. Причина, по которой файловые системы имеют временные метки, заключается в таких случаях использования.

Разработчик обычно запускается, make cleanкогда зависимость, не отслеживаемая непосредственно Makefile, изменяется. Как ни странно, это обычно включает сам Makefile. Обычно он также включает в себя версии компилятора. В зависимости от того, насколько хорошо написан ваш Makefile, он может включать версии внешних библиотек.

Это те вещи, которые имеют тенденцию обновляться, когда вы выполняете обновление контроля версий, поэтому большинство разработчиков просто имеют привычку запускать их make cleanодновременно, так что вы знаете, что начинаете с чистого листа. Вы можете уйти, не делая этого много времени, но действительно трудно предсказать времена, когда вы не можете.

Несколько моментов, касающихся хэшей и временных меток в сборочных системах:

1. Когда вы извлекаете файл, отметка времени должна обновляться до текущего времени, что вызывает перестроение. То, что описывает ваш коллега, обычно не является режимом сбоя систем отметок времени.
2. Метки времени немного быстрее, чем хэши. Система меток времени должна проверять только метку времени, тогда как система хэширования должна проверять метку времени, а затем и потенциально хэш.
3. Make разработан, чтобы быть легким и автономным. Чтобы преодолеть (2), системы, основанные на хэше, обычно запускают фоновый процесс проверки хэшей (например, сторож Facebook ). Это противоречит целям дизайна (и истории) Make.
4. Хэши предотвращают ненужные перестроения, когда метка времени изменилась, но не содержимое. Часто это компенсирует стоимость вычисления хэша.
5. Хэши позволяют совместно использовать кеши артефактов между проектами и по сети. Опять же, это более чем компенсирует стоимость вычислений хэшей.
6. Современные основанные на хэше системы сборки включают Bazel (Google) и Buck (Facebook).
7. Большинству разработчиков следует подумать об использовании системы на основе хеша, поскольку у них нет тех же требований, что и для тех, для которых был разработан Make.