종속 항목

빌드 또는 실행 시간에 AB가 필요한 경우 타겟 A는 타겟 B종속됩니다. 종속 관계는 타겟에 방향성 비순환 그래프 (DAG)를 유도하며 이를 종속 항목 그래프라고 합니다.

타겟의 직접 종속 항목은 종속 항목 그래프에서 길이가 1인 경로 로 연결할 수 있는 다른 타겟입니다. 타겟의 전이적 종속 항목은 그래프를 통해 임의 길이의 경로를 통해 종속되는 타겟입니다.

실제로 빌드 컨텍스트에는 두 개의 종속 항목 그래프, 즉 그래프 실제 종속 항목 그래프와 선언된 종속 항목 그래프가 있습니다. 대부분의 경우 두 그래프가 매우 유사하므로 이 구분을 할 필요는 없지만 아래 논의에 유용합니다.

실제 종속 항목 및 선언된 종속 항목

타겟 X가 올바르게 빌드되려면 타겟 Y가 있어야 하고 빌드되어야 하며 최신 상태여야 하는 경우 타겟 X는 타겟 Y실제로 종속됩니다. 빌드됨은 생성됨, 처리됨, 컴파일됨, 연결됨, 보관됨, 압축됨, 실행됨 또는 빌드 중에 정기적으로 발생하는 다른 종류의 작업을 의미할 수 있습니다.

타겟 X의 패키지에 X에서 Y로의 종속 항목 가장자리가 있는 경우 타겟 X는 타겟 Y선언된 종속 항목을 갖습니다.

올바른 빌드를 위해서는 실제 종속 항목 그래프 A가 하위 그래프여야 합니다. 선언된 종속 항목 그래프 D의 즉, 직접 연결된 모든 노드 쌍 x --> y AD에서도 직접 연결되어야 합니다. DA과대 근사 라고 할 수 있습니다.

BUILD 파일 작성자는 모든 규칙의 실제 직접 종속 항목을 빌드 시스템에 명시적으로 선언해야 하며 그 이상은 선언해서는 안 됩니다.

이 원칙을 준수하지 않으면 정의되지 않은 동작이 발생합니다. 빌드가 실패할 수 있지만 더 나쁜 것은 빌드가 일부 이전 작업 또는 타겟에 있는 전이적 선언된 종속 항목에 종속될 수 있다는 것입니다. Bazel은 누락된 종속 항목을 확인하고 오류를 보고하지만 이 검사가 모든 경우에 완료될 수는 없습니다.

실행 시간에 A필요 하더라도 간접적으로 가져온 모든 항목을 나열하려고 시도할 필요가 없으며 시도해서도 안 됩니다.

타겟 X를 빌드하는 동안 빌드 도구는 X의 종속 항목의 전체 전이적 클로저를 검사하여 이러한 타겟의 변경사항이 최종 결과에 반영되도록 하고 필요에 따라 중간 항목을 다시 빌드합니다.

종속 항목의 전이적 특성으로 인해 일반적인 실수가 발생합니다. 경우에 따라 한 파일의 코드가 간접 종속 항목(선언된 종속 항목 그래프에서 전이적이지만 직접적인 가장자리가 아님)에서 제공하는 코드를 사용할 수 있습니다. 간접 종속 항목은 BUILD 파일에 표시되지 않습니다. 규칙이 제공업체에 직접 종속되지 않으므로 다음 예시 타임라인과 같이 변경사항을 추적할 방법이 없습니다.

1. 선언된 종속 항목이 실제 종속 항목과 일치함

처음에는 모든 것이 작동합니다. 패키지 a의 코드는 패키지 b의 코드를 사용합니다. 패키지 b의 코드는 패키지 c의 코드를 사용하므로 ac에 전이적으로 종속됩니다.

a/BUILD b/BUILD
rule(
    name = "a",
    srcs = "a.in",
    deps = "//b:b",
)
      
rule(
    name = "b",
    srcs = "b.in",
    deps = "//c:c",
)
      
