"make"의 증분 빌드가 해싱 알고리즘을 사용하지 않는 이유는 무엇입니까?

나는 초보자이며 make언제 사용 해야하는지 궁금합니다 make clean.

한 동료는 증분 빌드가 make파일 타임 스탬프를 기반으로 한다고 말했습니다 . 따라서 VCS에서 이전 버전의 파일을 체크 아웃하면 "오래된"타임 스탬프가 표시되고 "이 파일을 다시 컴파일 할 필요가 없습니다"로 표시됩니다. 그런 다음 해당 파일은 다음 빌드에 포함되지 않습니다.
같은 동료에 따르면 사용하는 이유가 될 것 make clean입니다.

어쨌든 make clean다른 StackExchange 질문에서 " 사용할 때"라는 질문에 대한 답변을 대략 얻었 지만 다른 질문은 다음과 같습니다.

make예를 들어 SHA-1이 아닌 파일 타임 스탬프에 의존 하여 증분 빌드를 사용 하는 이유는 무엇 입니까? 예를 들어 Git은 SHA-1을 사용하여 파일이 수정되었는지 여부를 성공적으로 확인할 수 있음을 보여줍니다.
속도 문제입니까?

builds make

— 필라 톤
소스

make70 년대에 만들어졌습니다. SHA-1은 90 년대에 만들어졌습니다. Git은 00에서 만들어졌습니다. 마지막으로 원하는 것은 30 년 동안 작동해온 모호한 빌드가 누군가 실패하고 테스트 한 시스템으로 현대화하기로 결정했기 때문에 갑자기 실패하는 것입니다.

— Ordous

파일을 항상 해싱하는 것은 느립니다. git은 파일 시스템 메타 데이터를 사용하여 변경된 파일 검사를 최적화한다고 생각합니다.

— 코드 InChaos 2016 년

파일 날짜를 기반으로 한 원래 솔루션은 매우 간단하며 해시 코드를 저장하기 위해 추가 파일이 필요하지 않으며 수십 년 동안 놀랍도록 잘 작동했습니다. 잘 작동하는 솔루션을 더 복잡한 솔루션으로 대체해야하는 이유는 무엇입니까? 또한 AFAIK 대부분의 VCS 시스템은 체크 아웃 된 파일에 "체크 아웃 날짜"를 할당하므로 변경된 파일은 "make clean"없이 재 컴파일을 올바르게 수행합니다.

— Doc Brown

@Ordous : 재미 있지만 여기에 관련이 있습니까? 소프트웨어가 녹슬지 않습니다. 누군가가 주변 환경에서 무언가를 바꿨 기 때문에 그것을 제공합니다. 그들이하지 않은 경우, 여전히 작동합니다.

— Robert Harvey

@RobertHarvey 물론입니다! 물론, 업데이트하지 않으면 make소프트웨어가 손상되지 않지만 make새 버전에서 이전 버전과의 호환성을 얻으려고 노력합니다. 정당한 이유없이 핵심 행동을 바꾸는 것은 그 반대입니다. 그리고 날짜는 왜 SHA-1을 처음 사용하지 않았는지 또는 사용 가능 해졌을 때 개조하기가 쉽지 않은 이유를 보여줍니다 ( make이미 수십 년 전).

— Ordous

답변:

명백한 (그리고 명백하게 피상적 인) 문제는 빌드 시스템이 마지막 빌드에 사용 된 파일의 해시를 기록해야한다는 것입니다. 이 문제는 확실히 해결 될 수 있지만 타임 스탬프 정보가 파일 시스템에 이미 존재하는 경우 사이드 스토리지가 필요합니다.

더 심각하게도 해시는 동일한 의미를 전달하지 않습니다. 파일 T 가 해시 H _1을 사용 하여 종속성 D 에서 빌드 된 것을 알고 D가 이제 H _2로 해시되는 것을 발견하면 T 를 다시 빌드해야 합니까? 아마도 그렇습니다. 그러나 H _2가 실제로 파일 의 이전 버전을 가리킬 수도 있습니다 . 타임 스탬프는 순서를 정의하지만 해시는 평등에 대해서만 비교할 수 있습니다.

타임 스탬프가 지원하는 기능은 단순히 타임 스탬프를 업데이트 (예 : POSIX 명령 줄 유틸리티 사용 touch) make하여 종속성이 변경되었거나 더 흥미롭게 대상이 더 최근에 있다고 생각 하도록 속일 수 있다는 것입니다. 실제로보다. 이것을 가지고 노는 것은 발로 자신을 쏠 수있는 좋은 기회이지만, 때때로 유용합니다. 해시 기반 시스템에서는 실제로 빌드하지 않고 마지막 빌드에 사용 된 내부 해시 데이터베이스를 업데이트하려면 빌드 시스템 자체의 지원이 필요합니다.

