BazelCon 2024 등록이 시작되었습니다

이 페이지는 Cloud Translation API를 통해 번역되었습니다.

외부 종속 항목 다루기

<ph type="x-smartling-placeholder"></ph> 문제 신고 소스 보기 1박 · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

Bazel은 다른 프로젝트의 대상을 사용할 수 있습니다. 이러한 다른 유형의 종속 항목 프로젝트를 외부 종속 항목이라고 합니다.

WORKSPACE 파일 (또는 WORKSPACE.bazel 파일)은 작업공간 디렉터리 Bazel에게 다른 프로젝트를 가져오는 방법을 알려줍니다 소스입니다 이러한 다른 프로젝트는 자체 타겟이 있는 하나 이상의 BUILD 파일을 포함합니다. 다음 위치에 있는 파일 BUILD개 기본 프로젝트는 WORKSPACE 파일

예를 들어 시스템에 두 개의 프로젝트가 있다고 가정해 보겠습니다.

/
  home/
    user/
      project1/
        WORKSPACE
        BUILD
        srcs/
          ...
      project2/
        WORKSPACE
        BUILD
        my-libs/

project1가:foo /home/user/project2/BUILD라는 저장소 이름이 project2을(를) /home/user/project2에서 찾을 수 있습니다. 그런 다음 /home/user/project1/BUILD는 @project2//:foo에 종속될 수 있습니다.

WORKSPACE 파일을 사용하면 사용자가 인터넷에서 다운로드한 파일 시스템일 수 있습니다. BUILD와 동일한 문법을 사용합니다. 있지만 저장소 규칙이라는 다른 규칙 집합을 허용합니다 (때로는 작업공간 규칙이라고도 합니다. Bazel에는 몇 가지 기본 제공 저장소가 함께 제공되며 규칙 및 삽입된 Starlark 저장소 세트 규칙을 참조하세요. 사용자는 커스텀 저장소를 작성할 수도 있습니다. 더 복잡한 동작을 구현할 수 있습니다.

지원되는 외부 종속 항목 유형

다음과 같은 몇 가지 기본적인 유형의 외부 종속 항목을 사용할 수 있습니다.

다른 Bazel 프로젝트에 대한 종속 항목
Bazel 이외의 프로젝트에 대한 종속 항목
외부 패키지 종속 항목

다른 Bazel 프로젝트에 따라 다름

두 번째 Bazel 프로젝트의 대상을 사용하려면 다음 안내를 따르세요. 사용 local_repository님, git_repository 또는 http_archive 로컬 파일 시스템에서 심볼릭 링크로 연결하려면 git 저장소를 참조하거나 나타냅니다.

예를 들어 my-project/ 프로젝트에서 작업하고 있는데 동료의 프로젝트(coworkers-project/)의 대상에 종속됩니다. 모두 Bazel을 사용하므로 동료의 프로젝트를 동료가 정의한 타겟을 사용하여 BUILD 파일. my_project/WORKSPACE에 다음을 추가합니다.

local_repository(
    name = "coworkers_project",
    path = "/path/to/coworkers-project",
)

동료가 대상 //foo:bar를 가지고 있으면 프로젝트에서 이를 다음과 같이 지칭할 수 있습니다. @coworkers_project//foo:bar입니다. 외부 프로젝트 이름은 올바른 작업공간 이름.

Bazel이 아닌 프로젝트에 따라 다름

new_ 프리픽스가 붙은 규칙(예: new_local_repository님, Bazel을 사용하지 않는 프로젝트에서 대상을 만들 수 있습니다.

예를 들어 my-project/ 프로젝트에서 작업하고 있는데 동료의 프로젝트(coworkers-project/)에 종속되도록 할 수 있습니다. 동료의 프로젝트에서 make를 사용하여 빌드하지만 .so 파일 중 하나에 종속하려는 경우 확인할 수 있습니다 이렇게 하려면 my_project/WORKSPACE에 다음을 추가합니다.

new_local_repository(
    name = "coworkers_project",
    path = "/path/to/coworkers-project",
    build_file = "coworker.BUILD",
)

build_file는 기존 프로젝트에 오버레이할 BUILD 파일을 지정합니다. 예:

cc_library(
    name = "some-lib",
    srcs = glob(["**"]),
    visibility = ["//visibility:public"],
)

그런 다음 프로젝트의 @coworkers_project//:some-lib에 의존할 수 있습니다. 파일 BUILD개.

외부 패키지에 따라 다름

Maven 아티팩트 및 저장소

규칙 집합 rules_jvm_external 사용 Maven 저장소에서 아티팩트를 다운로드하여 Java로 사용할 수 있도록 합니다. 종속 항목이 포함됩니다

종속 항목 가져오기

기본적으로 bazel build 중에 필요에 따라 외부 종속 항목을 가져옵니다. 만약 특정 대상 집합에 필요한 종속 항목을 미리 가져오려면 bazel fetch 모든 외부 종속 항목을 무조건적으로 가져오려면 다음을 사용합니다. bazel sync 가져온 저장소가 출력 베이스에 저장되면 자동으로 적용됩니다

종속 항목 섀도 처리

가능하면 항상 살펴보겠습니다 이는 컴파일하는 데 필요한 종속 항목에 필요합니다. 생성합니다. 하지만 그렇지 않은 경우 Shadow 종속 항목을 사용합니다 다음 상황을 살펴보세요.

myproject/WORKSPACE

workspace(name = "myproject")

local_repository(
    name = "A",
    path = "../A",
)
local_repository(
    name = "B",
    path = "../B",
)

A/Workspace

workspace(name = "A")

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
    name = "testrunner",
    urls = ["https://github.com/testrunner/v1.zip"],
    sha256 = "...",
)

B/Workspace

workspace(name = "B")

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
    name = "testrunner",
    urls = ["https://github.com/testrunner/v2.zip"],
    sha256 = "..."
)

