Mengapa build tambahan di "make" tidak menggunakan algoritma hashing?

Saya seorang pemula makedan saya bertanya-tanya kapan harus menggunakannya make clean.

Salah satu kolega memberi tahu saya bahwa penambahan build makedidasarkan pada stempel waktu file. Jadi, jika Anda checkout versi lama file di VCS Anda, itu akan memiliki cap waktu "lama" dan itu akan ditandai sebagai "tidak perlu mengkompilasi ulang file ini". Kemudian, file itu tidak akan dimasukkan dalam build berikutnya.
Menurut kolega yang sama, itu akan menjadi alasan untuk menggunakannya make clean.

Ngomong-ngomong, saya kira-kira mendapat jawaban untuk pertanyaan "kapan harus menggunakan make clean" dari pertanyaan StackExchange lainnya tetapi pertanyaan saya yang lain adalah:

Mengapa membangun tambahan menggunakan makemengandalkan stempel waktu file dan bukan pada SHA-1 misalnya? Git, misalnya, menunjukkan bahwa kita dapat berhasil menentukan apakah suatu file diubah menggunakan SHA-1.
Apakah itu untuk masalah kecepatan?

builds make

— filaton
sumber

makediciptakan pada 70-an. SHA-1 dibuat pada tahun 90-an. Git dibuat pada tahun 00-an. Hal terakhir yang Anda inginkan adalah beberapa bangunan tidak jelas yang bekerja selama 30 tahun tiba-tiba gagal karena seseorang memutuskan untuk menjadi modern dengan sistem yang telah dicoba dan diuji.

— Biasa

Hashing file sepanjang waktu lambat. Saya pikir git juga menggunakan metadata filesystem untuk mengoptimalkan pemeriksaan untuk file yang diubah.

— CodesInChaos

Solusi asli berdasarkan tanggal file sangat sederhana, tidak memerlukan file tambahan untuk menyimpan kode hash, dan itu bekerja sangat baik selama beberapa dekade. Mengapa seseorang harus mengganti solusi yang berfungsi baik dengan yang lebih rumit? Selain itu, AFAIK kebanyakan sistem VCS menetapkan file yang diperiksa sebagai "tanggal checkout", sehingga file yang diubah akan menyebabkan kompilasi ulang tanpa "make clean".

— Doc Brown

@Ordous: Lucu, tetapi apakah ini relevan di sini? Perangkat lunak tidak berkarat; itu memberi karena seseorang mengubah sesuatu di lingkungan sekitarnya. Kecuali jika tidak, dalam hal ini masih harus bekerja.

— Robert Harvey

@RobertHarvey Tentu saja! Tentu, jika Anda tidak memperbarui Anda makemaka perangkat lunak Anda tidak akan rusak, namun makeberusaha untuk memiliki kompatibilitas ke belakang dalam versi baru. Mengubah perilaku inti tanpa alasan yang jelas merupakan kebalikan dari itu. Dan tanggal menunjukkan mengapa itu awalnya tidak dibuat untuk menggunakan SHA-1, atau mengapa itu tidak mudah untuk retrofit ketika sudah tersedia ( makesudah puluhan tahun saat itu).

— Biasa

Jawaban:

Masalah yang jelas (dan bisa dibilang dangkal) adalah bahwa sistem build harus menyimpan catatan hash dari file yang digunakan untuk build terakhir. Meskipun masalah ini dapat dipecahkan, akan membutuhkan penyimpanan samping ketika informasi cap waktu sudah ada dalam sistem file.

Lebih serius lagi, hash tidak akan menyampaikan semantik yang sama. Jika Anda tahu bahwa file T dibangun dari dependensi D dengan hash H ₁ dan kemudian mengetahui bahwa D sekarang hash ke H ₂ , haruskah Anda membangun kembali T ? Mungkin ya, tapi bisa juga bahwa H ₂ sebenarnya mengacu pada suatu tua versi dari file. Stempel waktu menentukan pemesanan sementara hash hanya dapat dibandingkan untuk kesetaraan.

Fitur yang didukung oleh cap waktu adalah Anda cukup memperbarui cap waktu (misalnya, menggunakan utilitas baris perintah POSIX touch) untuk mengelabui makebahwa ketergantungan telah berubah atau - lebih menariknya - target lebih baru dari yang sebenarnya. Sambil bermain dengan ini adalah kesempatan bagus untuk menembak diri sendiri, itu berguna dari waktu ke waktu. Dalam sistem berbasis hash, Anda akan memerlukan dukungan dari sistem build itu sendiri untuk memperbarui basis data internal hash yang digunakan untuk build terakhir tanpa benar-benar membangun apa pun.