a / a.in b / b.in
import b;
b.foo();
    
import c;
function foo() {
  c.bar();
}
      
a, b, c를 연결하는 화살표가 있는 선언된 종속 항목 그래프
선언된 종속 항목 그래프
선언된 종속 항목 그래프와 일치하는 실제 종속 항목 그래프(a, b, c를 연결하는 화살표 포함)
실제 종속 항목 그래프

선언된 종속 항목은 실제 종속 항목을 과대 근사합니다. 모든 것이 잘 작동합니다.

2. 선언되지 않은 종속 항목 추가

누군가가 c에 대한 직접적인 실제 종속 항목을 만드는 코드를 a에 추가하지만 빌드 파일 a/BUILD에서 선언하는 것을 잊으면 잠재적인 위험이 발생합니다.

a / a.in  
        import b;
        import c;
        b.foo();
        c.garply();
      
 
a, b, c를 연결하는 화살표가 있는 선언된 종속 항목 그래프
선언된 종속 항목 그래프
a, b, c를 연결하는 화살표가 있는 실제 종속 항목 그래프 이제 화살표가 A와 C도 연결합니다. 선언된 종속 항목 그래프와 일치하지 않습니다.
실제 종속 항목 그래프

선언된 종속 항목은 더 이상 실제 종속 항목을 과대 근사하지 않습니다. 두 그래프의 전이적 클로저가 동일하므로 빌드가 정상적으로 진행될 수 있지만 문제를 마스크합니다. ac에 대한 실제 종속 항목이 있지만 선언되지 않았습니다.

3. 선언된 종속 항목 그래프와 실제 종속 항목 그래프 간의 차이

누군가가 b에 더 이상 종속되지 않도록 c를 리팩터링하면 위험이 드러나고, 본인의 잘못이 아닌데도 a가 실수로 중단됩니다.

  b/BUILD
 
rule(
    name = "b",
    srcs = "b.in",
    deps = "//d:d",
)
      
  b / b.in
 
      import d;
      function foo() {
        d.baz();
      }
      
a와 b를 연결하는 화살표가 있는 선언된 종속 항목 그래프
                  b가 더 이상 c에 연결되지 않아 a의 c 연결이 끊어짐
선언된 종속 항목 그래프
a가 b 및 c에 연결되지만 b가 더 이상 c에 연결되지 않는 실제 종속 항목 그래프
실제 종속 항목 그래프

선언된 종속 항목 그래프는 이제 전이적으로 닫혀 있어도 실제 종속 항목을 과소 근사합니다. 빌드가 실패할 가능성이 높습니다.

2단계에서 도입된 a에서 c로의 실제 종속 항목이 BUILD 파일에서 올바르게 선언되도록 하면 문제를 방지할 수 있습니다.

종속 항목 유형

대부분의 빌드 규칙에는 다양한 종류의 일반 종속 항목을 지정하는 세 가지 속성(srcs, deps, data)이 있습니다. 이에 대한 설명은 아래와 같습니다. 자세한 내용은 모든 규칙에 공통된 속성을 참고하세요.

또한 많은 규칙에는 규칙별 종속 항목 유형( 예: compiler 또는 resources)을 위한 추가 속성이 있습니다. 이러한 속성은 빌드 백과사전에 자세히 설명되어 있습니다.

srcs 종속 항목

규칙 또는 소스 파일을 출력하는 규칙에서 직접 사용하는 파일입니다.

deps 종속 항목

헤더 파일, 기호, 라이브러리, 데이터 등을 제공하는 별도로 컴파일된 모듈을 가리키는 규칙입니다.

data 종속 항목

빌드 타겟이 올바르게 실행되려면 일부 데이터 파일이 필요할 수 있습니다. 이러한 데이터 파일은 소스 코드가 아니며 타겟이 빌드되는 방식에 영향을 주지 않습니다. 예를 들어 단위 테스트는 함수의 출력을 파일의 콘텐츠와 비교할 수 있습니다. 단위 테스트를 빌드할 때는 파일이 필요하지 않지만 테스트를 실행할 때는 파일이 필요합니다. 실행 중에 실행되는 도구에도 동일하게 적용됩니다.

