Tại sao các bản dựng gia tăng trong hệ thống làm cho các chế độ băm không sử dụng thuật toán băm?

Tôi là người mới bắt đầu makevà tôi đang tự hỏi khi nào nên sử dụng make clean.

Một đồng nghiệp nói với tôi rằng các bản dựng tăng dần makedựa trên dấu thời gian của tệp. Vì vậy, nếu bạn kiểm tra phiên bản cũ của tệp trong VCS, nó sẽ có dấu thời gian "cũ" và nó sẽ được đánh dấu là "không cần biên dịch lại tệp này". Sau đó, tập tin đó sẽ không được bao gồm trong bản dựng tiếp theo.
Theo đồng nghiệp đó, nó sẽ là một lý do để sử dụng make clean.

Dù sao, tôi gần như đã có câu trả lời cho câu hỏi "khi nào nên sử dụng make clean" từ các câu hỏi StackExchange khác nhưng câu hỏi khác của tôi là:

Tại sao các bản dựng gia tăng sử dụng makedựa vào dấu thời gian của tệp chứ không phải trên SHA-1 chẳng hạn? Chẳng hạn, Git cho thấy rằng chúng ta có thể xác định thành công nếu một tệp đã được sửa đổi bằng SHA-1.
Có phải cho vấn đề tốc độ?

builds make

— filaton
nguồn

makeđược tạo ra vào những năm 70 SHA-1 được tạo ra vào những năm 90. Git đã được tạo ra trong 00. Điều cuối cùng bạn muốn là đối với một số bản dựng tối nghĩa đã hoạt động trong 30 năm đột nhiên thất bại vì ai đó đã quyết định đi tất cả hiện đại với một hệ thống đã được thử nghiệm và thử nghiệm.

— Thông thường

Băm các tập tin tất cả các thời gian là chậm. Tôi nghĩ git cũng sử dụng siêu dữ liệu hệ thống tập tin để tối ưu hóa việc kiểm tra các tập tin đã thay đổi.

— CodeInChaos

Giải pháp ban đầu dựa trên ngày tệp rất đơn giản, nó không cần bất kỳ tệp bổ sung nào để lưu trữ mã băm và nó hoạt động rất tốt trong nhiều thập kỷ. Tại sao một người nào đó nên thay thế một giải pháp làm việc tốt bằng một giải pháp phức tạp hơn? Ngoài ra, hầu hết các hệ thống VCS của AFAIK đều gán các tệp đã kiểm tra là "ngày thanh toán", do đó, các tệp bị thay đổi sẽ gây ra việc biên dịch lại một cách chính xác mà không "làm sạch".

— Doc Brown

@Ordous: gây cười, nhưng nó có liên quan ở đây không? Phần mềm không bị rỉ sét; nó đưa ra bởi vì ai đó đã thay đổi một cái gì đó trong môi trường xung quanh. Trừ khi họ không làm, trong trường hợp đó nó vẫn hoạt động.

— Robert Harvey

@RobertHarvey Tất nhiên rồi! Chắc chắn, nếu bạn không cập nhật makethì phần mềm của bạn sẽ không bị hỏng, tuy nhiên, makenỗ lực để có khả năng tương thích ngược trong các phiên bản mới. Thay đổi hành vi cốt lõi không có lý do chính đáng là điều ngược lại với điều đó. Và ngày tháng cho thấy lý do tại sao ban đầu nó không được sử dụng để sử dụng SHA-1, hoặc tại sao nó không dễ dàng trang bị thêm khi nó trở nên có sẵn ( makeđã có hàng thập kỷ trước đó).

— Thường

Câu trả lời:

Một vấn đề rõ ràng (và có thể nói là hời hợt) là hệ thống xây dựng sẽ phải lưu giữ các bản băm của các tệp được sử dụng cho bản dựng cuối cùng. Mặc dù vấn đề này chắc chắn có thể được giải quyết, nó sẽ yêu cầu lưu trữ bên khi thông tin về dấu thời gian đã có trong hệ thống tệp.

Nghiêm trọng hơn, mặc dù, hàm băm sẽ không truyền đạt cùng một ngữ nghĩa. Nếu bạn biết rằng tệp T được xây dựng từ phụ thuộc D với hàm băm H ₁ và sau đó phát hiện ra rằng D bây giờ băm đến H ₂ , bạn có nên xây dựng lại T không? Có lẽ là có, nhưng cũng có thể là H ₂ thực sự đề cập đến một phiên bản cũ hơn của tệp. Dấu thời gian xác định một thứ tự trong khi băm chỉ có thể so sánh cho sự bình đẳng.

Một tính năng hỗ trợ tem thời gian là bạn có thể chỉ cần cập nhật dấu thời gian (ví dụ: sử dụng tiện ích dòng lệnh POSIX touch) để đánh lừa makerằng một sự phụ thuộc đã thay đổi hoặc - thú vị hơn - một mục tiêu gần đây hơn hơn thực tế là như vậy Mặc dù chơi với điều này là một cơ hội tuyệt vời để bắn vào chân bạn, nó rất hữu ích theo thời gian. Trong một hệ thống dựa trên hàm băm, bạn sẽ cần sự hỗ trợ từ chính hệ thống xây dựng để cập nhật cơ sở dữ liệu nội dung băm được sử dụng cho bản dựng cuối cùng mà không thực sự xây dựng bất cứ thứ gì.

