929 구현이 있습니다. 매일 수천 개의 빌드에 성공적으로 사용되었지만(포크에서) 병합 대상으로 고려되지 않았습니다.

929는 단일 스레드이므로 ccache 또는 다른 솔루션처럼 느릴 수 있습니다. 또한 빌드 정의를 변경할 필요가 없도록 이것이 명령줄 플래그여야 한다고 생각합니다.

해싱이 모든 규칙에 적용되므로 명령줄 플래그가 될 수 없습니다(또는 적어도 해서는 안 됨). 예를 들어 링크 규칙의 모든 입력을 해싱하는 것은 비용이 많이 들기 때문에 바람직하지 않지만 소스 파일과 알려진 종속성은 좋은 후보입니다. 이러한 구분을 위해서는 빌드 설명의 일부여야 합니다. 또한 이 기능을 사용하려면 항상 플래그를 일관되게 사용해야 합니다. 가끔이 아닙니다.

단일 스레드 인수에 응답: 예, 단일 스레드 루프에 명령을 추가합니다. 실제로는 단일 스레드가 처리할 수 있는 것보다 더 많은 작업을 수행하는 경우에만 중요합니다(즉, 한 스레드가 처리할 수 있는 것보다 더 많은 규칙이 완료됨(depslog+hashlog+...)). 그래야만 해싱이 아프다. 그렇지 않으면 단일 스레드 루프가 어쨌든 작업이 완료될 때까지 기다립니다. -j1000 실험을 해도 해싱으로 바쁜 닌자를 본 적이 없습니다. (그리고 빠른 마무리 규칙의 경우 해싱은 어쨌든 안전한 시간에 흥미롭지 않습니다.)

또한 고려하십시오: murmur 해시를 사용한 해시는 상당히 빠르며 큰 소스 파일도 해시하는 데 몇 밀리초만 걸립니다. 또한 해싱은 컴파일러에서 소스 파일(및 종속성)을 확인한 직후에 발생합니다. 따라서 일반적으로 파일 시스템 캐시에서 읽습니다.
(실행된 규칙과 병행하여) 빌드 중에 해싱이 발생하므로 일반적으로 전체 빌드 시간은 측정 가능한 영향을 받지 않습니다.

마지막으로 #929의 구현은 옵트인이며 기능을 사용하지 않는 사람들을 위해 무료로 제공됩니다(if-문 제외).

예를 들어 링크 규칙의 모든 입력을 해싱하는 것은 비용이 많이 들기 때문에 바람직하지 않지만 소스 파일과 알려진 종속성은 좋은 후보입니다.

링커에 대한 입력의 해싱은 종종 연결을 완전히 건너뛸 수 있기 때문에 특히 바람직하다고 말하고 싶습니다(예: 형식 변경 또는 주석이 변경된 경우). 개체 파일의 컴파일이 하나씩 완료되면 빌드가 실행되는 동안 해시 계산이 발생할 수 있습니다(지시한 대로).

너무 느린 경우(예: 큰 정적 라이브러리의 경우) 중간 파일이 아닌 순수한 입력에 대해서만 해시를 구현하는 것을 생각할 수 있습니다. 그렇게 하면 최소한 "Git 분기를 전환하면 전체 재구축이 발생합니다"라는 경우가 해결됩니다.

또한 이 기능을 사용하려면 항상 플래그를 일관되게 사용해야 합니다. 가끔이 아닙니다.

그것이 장점이라고 말하고 싶습니다. 단일 지점에서 작업하고 있고 빠르게 반복하고 싶다면 해시를 사용하지 않을 것입니다. 다른 기능 분기를 비교하는 경우 해시를 사용합니다.

또한 이 기능을 사용하려면 항상 플래그를 일관되게 사용해야 합니다. 가끔이 아닙니다.

그것이 장점이라고 말하고 싶습니다. 단일 지점에서 작업하고 있고 빠르게 반복하고 싶다면 해시를 사용하지 않을 것입니다. 다른 기능 분기를 비교하는 경우 해시를 사용합니다.

그러나 비해싱에서 해싱으로 전환하는 방법이 필요합니다. 즉, 파일의 현재 상태를 해시해야 하므로 다음 재구축에서 해시를 사용할 수 있습니다(아마도 존재하지 않거나 깃발을 통과하지 못한 경우 날짜).

해시는 여전히 타임스탬프를 먼저 사용하므로 타임스탬프가 일치하면 해시를 비교할 필요가 없습니다. 이는 처음 몇 개의 빌드가 일부 파일을 불필요하게 다시 컴파일할 수 있지만 자주 발생하지 않아야 함을 의미합니다(대부분의 경우 타임스탬프 휴리스틱이 옳습니다).

또한 직장에서 해싱을 사용하여 큰 성공을 거두었습니다. #929를 기반으로 하지만 https://github.com/moroten/ninja/commits/hashed에서 볼 수 있듯이 많은 패치가 있습니다. 선택한 규칙의 hash_input = 1 는 매우 편리합니다. 내 지점에는 여전히 O(n) O(n^2) stat 이 너무 자주 있는 버그가 있습니다. 버그는 가짜 가장자리와 관련이 있습니다.

한 가지 문제는 가짜 가장자리를 처리하는 방법입니다. 예를 들어 헤더 파일을 그룹화하기 위해 가짜 가장자리를 사용합니다. 따라서 내 구현은 가짜 가장자리를 통해 재귀적으로 반복됩니다. 이것은 #1021의 버그와도 관련이 있습니다.

