Workspace 규칙

문제 신고open_in_new 소스 보기open_in_new

작업공간 규칙은 일반적으로 기본 저장소 외부에 있는 소스 코드인 외부 종속 항목을 가져오는 데 사용됩니다.

참고: Bazel은 기본 작업공간 규칙 외에도 다양한 Starlark 작업공간 규칙, 특히 웹에 호스팅되는 git 저장소 또는 보관 규칙을 처리하는 규칙도 삽입합니다.

규칙

• 결합
• local_repository
• new_local_repository

bind

규칙 소스 보기open_in_new

bind(name, actual, compatible_with, deprecation, distribs, features, licenses, restricted_to, tags, target_compatible_with, testonly, visibility)

경고: bind()는 사용하지 않는 것이 좋습니다. 문제 및 대안에 관한 자세한 설명은 '바인딩 삭제 고려'를 참고하세요. 특히 repo_mapping 저장소 속성 사용을 고려하세요.

경고: select()는 bind()에서 사용할 수 없습니다. 자세한 내용은 구성 가능한 속성 FAQ를 참고하세요.

//external 패키지의 대상에 별칭을 제공합니다.

//external 패키지는 '일반' 패키지가 아닙니다. 외부/ 디렉터리는 없으므로 모든 바인드된 타겟을 포함하는 '가상 패키지'로 생각할 수 있습니다.

예

대상에 별칭을 제공하려면 WORKSPACE 파일에서 별칭을 bind로 지정하세요. 예를 들어 //third_party/javacc-v2라는 java_library 타겟이 있다고 가정해 보겠습니다. WORKSPACE 파일에 다음을 추가하여 별칭을 지정할 수 있습니다.

bind(
    name = "javacc-latest",
    actual = "//third_party/javacc-v2",
)

이제 타겟은 //third_party/javacc-v2 대신 //external:javacc-latest에 종속될 수 있습니다. javacc-v3이 출시되면 bind 규칙을 업데이트할 수 있고 //external:javacc-latest에 종속된 모든 BUILD 파일은 이제 수정할 필요 없이 javacc-v3에 종속됩니다.

Bind를 사용하여 외부 저장소의 대상을 작업공간에 제공할 수도 있습니다. 예를 들어 WORKSPACE 파일에 @my-ssl라는 원격 저장소가 있고 cc_library 대상 //src:openssl-lib가 있는 경우 bind를 사용하여 이 타겟의 별칭을 만들 수 있습니다.

bind(
    name = "openssl",
    actual = "@my-ssl//src:openssl-lib",
)

그런 다음 작업공간의 BUILD 파일에서 다음과 같이 결합된 타겟을 사용할 수 있습니다.

cc_library(
    name = "sign-in",
    srcs = ["sign_in.cc"],
    hdrs = ["sign_in.h"],
    deps = ["//external:openssl"],
)

sign_in.cc 및 sign_in.h 내에서 //external:openssl에 의해 노출되는 헤더 파일을 저장소 루트를 기준으로 한 경로를 사용하여 참조할 수 있습니다. 예를 들어 @my-ssl//src:openssl-lib의 규칙 정의는 다음과 같습니다.

cc_library(
    name = "openssl-lib",
    srcs = ["openssl.cc"],
    hdrs = ["openssl.h"],
)

그러면 sign_in.cc의 include는 다음과 같을 수 있습니다.

#include "sign_in.h"
#include "src/openssl.h"

인수

속성
name	Name; required 이 타겟의 고유한 이름입니다.
actual	Label; optional 별칭을 지정할 대상입니다. 이 타겟은 있어야 하지만 모든 유형의 규칙 (바인딩 포함)일 수 있습니다. 이 속성을 생략하면 //external에서 이 대상을 참조하는 규칙이 이 종속 항목 가장자리를 볼 수 없습니다. 이는 bind 규칙을 완전히 생략하는 것과는 다릅니다. //external 종속 항목에 연결된 bind 규칙이 없으면 오류가 발생합니다.

local_repository

규칙 소스 보기open_in_new

local_repository(name, path, repo_mapping)

로컬 디렉터리의 대상이 바인딩되도록 허용합니다. 즉, 현재 저장소는 다른 디렉터리에 정의된 대상을 사용할 수 있습니다. 자세한 내용은 결합 섹션을 참고하세요.

예

현재 저장소가 ~/chat-app 디렉터리에 있는 채팅 클라이언트라고 가정해 보겠습니다. 다른 저장소에 정의된 SSL 라이브러리 ~/ssl을 사용하려고 합니다. SSL 라이브러리에는 대상 //src:openssl-lib가 있습니다.

사용자는 ~/chat-app/WORKSPACE에 다음 줄을 추가하여 이 대상에 대한 종속 항목을 추가할 수 있습니다.

local_repository(
    name = "my-ssl",
    path = "/home/user/ssl",
)

타겟은 이 라이브러리에 종속될 종속 항목을 @my-ssl//src:openssl-lib로 지정합니다.

인수