종속 항목 A와 B는 모두 testrunner에 종속되지만, 다른 버전의 testrunner입니다. 이러한 테스트 실행기가 myproject 내에 평화롭게 공존하지는 않지만 각 단어와 충돌합니다. 둘은 이름이 같기 때문입니다. 두 종속 항목을 모두 선언하려면 myproject/WORKSPACE 업데이트:

workspace(name = "myproject")

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
    name = "testrunner-v1",
    urls = ["https://github.com/testrunner/v1.zip"],
    sha256 = "..."
)
http_archive(
    name = "testrunner-v2",
    urls = ["https://github.com/testrunner/v2.zip"],
    sha256 = "..."
)
local_repository(
    name = "A",
    path = "../A",
    repo_mapping = {"@testrunner" : "@testrunner-v1"}
)
local_repository(
    name = "B",
    path = "../B",
    repo_mapping = {"@testrunner" : "@testrunner-v2"}
)

이 메커니즘은 다이아몬드를 조인하는 데도 사용할 수 있습니다. 예: A 및 B 같은 종속 항목을 가지고 있지만 다른 이름으로 호출하는 경우 이러한 종속 항목은 myproject/WORKSPACE에 조인되어야 합니다.

명령줄에서 저장소 재정의

명령줄에서 로컬 저장소로 선언된 저장소를 재정의하려면 다음 안내를 따르세요. 사용 --override_repository 드림 플래그. 이 플래그를 사용하면 변경할 수 있습니다

예를 들어 @foo를 로컬 디렉터리 /path/to/local/foo로 재정의하려면 다음을 실행합니다. --override_repository=foo=/path/to/local/foo 플래그를 전달합니다.

다음은 몇 가지 사용 사례입니다.

디버깅 문제 예를 들어 http_archive 저장소를 재정의할 수 있습니다. 보다 쉽게 변경할 수 있는 로컬 디렉터리로 복사됩니다.
벤더링. 네트워크 호출을 할 수 없는 환경에 있는 경우 로컬 디렉터리를 가리키도록 네트워크 기반 저장소 규칙을 재정의합니다. 하세요.

프록시 사용

Bazel이 HTTPS_PROXY 및 HTTP_PROXY에서 프록시 주소를 선택합니다. 환경 변수를 사용하여 HTTP/HTTPS 파일을 다운로드합니다 (지정된 경우).

IPv6 지원

IPv6 전용 머신에서 Bazel은 변경사항이 없습니다. 그러나 듀얼 스택 IPv4/IPv6 머신에서 Bazel은 표준: IPv4가 사용 설정된 경우 IPv4가 선호됩니다. 어떤 경우에는 예를 들어 IPv4 네트워크가 외부 주소를 확인/연결할 수 없을 때, 이로 인해 Network unreachable 예외 및 빌드 실패가 발생할 수 있습니다. 이 경우 IPv6를 선호하도록 Bazel의 동작을 재정의할 수 있습니다. java.net.preferIPv6Addresses=true 시스템 속성 사용 특히 다음에 주의해야 합니다.

--host_jvm_args=-Djava.net.preferIPv6Addresses=true 사용 시작 옵션 예를 들어 .bazelrc 파일:

startup --host_jvm_args=-Djava.net.preferIPv6Addresses=true
인터넷에 연결해야 하는 Java 빌드 대상을 실행 중인 경우 (통합 테스트에 필요한 경우도 있음) --jvmopt=-Djava.net.preferIPv6Addresses=true 도구 플래그입니다. 예를 들어 .bazelrc 파일에 다음 줄을 추가합니다.

build --jvmopt=-Djava.net.preferIPv6Addresses
rules_jvm_external, 예를 들어 종속 항목 버전 확인을 위해 COURSIER_OPTS까지 -Djava.net.preferIPv6Addresses=true Coursier에 JVM 옵션을 제공하는 환경 변수

