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

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

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

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

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

builds make

— filaton
источник

makeбыл создан в 70-х годах. SHA-1 был создан в 90-х годах. Git был создан в 00-х годах. Последнее, что вы хотите, - это чтобы некоторые неясные сборки, которые работали в течение 30 лет, внезапно потерпели неудачу, потому что кто-то решил перейти на все современное с проверенной и испытанной системой.

— Ордус

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

— CodesInChaos

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

— Док Браун

@Ordous: Забавно, но уместно ли это здесь? Программное обеспечение не ржавеет; это выдает, потому что кто-то что-то изменил в окружающей среде. Если они не сделали, в этом случае это все еще должно работать.

— Роберт Харви

@RobertHarvey Конечно, это так! Конечно, если вы не обновите свое makeПО, ваше программное обеспечение не сломается, но makeприлагает все усилия для обеспечения обратной совместимости в новых версиях. Изменение основного поведения без уважительной причины в значительной степени противоположно этому. И даты показывают, почему он изначально не был создан для использования SHA-1, или почему было нелегко дооснастить его, когда он стал доступен (к тому времени makeуже было десятилетия).

— Ордус

Ответы:

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

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

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

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

— 5gon12eder
источник

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

— Axl

Большинство из того, что вы говорите, правильно. Однако хорошо реализованная система сборки, которая использует хеши, такие как Google Blaze / Bazel (внутренняя версия Blaze, с открытым исходным кодом - Bazel), отстает от системы с метками времени, такой как Make. Тем не менее, вы должны приложить много усилий для повторяющихся сборок, чтобы всегда было безопасно использовать старые артефакты сборки, а не перестраивать.

— Btilly

Отображение здесь не много к одному, это один к одному. Если в Dнастоящее время хэшей H2, и у вас нет какой - то выход T2построен из D@H2, вы должны производить и хранить его. После этого, независимо от того, в каком порядке происходит Dпереключение между состояниями H1и H2, вы сможете использовать кэшированный вывод.

— Асад Саидуддин

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

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

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

— Карл Билефельдт
источник

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

— Асад Саидуддин

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

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

— sdgfsdh
источник