작업공간 규칙은 일반적으로 기본 저장소 외부에 있는 소스 코드인 외부 종속 항목을 가져오는 데 사용됩니다.
참고: 기본 작업공간 규칙 외에도 Bazel은 다양한 Starlark 작업공간 규칙을 삽입합니다. 특히 웹에서 호스팅되는 git 저장소나 보관 파일을 처리하기 위한 규칙입니다.
규칙
bind
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
패키지는 '일반' 패키지가 아니며 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에 종속됩니다.
외부 저장소의 대상을 작업공간에 제공하는 데에도 결합을 사용할 수 있습니다.
예를 들어 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 |
이 대상의 고유한 이름입니다. |
actual
|
이 대상은 있어야 하지만 어떤 유형의 규칙 (바인드 포함)이 될 수도 있습니다. 이 속성을 생략하면 |
local_repository
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 |
이 대상의 고유한 이름입니다. |
path
|
저장소의 WORKSPACE 파일이 있는 디렉터리의 경로여야 합니다. 경로는 절대적이거나 기본 저장소의 WORKSPACE 파일에 대한 상대 경로일 수 있습니다. |
repo_mapping
|
예를 들어 |
new_local_repository
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 |
이 대상의 고유한 이름입니다. |
build_file
|
build_file 또는 build_file_content 중 하나를 지정해야 합니다. 이 속성은 기본 작업공간을 기준으로 한 라벨입니다. 파일 이름을 BUILD로 지정할 필요는 없지만 사용해도 됩니다. BUILD.new-repo-name과 같은 항목이 저장소의 실제 BUILD 파일과 구별될 수도 있습니다. |
build_file_content
|
build_file 또는 build_file_content 중 하나를 지정해야 합니다. |
path
|
절대적 또는 기본 저장소의 WORKSPACE 파일을 기준으로 할 수 있습니다. |
repo_mapping
|
예를 들어 |
workspace_file
|
workspace_file 또는 workspace_file_content 중 하나를 지정할 수 있지만 둘 다 지정할 수는 없습니다. 이 속성은 기본 작업공간을 기준으로 한 라벨입니다. 파일 이름을 WORKSPACE로 지정할 필요는 없지만 사용해도 됩니다. WORKSPACE.new-repo-name과 같은 명령어는 저장소의 실제 WORKSPACE 파일과 구분할 수 있습니다. |
workspace_file_content
|
workspace_file 또는 workspace_file_content 중 하나를 지정할 수 있지만 둘 다 지정할 수는 없습니다. |