전이 종속 항목

Bazel은 WORKSPACE 파일에 나열된 종속 항목만 읽습니다. 프로젝트가 (A)는 세 번째 프로젝트의 종속 항목을 나열하는 다른 프로젝트 (B)에 종속됩니다. 프로젝트 (C)를 WORKSPACE 파일에 포함했다면 B를 모두 추가해야 합니다. 및 C를 프로젝트의 WORKSPACE 파일에 추가합니다. 이 요구사항을 통해 파일 크기가 WORKSPACE이지만 라이브러리가 하나만 있을 가능성이 제한됨 버전 1.0에 C를 포함하고 다른 버전 2.0에 C를 포함합니다.

외부 종속 항목 캐싱

기본적으로 Bazel은 다음 경우에만 외부 종속 항목을 다시 다운로드합니다. 사용됩니다. 정의에 참조된 파일의 변경사항 (예: 패치) 또는 BUILD 파일)도 bazel에서 고려합니다.

강제로 다시 다운로드하려면 bazel sync를 사용하세요.

레이아웃

외부 종속 항목은 모두 하위 디렉터리 아래의 디렉터리에 다운로드됩니다. 출력 베이스의 external 만약 로컬 저장소에 저장되면 심볼릭 링크가 생성됩니다 새 디렉터리를 만드는 대신 다음을 실행하여 external 디렉터리를 확인할 수 있습니다.

ls $(bazel info output_base)/external

bazel clean를 실행해도 실제로 외부 애플리케이션이 삭제되지는 않습니다. 디렉터리 모든 외부 아티팩트를 삭제하려면 bazel clean --expunge를 사용하세요.

오프라인 빌드

때로는 오프라인 방식으로 빌드를 실행하는 것이 바람직하거나 필요한 경우가 있습니다. 대상 간단한 사용 사례(예: 비행기 여행) 필요한 경우 prefetching bazel fetch 또는 bazel sync가 있는 저장소로 충분할 수 있습니다. 게다가 --nofetch 옵션을 사용하면 추가 저장소 가져오기를 사용 중지할 수 있습니다. 확인할 수 있습니다

필요한 파일을 제공해야 하는 실제 오프라인 빌드의 경우 bazel과 다른 엔티티에 의해 작성되는 경우 bazel은 해당 옵션을 지원합니다. --distdir 저장소 규칙이 다음을 통해 파일을 가져오도록 bazel에 요청할 때마다 ctx.download 또는 ctx.download_and_extract 파일의 해시 합계를 제공합니다. 필요한 경우 bazel은 먼저 제공된 첫 번째 URL의 기본 이름과 일치하는 확인할 수 있습니다.

Bazel 자체에서 이 기법을 사용하여 배포판에서 오프라인으로 부트스트랩합니다. 아티팩트를 참고하세요. 이를 위해 필요한 모든 외부 데이터 종속 항목 내부 distdir_tar

그러나 bazel은 저장소 규칙에서 임의의 명령어 실행을 허용합니다. 외부 IP 주소가 네트워크로 호출하는지 알지 못한 채 말이죠 따라서 bazel은 빌드를 완전히 오프라인으로 적용할 수 있습니다 따라서 빌드가 올바르게 작동하는지 테스트하는지 오프라인일 때는 네트워크의 외부 차단이 필요하며, 이는 bazel이 부트스트랩 테스트

권장사항

저장소 규칙

저장소 규칙은 일반적으로 다음을 담당해야 합니다.

시스템 설정 감지 및 파일에 쓰기
시스템의 다른 곳에서 리소스를 찾습니다.
URL에서 리소스 다운로드
BUILD 파일을 생성하거나 외부 저장소 디렉터리에 심볼릭 링크 만들기

가능하면 repository_ctx.execute를 사용하지 않는 것이 좋습니다. 예를 들어 Bazel이 아닌 C++를 사용하는 경우 빌드가 포함된 경우 repository_ctx.download()를 사용하는 것이 좋습니다. ctx.execute(["make"])를 실행하는 대신 빌드하는 BUILD 파일을 작성합니다.

git_repository보다 http_archive 선호 및 new_git_repository입니다. 이유는 다음과 같습니다.

Git 저장소 규칙은 시스템 git(1)에 종속되지만 HTTP 다운로더는 빌드됩니다. Bazel에 연결할 수 있으며 시스템 종속 항목이 없습니다.
http_archive는 urls 목록을 미러로 지원하고 git_repository는 다음만 지원합니다. 단일 remote입니다.
http_archive는 저장소 캐시와 호환되지만 작동하지 않습니다. git_repository입니다. 자세한 내용은 #5116을 참조하세요.

bind()를 사용하지 마세요. '삭제 고려하기'를 참고하세요. 바인드" 오랫동안 문제와 대안에 대해 논의합니다