Mặc dù một lập luận chắc chắn có thể được đưa ra để sử dụng băm theo dấu thời gian, quan điểm của tôi là chúng không phải là giải pháp tốt hơn để đạt được cùng một mục tiêu mà là một giải pháp khác để đạt được mục tiêu khác. Mục tiêu nào trong số những mục tiêu này là mong muốn hơn có thể được mở để tranh luận.

— 5gon12eder
nguồn

Mặc dù ngữ nghĩa khác nhau giữa băm và dấu thời gian, nhưng thông thường trong trường hợp này không liên quan vì bạn rất có thể muốn xây dựng dựa trên các tệp hiện tại, bất kể tuổi của chúng.

— axl

Hầu hết những gì bạn nói là chính xác. Tuy nhiên, một hệ thống xây dựng được triển khai tốt sử dụng các giá trị băm như Google blaze / bazel (phiên bản nội bộ của blaze, mã nguồn mở là bazel) đánh bật quần khỏi hệ thống được đánh dấu thời gian như Make. Điều đó nói rằng, bạn phải nỗ lực rất nhiều vào các bản dựng lặp lại để luôn an toàn khi sử dụng các tạo tác xây dựng cũ thay vì xây dựng lại.

— btilly

Ánh xạ ở đây không nhiều đến một, nó là một. Nếu Dbây giờ băm đến H2và bạn không có một số đầu ra T2được xây dựng từ đó D@H2, bạn cần sản xuất và lưu trữ nó. Sau đó, bất kể thứ tự nào Dchuyển đổi giữa H1và H2trạng thái trong, bạn sẽ có thể sử dụng đầu ra được lưu trữ.

— Asad Saeeduddin

Băm toàn bộ một dự án là rất chậm. Bạn phải đọc từng byte của mỗi tệp. Git không băm mọi tệp mỗi khi bạn chạy một git statustrong hai. Kiểm tra VCS cũng không đặt thời gian sửa đổi tệp thành thời gian tác giả ban đầu. Một khôi phục sao lưu sẽ, nếu bạn cẩn thận để làm như vậy. Toàn bộ lý do hệ thống tập tin có dấu thời gian là dành cho các trường hợp sử dụng như thế này.

Một nhà phát triển thường chạy make cleankhi một phụ thuộc không được theo dõi trực tiếp bởi các thay đổi Makefile. Trớ trêu thay, điều này thường bao gồm chính Makefile. Nó cũng thường bao gồm các phiên bản trình biên dịch. Tùy thuộc vào mức độ Makefile của bạn được viết, nó có thể bao gồm các phiên bản thư viện bên ngoài.

Đây là những thứ có xu hướng được cập nhật khi bạn thực hiện cập nhật kiểm soát phiên bản, vì vậy hầu hết các nhà phát triển chỉ có thói quen chạy make cleancùng một lúc, vì vậy bạn biết rằng bạn đang bắt đầu từ một bảng xếp hạng sạch sẽ. Bạn có thể thoát ra mà không làm điều đó nhiều thời gian, nhưng thực sự rất khó để dự đoán thời gian bạn không thể.

— Karl Bielefeldt
nguồn

Bạn có thể sử dụng các hệ thống tệp như ZFS trong đó chi phí băm được khấu hao theo thời gian khi các tệp đang được sửa đổi, thay vì được trả tất cả cùng một lúc khi bạn xây dựng.

— Asad Saeeduddin

Một vài điểm về băm so với dấu thời gian trong các hệ thống xây dựng:

Khi bạn kiểm tra một tập tin, dấu thời gian sẽ được cập nhật vào thời điểm hiện tại, điều này sẽ kích hoạt việc xây dựng lại. Những gì đồng nghiệp của bạn mô tả thường không phải là chế độ thất bại của các hệ thống dấu thời gian.
Dấu thời gian nhanh hơn một chút so với giá trị băm. Một hệ thống dấu thời gian chỉ phải kiểm tra dấu thời gian, trong khi đó hệ thống băm phải kiểm tra dấu thời gian và sau đó có khả năng băm.
Make được thiết kế gọn nhẹ và khép kín. Để khắc phục (2), các hệ thống dựa trên hàm băm thường sẽ chạy quy trình nền để kiểm tra giá trị băm (ví dụ: Watchman của Facebook ). Điều này phản lại các mục tiêu thiết kế (và lịch sử) của Make.
Băm ngăn chặn việc xây dựng lại không cần thiết khi dấu thời gian đã thay đổi nhưng không phải nội dung. Thông thường, điều này bù đắp chi phí tính toán hàm băm.
Băm cho phép bộ nhớ nhân tạo được chia sẻ trên các dự án và qua mạng. Một lần nữa, điều này nhiều hơn bù đắp chi phí băm máy tính.
Các hệ thống xây dựng dựa trên hàm băm hiện đại bao gồm Bazel (Google) và Buck (Facebook).
Hầu hết các nhà phát triển nên cân nhắc sử dụng hệ thống dựa trên hàm băm, vì họ không có các yêu cầu giống như các yêu cầu mà Make được thiết kế.

— sdgfsdh
nguồn