Чому інкрементні побудови в "make" не використовують алгоритми хешування?

Я початківець з, makeі мені цікаво, коли використовувати make clean.

Один колега сказав мені, що додаткові версії з makeвикористанням базуються на часових позначках файлів. Отже, якщо ви перевірите стару версію файлу у своєму VCS, у нього буде "стара" часова мітка, і вона буде позначена як "не потрібно перекомпілювати цей файл". Тоді цей файл не буде включений до наступної збірки.
За словами того самого колеги, це було б приводом для використання make clean.

У будь-якому випадку, я приблизно отримав відповідь на питання "коли використовувати make clean" з інших питань StackExchange, але моє інше питання:

Чому інкрементні побудови, використовуючи, наприклад, makeпокладаються на часові позначки файлів, а не на SHA-1? Наприклад, Git показує, що ми можемо успішно визначити, чи був файл змінений за допомогою SHA-1.
Це для питань швидкості?

builds make

— філатон
джерело

makeбуло створено в 70-х роках. SHA-1 був створений у 90-х. Git був створений у 00-х. Останнє, що ви хочете, - це те, що деякі незрозумілі конструкції, які працювали протягом 30 років, раптом провалилися, тому що хтось вирішив перейти все сучасне із випробуваною системою.

— Звичайний

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

— CodesInChaos

Оригінальне рішення, засноване на датах файлів, дуже просте, воно не потребує додаткових файлів для зберігання хеш-кодів, і воно працювало надзвичайно добре протягом декількох десятиліть. Чому хтось повинен замінити добре працююче рішення на більш складне? Більше того, AFAIK більшість систем VCS присвоює перевіреним файлам "дату оформлення замовлення", тому змінені файли правильно спричинить перекомпіляцію без "очищення".

— Док Браун

@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 не хешує кожен файл кожного разу, коли ви запускаєте git statusбудь-який. Також каси VCS не встановлюють час модифікації файлу на початковий авторський час. Резервне відновлення буде, якщо ви подбаєте про це. Вся причина, чому файлові системи мають часові позначки, - це для таких випадків використання.

Зазвичай розробник працює, make cleanколи залежність, яку безпосередньо не відстежують Makefile, змінюється. Як не дивно, це зазвичай включає сам Makefile. Зазвичай він включає також версії компілятора. Залежно від того, наскільки добре написаний ваш Makefile, він може включати зовнішні версії бібліотеки.

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

— Карл Білефельдт
джерело

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

— Асад Саєдюддін

Кілька пунктів про хеші та часові позначки в складальних системах:

Під час огляду файлу часова марка повинна бути оновлена до поточного часу, що ініціює відновлення. Те, що описує ваш колега, зазвичай не є збоєм у режимі відміток часу.
Часові позначки незначно швидші, ніж хеши. Система міток часу повинна перевіряти лише часову марку, тоді як хеш-система повинна перевіряти часову марку, а потім потенційно хеш.
Марка створена таким, щоб вона була легкою та самодостатньою. Для подолання (2) системи на основі хешей зазвичай виконують фоновий процес перевірки хешей (наприклад, Watchman Facebook ). Це суперечить цілям дизайну (та історії) Make.
Хеші запобігають непотрібному перебудові, коли змінена часова марка, але не вміст. Часто це компенсує витрати на обчислення хешу.
Хеші дозволяють обмінюватися кешами артефактів між проектами та по мережі. Знову ж таки, це більш ніж компенсує витрати на обчислення хешей.
Сучасні системи побудови на основі хешу включають Bazel (Google) та Buck (Facebook).
Більшість розробників повинні подумати про використання хеш-системи, оскільки вони не мають тих самих вимог, що і вимоги, згідно з якими Make був розроблений.

— sdgfsdh
джерело