또 다른 생각은 해싱을 닌자의 일급 멤버로 만드는 것입니다. 즉, 해시를 빌드 로그로 옮기는 것입니다. SHA256을 사용하는 것은 Bazel의 원격 실행 API에 대한 지원을 추가하는 한 단계가 될 것입니다. C++ 구현은 https://gitlab.com/bloomberg/recc/에서 찾을 수 있습니다. 꽤 좋지 않을까요?

불행히도 가짜 가장자리에 대한 의미 체계를 분류하면 이전 버전과의 호환성이 깨질 수 있습니다.

한편 저는 Chromium에서 분기를 전환하는 사용 사례에 대한 솔루션을 구성했습니다(특히 고통스럽습니다). 내가 사용하는 작은 Go 프로그램과 스크립트는 여기: https://github.com/bromite/mtool

Chromium에서 작동하는 경우 사용 사례에 자유롭게 적용할 수 있습니다. 소규모 빌드 프로젝트에서도 작동할 것입니다(내 실행에는 무시할 수 있는 시간이 걸립니다). 유일한 단점은 내가 게시한 스크립트를 있는 그대로 사용하면 각 git 저장소 상위 디렉토리에 .mtool 파일이 흩어지지만 전역 gitignore 로는 치료할 수 없다는 것입니다.

해싱 요구 사항에 대해 git ls-files --stage 출력을 사용한다는 점은 흥미롭습니다. 빌드가 해당 파일에 의존하는 경우 인덱스되지 않은 파일도 해시하도록 git에 요청하는 것이 가능하지만 덜 효율적입니다.

기능 측면에서 여기에서 논의되는 기능을 구현하기 위해 닌자는 내부적으로(git에 의존하지 않고) 유사한 성능 결과로 동일한 작업을 수행할 수 있을 것으로 예상합니다.

빠른 살펴보기 후에 해당 닌자 패치는 입력 파일 외에 컴파일러 명령줄을 해시하지 않는 것 같습니다. 내가 뭔가를 놓치고 있습니까?

명령줄은 이미 ninja에 의해 해시되어 빌드 로그에 저장됩니다.

해시는 여전히 타임스탬프를 먼저 사용하므로 타임스탬프가 일치하면 해시를 비교할 필요가 없습니다. 이는 처음 몇 개의 빌드가 일부 파일을 불필요하게 다시 컴파일할 수 있지만 자주 발생하지 않아야 함을 의미합니다(대부분의 경우 타임스탬프 휴리스틱이 옳습니다).

그것은 매우 잘못된 것입니다. 타임스탬프가 일치 하지 않으면 해시 비교를 생략할 수 있습니다. 빌드 시스템은 종속성이 수정되었다고 가정할 수 있으며 실제로 수정되지 않은 경우(만진 경우) 빌드는 차선책이지만 정확합니다. 그러나 타임스탬프가 일치하면 종속성이 수정되고 타임스탬프가 강제로 재설정되었을 가능성이 있습니다(EDIT: 또는 대상이 터치되어 종속성보다 최신 상태가 됨). 해시를 비교하여 이중 확인하지 않으면 잘못된 빌드가 발생합니다.

Ninja는 타임스탬프가 일치할 때 이미 모든 작업을 가정하고 건너뜁니다. 따라서 귀하의 예에서는 어쨌든 잘못된 빌드가 될 것입니다.

다른 출력을 생성하고 이전 타임스탬프를 유지하는 도구를 알지 못합니다(내 무지로 인해). 왜 그럴까요?

IMHO, 타임스탬프가 일치할 때 해시 검사를 건너뛰는 것은 매우 유효한 최적화입니다.

해시 검사는 Ninja가 이미 제공한 기존 의미를 유지하면서 단순히 "거짓 더러운" 재빌드를 방지합니다.

문제는 false-dirty 재빌드가 아니라 false-clean non-rebuilds입니다. git checkout은 덮어쓰는 모든 항목을 터치합니다. 종속성보다 새로운 대상을 만들 수 있습니다(예, 사람들은 다양한 유효한 이유로 생성된 코드를 커밋합니다). 해시 검사는 이 경우 거짓 청소 비 재구축을 방지합니다.

@rulatir 나는 당신이 말하는 것을 대부분 이해한다고 생각합니다. :) 이것이 Bazel 및 해시 검사를 기반으로 하는 다른 빌드 시스템이 실제로 트리 내 대상 출력에 반대되는 이유 중 하나인 것 같습니다.

그러나 빌드 시스템이 대상이 이전에 알려진 시간보다 최신인지 확인하고 필요한 경우 다시 빌드하면 이 문제가 해결되지 않을까요?

@rulatir 나는 당신이 말하는 것을 대부분 이해한다고 생각합니다. :) 이것이 Bazel 및 해시 검사를 기반으로 하는 다른 빌드 시스템이 실제로 트리 내 대상 출력에 반대되는 이유 중 하나인 것 같습니다.

해시는 파일의 위치에 따라 어떻게 달라지나요?

그러나 빌드 시스템이 대상이 이전에 알려진 시간보다 최신인지 확인하고 필요한 경우 다시 빌드하면 이 문제가 해결되지 않을까요?

타임스탬프 사용의 주요 이점은 "이전에 알려진" 버전 서명을 추적하는 별도의 데이터베이스를 유지 관리할 필요가 없다는 점입니다. 그 혜택을 기꺼이 포기한다면 왜 그 서명이 해시가 아니어야 합니까?