속성
name	Name; required 이 타겟의 고유한 이름입니다.
path	String; required 로컬 저장소의 디렉터리 경로입니다. 저장소의 WORKSPACE 파일이 포함된 디렉터리 경로여야 합니다. 경로는 절대 저장소의 상대 경로이거나 기본 저장소의 WORKSPACE 파일이어야 합니다.
repo_mapping	Dictionary: String -> String; optional 로컬 저장소 이름에서 전역 저장소 이름으로의 사전입니다. 이렇게 하면 이 저장소의 종속 항목에 대한 작업공간 종속 항목 해결을 제어할 수 있습니다. 예를 들어 "@foo": "@bar" 항목은 이 저장소가 "@foo"에 종속되는 경우 (예: "@foo//some:target"의 종속 항목) 전역적으로 선언된 "@bar" ("@bar//some:target") 내에서 실제로 이 종속 항목을 해결해야 한다고 선언합니다.

새_로컬_저장소

규칙 소스 보기open_in_new

new_local_repository(name, build_file, build_file_content, path, repo_mapping, workspace_file, workspace_file_content)

로컬 디렉터리를 Bazel 저장소로 변환할 수 있습니다. 즉, 현재 저장소는 파일 시스템의 모든 위치에서 대상을 정의하고 사용할 수 있습니다.

이 규칙은 지정된 BUILD 파일 및 경로에 대한 심볼릭 링크가 포함된 WORKSPACE 파일과 하위 디렉터리를 만들어 Bazel 저장소를 만듭니다. 빌드 파일은 path을 기준으로 타겟을 생성해야 합니다. 이미 WORKSPACE 파일과 BUILD 파일이 포함된 디렉터리의 경우 local_repository 규칙을 사용할 수 있습니다.

예

현재 저장소가 ~/chat-app 디렉터리에 기반한 채팅 클라이언트라고 가정해 보겠습니다. 다른 디렉터리(~/ssl)에 정의된 SSL 라이브러리를 사용하려고 합니다.

사용자는 다음을 포함하는 SSL 라이브러리(~/chat-app/BUILD.my-ssl)용 BUILD 파일을 만들어 종속 항목을 추가할 수 있습니다.

java_library(
    name = "openssl",
    srcs = glob(['*.java'])
    visibility = ["//visibility:public"],
)

그런 다음 ~/chat-app/WORKSPACE에 다음 줄을 추가할 수 있습니다.

new_local_repository(
    name = "my-ssl",
    path = "/home/user/ssl",
    build_file = "BUILD.my-ssl",
)

이렇게 하면 /home/user/ssl에 심볼릭 링크를 만드는 @my-ssl 저장소가 생성됩니다. 타겟은 @my-ssl//:openssl를 타겟의 종속 항목에 추가하여 이 라이브러리에 종속될 수 있습니다.

new_local_repository를 사용하여 디렉터리뿐만 아니라 단일 파일도 포함할 수 있습니다. 예를 들어 /home/username/Downloads/piano.jar에 jar 파일이 있다고 가정해 보겠습니다. WORKSPACE 파일에 다음을 추가하여 이 파일만 빌드에 추가할 수 있습니다.

new_local_repository(
    name = "piano",
    path = "/home/username/Downloads/piano.jar",
    build_file = "BUILD.piano",
)

그리고 다음과 같은 BUILD.piano 파일을 만듭니다.

java_import(
    name = "play-music",
    jars = ["piano.jar"],
    visibility = ["//visibility:public"],
)

그런 다음 대상은 @piano//:play-music에 의존하여 piano.jar을 사용할 수 있습니다.

인수

속성
name	Name; required 이 타겟의 고유한 이름입니다.
build_file	String; optional 이 디렉터리의 BUILD 파일로 사용할 파일입니다. build_file 또는 build_file_content를 지정해야 합니다. 이 속성은 기본 작업공간을 기준으로 하는 라벨입니다. 파일 이름을 BUILD할 필요는 없지만 지정할 수 있습니다. BUILD.new-repo-name과 같은 항목을 저장소의 실제 BUILD 파일과 구분하는 데 적합합니다.
build_file_content	String; optional 이 저장소에 대한 BUILD 파일의 콘텐츠입니다. build_file 또는 build_file_content를 지정해야 합니다.
path	String; required 로컬 파일 시스템의 경로입니다. 절대 또는 기본 저장소의 WORKSPACE 파일을 기준으로 할 수 있습니다.
repo_mapping	Dictionary: String -> String; optional 로컬 저장소 이름에서 전역 저장소 이름으로의 사전입니다. 이렇게 하면 이 저장소의 종속 항목에 대한 작업공간 종속 항목 해결을 제어할 수 있습니다. 예를 들어 "@foo": "@bar" 항목은 이 저장소가 "@foo"에 종속되는 경우 (예: "@foo//some:target"의 종속 항목) 전역적으로 선언된 "@bar" ("@bar//some:target") 내에서 실제로 이 종속 항목을 해결해야 한다고 선언합니다.
workspace_file	String; optional 이 저장소의 WORKSPACE 파일로 사용할 파일입니다. workspace_file 또는 workspace_file_content 중 하나를 지정할 수 있지만 둘 다 지정할 수는 없습니다. 이 속성은 기본 작업공간을 기준으로 하는 라벨입니다. 파일 이름을 WORKSPACE하지 않아도 됩니다. WORKSPACE.new-repo-name 같은 항목은 저장소의 실제 WORKSPACE 파일과 쉽게 구분할 수 있습니다.
workspace_file_content	String; optional 이 저장소에 대한 WORKSPACE 파일의 콘텐츠 workspace_file 또는 workspace_file_content 중 하나를 지정할 수 있지만 둘 다 지정할 수는 없습니다.