라벨은 타겟의 식별자입니다. 전체 표준 URL의 일반적인 라벨은 형식은 다음과 같습니다.
@@myrepo//my/app/main:app_binary
라벨의 첫 번째 부분은 저장소 이름(@@myrepo)입니다. 더블 @
구문은 이 저장소가 표준 저장소임을 나타냅니다.
이름은
살펴보겠습니다 표준 저장소 이름이 있는 라벨은 대상을 명확하게 식별합니다.
어떤 맥락에서 보든
표준 저장소 이름은 종종
@@rules_java++toolchains+local_jdk 훨씬 일반적으로 볼 수 있는 것은
명확한 저장소 이름으로 라벨을 지정합니다.
다음과 같습니다.
@myrepo//my/app/main:app_binary
유일한 차이점은 저장소 이름에 2개가 아닌 하나의 @ 접두사가 붙은 것입니다.
명백한 이름이 myrepo인 저장소를 나타냅니다. 저장소는 다를 수 있습니다.
기반으로 합니다.
일반적으로 라벨은 라벨이 지정된 포드가 있는
저장소 이름 부분이 생략될 수 있습니다. 따라서 @@myrepo 내에서 첫 번째
라벨은 일반적으로
//my/app/main:app_binary
라벨의 두 번째 부분은 정규화되지 않은 패키지 이름입니다.
my/app/main: 패키지 경로
상대적 경로를 반환합니다 합쳐서 저장소 이름과
정규화된 패키지 이름과 형식이 정규화되지 않은 패키지 이름
@@myrepo//my/app/main 라벨이
사용된 패키지, 패키지 이름 (선택사항으로 콜론)
생략할 수 있습니다. 따라서 @@myrepo//my/app/main 내에서
이 라벨은 다음 중 한 가지 방법으로 작성할 수 있습니다.
app_binary
:app_binary
파일의 경우 콜론을 생략하는 것이 규칙입니다. 규칙에 대해서는 보관되지만 그 외에는 중요하지 않습니다.
콜론 다음에 오는 라벨 부분인 app_binary는 정규화되지 않은 타겟입니다.
있습니다. 패키지 경로의 마지막 구성요소와 일치할 때 해당 구성요소와
생략할 수 있습니다. 따라서 이 두 라벨은 동일합니다.
//my/app/lib
//my/app/lib:lib
패키지의 하위 디렉터리에 있는 파일 대상의 이름은 파일의 경로입니다.
패키지 루트 (BUILD 파일이 포함된 디렉터리)를 기준으로 합니다. 따라서
이 파일은 저장소의 my/app/main/testdata 하위 디렉터리에 있습니다.
//my/app/main:testdata/input.txt
//my/app 및 @@some_repo//my/app과 같은 문자열은
즉, Bazel이 레이블을 예상하면
각각 //my/app:app 및 @@some_repo//my/app:app입니다. 하지만 Bazel이
(예: package_group 사양에서) 패키지가 필요하며, 다음을 참조합니다.
해당 라벨이 포함된 패키지를 선택합니다.
BUILD 파일에서 발생하는 일반적인 실수는 //my/app를 사용하여 패키지를 참조하는 것입니다.
패키지 내 모든 대상에 추가해야 하지만 그렇게 하지는 않습니다. 기억하세요,
//my/app:app와 같으므로 my/app의 app 타겟 이름을 지정합니다.
패키지입니다.
그러나 다음에서 //my/app를 사용하여 패키지를 참조하는 것이 좋습니다.
package_group 또는 .bzl 파일에서 지정할 수 있습니다.
패키지 이름이 절대적이고 최상위에 루트를 두고 있음을 전달
디렉터리에 있습니다
상대 라벨은 다른 패키지의 타겟을 참조하는 데 사용할 수 없습니다.
이 경우 저장소 식별자와 패키지 이름을 항상 지정해야 합니다.
예를 들어 소스 트리에 my/app 패키지와
my/app/testdata 패키지 (이 두 디렉터리는
BUILD 파일) 후자의 패키지에는 testdepot.zip라는 파일이 포함됩니다. 여기
이 파일을 참조하는 방법은 두 가지입니다 (하나는 틀렸고 다른 하나는 정답).
//my/app:BUILD:
틀림 — testdata는 다른 패키지이므로 상대 경로를 사용할 수 없습니다.
testdata/testdepot.zip
올바름 — 전체 경로는 testdata 참조
//my/app/testdata:testdepot.zip
@@//로 시작하는 라벨은 기본
외부 저장소에서도 계속 작동합니다.
따라서 @@//a/b/c는
외부 저장소에서 참조되는 경우 //a/b/c입니다.
전자는 기본 저장소를 참조하고 후자는 기본 저장소를 가리킵니다.
외부 저장소 자체에서 //a/b/c를 찾습니다.
이는 특히 기본 애플리케이션에 규칙을 작성할 때
대상으로 하는 새 저장소이며
외부 저장소에서 사용됩니다
대상을 참조할 수 있는 다양한 방법에 대한 자세한 내용은 대상 패턴과는 다릅니다.
라벨의 어휘 사양
라벨 구문은 살펴보겠습니다 이렇게 하면 실수로 인용 문제를 방지하는 데 도움이 되며 다음과 같이 레이블을 조작하는 도구 및 스크립트를 작성할 수 있습니다. Bazel 쿼리 언어.
허용되는 대상 이름의 정확한 세부정보는 다음과 같습니다.
대상 이름 — package-name:target-name
target-name은 패키지 내 타겟의 이름입니다. 규칙의 이름
BUILD의 규칙 선언에 있는 name 속성의 값입니다.
file; 파일의 이름은
BUILD 파일
대상 이름은 a~z 집합에서 가져온 문자로만 구성되어야 합니다.
A~Z, 0~9, 구두점 기호 !%-@^_"#$&'()*-+,;<=>?[]{|}~/.
파일 이름은 상대 경로 이름이어야 합니다. 즉,
슬래시로 시작하거나 끝나지 않습니다 (예: /foo 및 foo/는
금지됨) 경로 구분자로 여러 개의 연속된 슬래시를 포함하지도 않아야 합니다.
(예: foo//bar) 마찬가지로 업레벨 참조 (..) 및
현재 디렉터리 참조 (./)는 금지되어 있습니다.
잘못됨 — ..를 사용하여 다른 패키지에 있는 파일을 참조하지 마세요.
정답 — 사용
<ph type="x-smartling-placeholder">//package-name:filename</ph>
파일 타겟 이름에 /를 사용하는 것이 일반적이지만
규칙 이름에 /를 포함합니다. 특히 라벨의 약식 형식이
독자가 혼란스러울 수 있습니다 //foo/bar/wiz 라벨은 항상 약식입니다.
//foo/bar/wiz:wiz의 경우(foo/bar/wiz 패키지가 없는 경우에도) 이 항목
타겟이 존재하더라도 //foo:bar/wiz를 참조하지 않습니다.
그러나 슬래시를 사용하는 것이 편리한 몇 가지 상황이 있습니다. 때로는 꼭 필요할 때도 있습니다. 예를 들어 특정 규칙의 이름은 파일의 하위 디렉터리에 있을 수 있는 주 소스 파일.
패키지 이름 — //package-name:target-name
패키지 이름은 BUILD 파일이 포함된 디렉터리의 이름입니다.
최상위 디렉토리를 기준으로 합니다.
예를 들면 my/app입니다.
기술적 수준에서 Bazel은 다음을 적용합니다.
- 패키지 이름에 허용되는 문자는 소문자
a~z입니다. 대문자A~Z, 숫자0~9, 문자! \"#$%&'()*+,-.;<=>?@[]^_`{|}(예, 공백 문자가 있습니다. 슬래시는 물론 슬래시/(디렉터리이기 때문에)를 사용합니다. 구분자). - 패키지 이름은 슬래시 문자(
/)로 시작하거나 끝날 수 없습니다. - 패키지 이름에는 하위 문자열
//를 포함할 수 없습니다. 이것은 해당하는 디렉토리 경로는 무엇일까요? - 패키지 이름에는 하위 문자열
/./,/../또는/.../등을 포함할 수 없습니다. 이 시행은 논리 문장을 변환할 때 혼동을 피하기 위해 패키지 이름 및 물리적 디렉터리 이름을 의미하며, 점 문자를 사용합니다.
실용적인 측면:
- 모듈에 중요한 디렉터리 구조를 갖는 언어의 경우 다른 시스템 (예: Java)에서 실행하려는 것보다 유효한 식별자를 생성합니다 예를 들어, 맨 앞에 오는 특수문자, 특히 밑줄 및 하이픈은 사용하지 마세요.
- Bazel은 작업공간의 루트 패키지 (예:
//:foo)가 있는 경우 모든 의미 있는 패키지가 표시되도록 이 패키지를 비워 두는 것이 가장 좋습니다. 설명하는 이름을 사용합니다.
규칙
규칙은 입력과 출력 간의 관계를 지정하며 출력을 빌드하는 단계를 수행합니다. 규칙은 다양한 규칙 클래스라고도 하며 그 밖에 지원되는 실행 파일과 라이브러리, 테스트 실행 파일 등 백과사전 빌드에 설명된 대로 출력됩니다.
BUILD 파일은 규칙을 호출하여 대상을 선언합니다.
아래 예에서는 타겟 my_app의 선언을 확인할 수 있습니다.
cc_binary 규칙 사용
cc_binary(
name = "my_app",
srcs = ["my_app.cc"],
deps = [
"//absl/base",
"//absl/strings",
],
)
모든 규칙 호출에는 name 속성 (유효한
target name)으로 지정합니다. 이는 패키지 내의 타겟을 선언하는 것입니다.
(BUILD 파일)
모든 규칙에는 일련의 속성이 있습니다. 적용 가능한 속성을 각 속성의 의미와 의미는 규칙의 종류 자세한 내용은 백과사전 만들기를 규칙 및 해당 속성의 목록입니다. 각 속성에는 이름과 유형. 속성에 포함될 수 있는 일반적인 유형은 정수, 라벨, 목록 레이블의 종류, 문자열, 문자열 목록, 출력 레이블, 출력 레이블 목록입니다. 비 모든 속성은 모든 규칙에 지정해야 합니다. 따라서 특성은 사전의 내용을 키 (이름)에서 선택적인 유형이 지정된 값으로 변환합니다.
많은 규칙에 있는 srcs 속성에는 '라벨 목록' 유형이 있습니다. 이것의
값(있는 경우)은 라벨 목록이며 각각은
추가할 수 있습니다.
경우에 따라서는 규칙 종류의 이름이 다소 임의적이며 규칙으로 생성된 파일의 이름이 흥미롭습니다. 그리고 이것은 사실입니다. 살펴보겠습니다 자세한 내용은 일반 규칙: genrule.
다른 경우에는 이름이 중요합니다. *_binary 및 *_test 규칙의 경우
예를 들어 규칙 이름은
지정할 수도 있습니다
타겟에 대한 이러한 방향성 비순환 그래프를 타겟 그래프라고 합니다. 빌드 종속 항목 그래프, 빌드 종속 항목 그래프가 Bazel 쿼리 도구가 작동합니다.
| <ph type="x-smartling-placeholder"></ph> 타겟 | <ph type="x-smartling-placeholder"></ph> BUILD 파일 |