Sementara argumen pasti dapat dibuat untuk menggunakan hash dari waktu-perangko, poin saya adalah bahwa mereka bukan solusi yang lebih baik untuk mencapai tujuan yang sama tetapi solusi yang berbeda untuk mencapai tujuan yang berbeda. Mana dari tujuan-tujuan ini yang lebih diinginkan mungkin terbuka untuk diperdebatkan.

— 5gon12eder
sumber

Meskipun semantik berbeda antara hash dan cap waktu, biasanya tidak relevan dalam hal ini karena Anda kemungkinan besar menginginkan build berdasarkan file saat ini, berapapun usianya.

— axl

Sebagian besar yang Anda katakan benar. Namun sistem pembangunan yang diimplementasikan dengan baik yang menggunakan hash seperti Google blaze / bazel (versi internal blaze, yang open source adalah bazel) mengalahkan ketukan dari sistem timestamped seperti Make. Yang mengatakan, Anda harus melakukan banyak upaya untuk membangun berulang sehingga selalu aman untuk menggunakan artefak membangun lama daripada membangun kembali.

— btilly

Pemetaan di sini tidak banyak ke satu, itu satu ke satu. Jika Dsekarang hash untuk H2, dan Anda tidak memiliki beberapa output T2dibangun dari D@H2, Anda perlu memproduksi dan menyimpannya. Setelah itu, terlepas dari apa urutan Dberalih antara H1dan H2menyatakan, Anda akan dapat menggunakan output cache.

— Asad Saeeduddin

Hashing seluruh proyek sangat lambat. Anda harus membaca setiap byte dari setiap file. Git tidak hash setiap file setiap kali Anda menjalankan yang git statusbaik. Checkout VCS juga tidak biasanya mengatur waktu modifikasi file ke waktu asli yang dibuat. Pemulihan cadangan akan terjadi, jika Anda berhati-hati melakukannya. Seluruh alasan filesystem memiliki cap waktu adalah untuk kasus-kasus penggunaan seperti ini.

Pengembang biasanya berjalan make cleanketika dependensi tidak dilacak secara langsung oleh Makefile berubah. Ironisnya, ini biasanya termasuk Makefile itu sendiri. Biasanya juga termasuk versi kompiler. Bergantung pada seberapa baik Makefile Anda ditulis, itu bisa termasuk versi pustaka eksternal.

Ini adalah hal-hal yang cenderung diperbarui ketika Anda melakukan pembaruan kontrol versi, sehingga sebagian besar pengembang hanya terbiasa menjalankan make cleanpada saat yang sama, sehingga Anda tahu Anda mulai dari yang bersih. Anda dapat pergi tanpa sering melakukannya, tetapi sangat sulit untuk memprediksi waktu yang tidak dapat Anda lakukan.

— Karl Bielefeldt
sumber

Anda dapat menggunakan sistem file seperti ZFS di mana biaya hashing diamortisasi seiring waktu ketika file sedang dimodifikasi, daripada dibayar sekaligus ketika Anda membangun.

— Asad Saeeduddin

Beberapa poin tentang hash vs cap waktu di sistem bangun:

Saat Anda checkout file, stempel waktu harus diperbarui ke waktu saat ini, yang memicu pembangunan kembali. Apa yang dijelaskan oleh kolega Anda biasanya bukan mode kegagalan sistem cap waktu.
Cap waktu sedikit lebih cepat dari hash. Sistem timestamp hanya perlu memeriksa timestamp, sedangkan sistem hash harus memeriksa cap waktu dan kemudian berpotensi hash.
Make dirancang agar ringan dan mandiri. Untuk mengatasi (2), sistem berbasis hashe biasanya akan menjalankan proses latar belakang untuk memeriksa hash (mis. Watchman Facebook ). Ini bertentangan dengan tujuan desain (dan sejarah) Make.
Hash mencegah pembangunan kembali yang tidak perlu ketika stempel waktu telah berubah tetapi bukan isinya. Seringkali, ini mengimbangi biaya komputasi hash.
Hash memungkinkan cache artefak untuk dibagikan di seluruh proyek dan melalui jaringan. Sekali lagi, ini lebih dari mengimbangi biaya komputasi hash.
Sistem pembangunan berbasis hash modern termasuk Bazel (Google) dan Buck (Facebook).
Sebagian besar pengembang harus mempertimbangkan untuk menggunakan sistem berbasis hash, karena mereka tidak memiliki persyaratan yang sama seperti yang dibuat oleh Make.

— sdgfsdh
sumber