타임 스탬프에 대해 해시를 사용하는 것에 대해서는 분명히 논쟁의 여지가 있지만, 내 목표는 그것들이 동일한 목표를 달성하기위한 더 나은 솔루션이 아니라 다른 목표를 달성하기위한 다른 솔루션이라는 것입니다. 이러한 목표 중 어느 것이 더 바람직한 지 토론 할 수 있습니다.

— 5gon12eder
소스

해시와 타임 스탬프 간에는 의미가 다르지만,이 경우 나이에 관계없이 현재 파일을 기반으로 빌드를 원할 가능성이 높으므로이 경우 일반적으로 관련이 없습니다.

— axl

당신이하는 말의 대부분은 맞습니다. 그러나 Google blaze / bazel (내부 버전의 blaze, 오픈 소스는 bazel)과 같은 해시를 사용하는 잘 구현 된 빌드 시스템은 Make와 같이 타임 스탬프가 지정된 시스템에서 바지를 이깁니다. 즉, 반복 가능한 빌드 에는 많은 노력을 기울여야하므로 다시 빌드하는 대신 이전 빌드 아티팩트를 사용하는 것이 항상 안전합니다.

— btilly

여기의 매핑은 일대일이 아니며 일대일입니다. 경우 D지금에 해시 H2, 당신은 어떤 출력이없는 T2에서 내장 D@H2, 당신은 생성하고 저장해야합니다. 그 후 관계없이 어떤 순서로하는 D사이에 전환 H1및 H2캐시 된 출력을 사용할 수있게됩니다에 상태.

— Asad Saeeduddin

전체 프로젝트를 해시하는 것은 매우 느립니다. 모든 단일 파일의 모든 단일 바이트를 읽어야합니다. Git은 매번 파일을 실행할 때마다 모든 파일을 해시하지는 않습니다 git status. VCS 체크 아웃은 일반적으로 파일의 수정 시간을 원래 작성된 시간으로 설정하지도 않습니다. 주의하여 백업 복원을 수행하십시오. 파일 시스템에 타임 스탬프가있는 전체 이유는 이와 같은 사용 사례를위한 것입니다.

개발자는 일반적으로 make cleanMakefile이 직접 추적하지 않는 종속성이 변경 될 때 실행 됩니다. 아이러니하게도 여기에는 보통 Makefile 자체가 포함됩니다. 일반적으로 컴파일러 버전도 포함됩니다. Makefile이 얼마나 잘 작성되었는지에 따라 외부 라이브러리 버전이 포함될 수 있습니다.

이것들은 버전 관리 업데이트를 할 때 업데이트되는 경향이 있으므로 대부분의 개발자 make clean는 동시에 실행 습관을 가지 므로 깨끗한 슬레이트에서 시작한다는 것을 알고 있습니다. 많은 시간을 들이지 않고 도망 갈 수는 있지만, 할 수없는 시간을 예측하기는 정말 어렵습니다.

— 칼 빌레펠트
소스

ZFS와 같은 파일 시스템을 사용하면 빌드 할 때 한 번에 모두 지불하지 않고 파일을 수정하는 시간에 해싱 비용이 상각됩니다.

— Asad Saeeduddin

빌드 시스템의 해시와 타임 스탬프에 대한 몇 가지 사항 :

파일을 체크 아웃하면 타임 스탬프가 현재 시간으로 업데이트되어 재 구축을 트리거합니다. 동료가 설명하는 것은 일반적으로 타임 스탬프 시스템의 고장 모드가 아닙니다.
타임 스탬프는 해시보다 약간 빠릅니다. 타임 스탬프 시스템은 타임 스탬프 만 확인하면되지만 해시 시스템은 타임 스탬프를 확인한 다음 잠재적으로 해시를 확인해야합니다.
Make는 가볍고 독립적으로 설계되었습니다. (2)를 극복하기 위해, hashe 기반 시스템은 일반적으로 해시 확인을위한 백그라운드 프로세스를 실행합니다 (예 : Facebook의 Watchman ). 이것은 Make의 디자인 목표와 역사에 반합니다.
타임 스탬프는 변경되었지만 내용은 변경되지 않은 경우 불필요한 재 빌드를 방지합니다. 종종 이것은 해시 계산 비용을 상쇄합니다.
해시는 아티팩트 캐시를 프로젝트와 네트워크를 통해 공유 할 수 있도록합니다. 다시 말하지만, 이것은 해시 컴퓨팅 비용을 상쇄합니다.
최신 해시 기반 빌드 시스템에는 Bazel (Google) 및 Buck (Facebook)이 포함됩니다.
대부분의 개발자는 Make가 설계 한 요구 사항과 동일한 요구 사항이 없기 때문에 해시 기반 시스템 사용을 고려해야합니다.

— sdgfsdh
소스