빌드 시스템은 data로 나열된 파일만 사용할 수 있는 격리된 디렉터리에서 테스트를 실행합니다. 따라서 바이너리/라이브러리/테스트를 실행하는 데 일부 파일이 필요한 경우 해당 파일 또는 해당 파일이 포함된 빌드 규칙을 data에서 지정합니다. 예를 들면 다음과 같습니다.

# I need a config file from a directory named env:
java_binary(
    name = "setenv",
    ...
    data = [":env/default_env.txt"],
)

# I need test data from another directory
sh_test(
    name = "regtest",
    srcs = ["regtest.sh"],
    data = [
        "//data:file1.txt",
        "//data:file2.txt",
        ...
    ],
)

이러한 파일은 상대 경로 path/to/data/file을 사용하여 사용할 수 있습니다. 테스트에서는 테스트의 소스 디렉터리 경로와 작업공간 상대 경로를 결합하여 이러한 파일을 참조할 수 있습니다(예: ${TEST_SRCDIR}/workspace/path/to/data/file).

라벨을 사용하여 디렉터리 참조

BUILD 파일을 살펴보면 일부 data 라벨 이 디렉터리를 참조하는 것을 알 수 있습니다. 이러한 라벨은 다음 예와 같이 /. 또는 /로 끝나며, 사용해서는 안 됩니다.

권장하지 않음data = ["//data/regression:unittest/."]

권장하지 않음data = ["testdata/."]

권장하지 않음data = ["testdata/"]

특히 테스트의 경우 디렉터리의 모든 데이터 파일을 테스트에서 사용할 수 있으므로 편리해 보입니다.

하지만 이렇게 하지 않는 것이 좋습니다. 변경 후 올바른 증분 재빌드 (및 테스트 재실행)를 보장하려면 빌드 시스템에서 빌드 (또는 테스트)의 입력인 파일의 전체 집합을 인식해야 합니다. 디렉터리를 지정하면 빌드 시스템은 디렉터리 자체가 변경될 때만 (파일 추가 또는 삭제로 인해) 재빌드를 실행하지만 이러한 변경사항은 포함된 디렉터리에 영향을 주지 않으므로 개별 파일의 수정을 감지할 수 없습니다. 빌드 시스템의 입력으로 디렉터리를 지정하는 대신 명시적으로 또는 glob() 함수를 사용하여 디렉터리에 포함된 파일 집합을 열거해야 합니다. **를 사용하여 glob()를 재귀적으로 실행합니다.

권장data = glob(["testdata/**"])

아쉽게도 디렉터리 라벨을 사용해야 하는 시나리오가 있습니다. 예를 들어 testdata 디렉터리에 이름이 라벨 구문을 준수하지 않는 파일이 포함되어 있는 경우 파일을 명시적으로 열거하거나 glob() 함수를 사용하면 잘못된 라벨 오류가 발생합니다. 이 경우 디렉터리 라벨을 사용해야 하지만 위에 설명된 잘못된 재빌드의 관련 위험에 유의하세요.

디렉터리 라벨을 사용해야 하는 경우 상대 ../ 경로로 상위 패키지를 참조할 수 없다는 점에 유의하세요. 대신 //data/regression:unittest/.과 같은 절대 경로를 사용하세요.

여러 파일을 사용해야 하는 테스트와 같은 외부 규칙은 모든 파일에 대한 종속 항목을 명시적으로 선언해야 합니다. filegroup()을 사용하여 BUILD 파일에서 파일을 함께 그룹화할 수 있습니다.

filegroup(
        name = 'my_data',
        srcs = glob(['my_unittest_data/*'])
)

그런 다음 테스트에서 my_data 라벨을 데이터 종속 항목으로 참조할 수 있습니다.

BUILD 파일 가시성