Make Variables

문제 신고 소스 보기 1박 · 7.4 에서 자세한 내용을 확인하실 수 있습니다. 7.3 · 7.2 · 7.1 · 7.0 · 6.5

'만들기' 변수는 사용할 수 있는 확장 가능한 문자열 변수의 특수 클래스입니다. 'Make var(변수 만들기)' 대체'를 사용해야 합니다.

예를 들어 이러한 작업은 사용자가 생성한 빌드 작업에 특정 도구 모음 경로를 삽입하는 데 사용할 수 있습니다.

Bazel은 사전 정의된 변수를 모두 제공하며 이 변수는 대상 및 종속 항목 타겟에 정의된 맞춤 변수 이를 사용하는 타겟에서만 사용할 수 있습니다.

'Make'라는 용어는 역사적인 이유로 사용됩니다. 이러한 변수의 문법과 시맨틱은 원래 GNU Make와 일치하도록 설계되었습니다.

사용

'Make 변수 대체 대상'으로 표시된 속성은 다음과 같이 'Make' 변수 FOO를 참조할 수 있습니다.

my_attr = "prefix $(FOO) suffix"

즉, $(FOO)와 일치하는 모든 하위 문자열은 FOO의 값으로 확장됩니다. 이 값이 "bar"이면 최종 문자열은 다음과 같이 변환됩니다.

my_attr = "prefix bar suffix"

FOO가 소비 타겟에 알려진 변수와 일치하지 않으면 Bazel이 오류와 함께 실패합니다.

'만들기' 이름이 아닌 기호가 있는 변수(예: @는 달러 기호만 사용하여 참조할 수도 있습니다(예: 괄호를 사용합니다. 예를 들면 다음과 같습니다.

my_attr = "prefix $@ suffix"

$를 문자열 리터럴로 작성하려면(즉, 변수 확장을 방지하려면) $$을 작성합니다.

사전 정의된 변수

사전 정의된 '제조업체' 변수는 "'Makevariable'(변수 만들기)이 대체'를 반환합니다.

주어진 빌드 세트의 이러한 변수 및 변수 값 보기 옵션, 실행

bazel info --show_make_env [build options]

대문자로 표시된 상단 출력 라인을 확인합니다.

사전 정의된 변수의 예 보기

툴체인 옵션 변수

경로 변수

  • BINDIR: 대상 아키텍처용으로 생성된 바이너리 트리의 기준입니다.

    실행 중에 실행되는 프로그램에 다른 트리가 사용될 수도 호스트 아키텍처에 빌드하여 크로스 컴파일을 지원합니다.

    genrule 내에서 도구를 실행하려면 경로를 가져오는 데 권장되는 방법은 $(execpath toolname)입니다. 여기서 toolname은 genrule의 tools 속성

  • GENDIR: 대상 아키텍처에 대해 생성된 코드 트리의 기준입니다.

머신 아키텍처 변수

  • TARGET_CPU: 타겟 아키텍처의 CPU입니다(예: k8).

사전 정의된 genrule 변수

다음은 genrule의 cmd 속성에만 사용할 수 있으며 일반적으로 이 속성을 작동시키는 데 중요합니다.

사전 정의된 genrule 변수의 예를 참조하세요.

  • OUTS: genrule의 outs 목록입니다. 출력 파일이 하나만 있는 경우 $@를 사용할 수도 있습니다.
  • SRCS: genrule의 srcs 목록(더 정확하게는 srcs 목록의 라벨에 해당하는 파일의 경로 이름)입니다. 소스 파일이 하나뿐인 경우 $<를 사용할 수도 있습니다.
  • <: SRCS(단일 파일인 경우) 그 외의 경우 빌드 오류가 트리거됩니다.
  • @: 단일 파일인 경우 OUTS 그렇지 않으면 빌드 오류가 발생합니다.

  • RULEDIR: 대상의 출력 디렉터리(즉, 타겟이 포함된 패키지의 이름에 해당하는 genfiles 또는 bin 트리 아래 //my/pkg:my_genrule의 경우 //my/pkg:my_genrule의 출력이 하위 디렉터리에 있더라도 항상 my/pkg로 끝납니다.

  • @D: 출력 디렉터리 만약 아웃에는 항목이 1개 있습니다. 해당 파일이 포함된 디렉터리로 확장됩니다. 여러 개의 이 항목은 genfiles 트리(모든 출력 파일이 동일한 경우일 경우) 하위 디렉터리를 참조하세요.

    참고: RULEDIR가 더 간단한 시맨틱스를 갖고 있고 출력 파일 수와 관계없이 동일한 방식으로 동작하므로 @D 대신 RULEDIR를 사용하세요.

    genrule이 임시 중간 파일 (예: 컴파일러와 같은 다른 도구를 사용한 결과인 경우) @D에 씁니다. 단, /tmp는 쓰기 가능해야 함)하고 완료하기 전에 제거해야 합니다.

    특히 입력이 포함된 디렉터리에 쓰지 마세요. 읽기 전용 파일 시스템에 있을 수 있습니다. 그렇지 않은 경우에도 그렇게 하면 소스 트리가 삭제됩니다.

사전 정의된 소스/출력 경로 변수

사전 정의된 변수 execpath, execpaths rootpath, rootpaths, location 외 locations는 라벨 매개변수 (예: $(execpath //foo:bar))를 사용하고 해당 라벨에 표시된 파일 경로를 대체합니다.

소스 파일의 경우 이는 작업공간 루트를 기준으로 한 경로입니다. 규칙의 출력인 파일의 경우 파일의 출력 경로입니다(아래의 출력 파일 설명 참고).

사전 정의된 경로 변수의 예 보기

  • execpath: Bazel에서 빌드 작업을 실행하는 execroot 아래의 경로를 나타냅니다.

    위 예에서 Bazel은 작업공간 루트의 bazel-myproject 심볼릭 링크로 연결된 디렉터리에서 모든 빌드 작업을 실행합니다. 소스 파일 empty.source가 bazel-myproject/testapp/empty.source 경로에 연결되어 있습니다. 따라서 실행 경로(루트 아래의 하위 경로)는 testapp/empty.source입니다. 이 빌드 작업이 파일을 찾는 데 사용할 수 있는 경로입니다.

    출력 파일도 비슷하게 스테이징되지만 하위 경로 bazel-out/cpu-compilation_mode/bin(또는 도구의 출력의 경우 bazel-out/cpu-opt-exec-hash/bin)가 접두사로 추가됩니다. 위 예에서 //testapp:app는 show_app_output의 tools 속성에 표시되므로 도구입니다. 따라서 출력 파일 app은 bazel-myproject/bazel-out/cpu-opt-exec-hash/bin/testapp/app입니다. 따라서 실행 경로는 bazel-out/cpu-opt-exec-hash/bin/testapp/app입니다. 이 추가 접두사를 사용하면 결과가 서로 충돌하지 않고 동일한 빌드에서 두 개의 서로 다른 CPU에 대해 동일한 타겟을 빌드할 수 있습니다.

    이 변수에 전달된 라벨은 정확히 하나의 파일을 나타내야 합니다. 대상 소스 파일을 나타내는 라벨이면 자동으로 true가 됩니다. 라벨 규칙은 정확히 하나의 출력을 생성해야 합니다. 이 값이 false이거나 라벨의 형식이 잘못되면 빌드가 오류와 함께 실패합니다.

  • rootpath: 빌드된 바이너리가 기본 저장소에 해당하는 runfiles 디렉터리의 하위 디렉터리를 기준으로 런타임에 종속 항목을 찾는 데 사용할 수 있는 경로를 나타냅니다. 참고: 이 방법은 --enable_runfiles가 사용 설정된 경우에만 작동하며, Windows에서는 기본적으로 사용 설정되어 있지 않습니다. 교차 플랫폼 지원을 위해 rlocationpath를 대신 사용하세요.

    execpath와 유사하지만 구성이 삭제됩니다. 접두사를 사용하면 됩니다. 위의 예에서 이는 empty.source 및 app는 순수 작업공간 기준 사용 경로: testapp/empty.source 및 testapp/app.

    외부 저장소에 있는 파일의 rootpath repo는 ../repo/로 시작하고 이어서 저장소 기준 경로를 사용합니다.

    '출력 하나만' 동일합니다. 요구사항을 execpath로 정의합니다.

  • rlocationpath: 빌드된 바이너리가 실행 파일 라이브러리의 Rlocation 함수에 전달하여 다음 위치에서 종속 항목을 찾을 수 있는 경로입니다. 또는 실행 파일 디렉토리 (사용 가능한 경우)에서 또는 실행 파일 매니페스트를 참조하세요.

    이것은 rootpath과 마찬가지로 구성 프리픽스를 사용하지만 항상 이름을 지정합니다 위의 예에서 empty.source 및 app의 결과는 다음과 같습니다. 경로: myproject/testapp/empty.source 및 myproject/testapp/app.

    외부 저장소 repo의 파일 rlocationpath는 repo/로 시작하고 저장소 상대 경로가 뒤에 옵니다.

    이 경로를 바이너리에 전달하고 다음을 사용하여 파일 시스템 경로로 확인합니다. 실행 파일 라이브러리는 런타임 환경입니다 rootpath에 비해 모든 플랫폼에서 작동하고 runfiles 디렉터리를 사용할 수 없는 경우에도 작동한다는 이점이 있습니다.

    execpath와 동일한 '하나의 출력만' 요구사항이 적용됩니다.

  • location: execpath 또는 펼쳐지는 속성에 따라 rootpath입니다. 이는 Starlark 이전의 기존 동작이며 특정 규칙에 어떤 영향을 미치는지 정확히 알고 있는 경우가 아니라면 권장되지 않습니다. 자세한 내용은 #2475를 참고하세요.

execpaths, rootpaths, rlocationpaths, locations는 각각 execpath, rootpath, rlocationpaths, location의 복수형 변형입니다. 여러 출력을 생성하는 라벨을 지원합니다. 각 출력은 공백으로 구분됩니다. 0 출력 규칙 및 잘못된 형식 라벨은 빌드 오류를 일으킵니다.

참조된 모든 라벨은 소비 타겟의 srcs, 출력 파일 또는 deps에 표시되어야 합니다. 그렇지 않으면 빌드가 실패합니다. C++ 타겟은 data의 라벨을 참조할 수도 있습니다.

라벨은 표준 형식이 아니어도 됩니다. foo, :foo, //somepkg:foo 모두 괜찮습니다.

맞춤 변수

맞춤 'Make' 변수는 "'Make var'(변수 만들기)가 대체'를 지원하지만 이러한 변수를 정의하는 다른 대상에 종속됩니다.

좋은 방법이 없는 한 모든 변수는 맞춤설정해야 합니다. 핵심 Bazel에 베이킹해야 하는 이유입니다. 따라서 Bazel은 tarets를 사용하는 변수를 공급하기 위해 잠재적으로 비용이 많이 드는 종속 항목을 신경 쓰지 않아도 됩니다

C++ 도구 모음 변수

다음은 C++ 도구 모음 규칙에 정의되어 있으며 모든 규칙에 사용할 수 있습니다. toolchains = ["@bazel_tools//tools/cpp:current_cc_toolchain"] 설정 java_binary 등의 일부 규칙은 암시적으로 규칙 정의에 C++ 도구 모음을 포함하는지 확인하세요. 이러한 변수는 자동으로 상속됩니다.

내장된 C++ 규칙은 '컴파일러를 실행'하는 것보다 훨씬 정교합니다. *SAN, ThinLTO, 모듈 유무, 신중하게 최적화된 바이너리와 같은 다양한 컴파일 모드를 지원하는 동시에 여러 플랫폼에서 테스트를 빠르게 실행하기 위해 내장 규칙은 내부에서 생성된 여러 작업 각각에 올바른 입력, 출력, 명령줄 플래그가 설정되도록 많은 노력을 기울입니다.

이러한 변수는 드물지만 언어 전문가가 사용할 수 있는 대체 메커니즘입니다. 이러한 기능을 사용하고 싶다면 먼저 Bazel 개발자에게 문의하세요.

  • ABI: C++ ABI 버전입니다.
  • AR: 크로스툴의 'ar' 명령어입니다.
  • C_COMPILER: C/C++ 컴파일러 식별자입니다. 예: llvm입니다.

  • CC: C 및 C++ 컴파일러 명령어입니다.

    다음 위치에는 항상 CC_FLAGS를 사용하는 것이 좋습니다. CC와 조합됩니다. 그러지 않으면 책임은 사용자에게 있습니다.

  • CC_FLAGS: genrules에서 사용할 수 있는 C/C++ 컴파일러의 최소 플래그 집합입니다. 특히 CC가 여러 아키텍처를 지원하는 경우 올바른 아키텍처를 선택하는 플래그가 포함되어 있습니다.
  • NM: 크로스툴의 'nm' 명령어입니다.
  • OBJCOPY: C/C++와 동일한 도구 모음의 objcopy 명령어 합니다.
  • STRIP: C/C++와 동일한 도구 모음의 스트립 명령어 합니다.

Java 도구 모음 변수

다음은 Java 도구 모음 규칙에 정의되어 있으며 toolchains = ["@bazel_tools//tools/jdk:current_java_runtime"](또는 호스트 도구 모음 등가 항목의 경우 "@bazel_tools//tools/jdk:current_host_java_runtime")를 설정하는 모든 규칙에서 사용할 수 있습니다.

JDK의 대부분의 도구는 직접 사용해서는 안 됩니다. 내장 Java 규칙은 인터페이스 Jar, 헤더 인터페이스 Jar, 고도로 최적화된 Jar 패키징 및 병합 구현과 같이 업스트림 도구가 표현할 수 있는 것보다 훨씬 더 정교한 접근 방식을 사용하여 Java 컴파일 및 패키징을 실행합니다.

이러한 변수는 드물게 있습니다. 이러한 기능을 사용하고 싶다면 먼저 Bazel 개발자에게 문의하세요.

  • JAVA: 'java' 명령어 (Java Virtual Private Cloud) 있습니다. 이를 방지하고 java_binary 규칙 사용 를 사용하세요. 상대 경로일 수 있습니다. java를 호출하기 전에 디렉터리를 변경해야 하는 경우 작업 디렉터리를 캡처한 후 변경해야 합니다.
  • JAVABASE: Java 유틸리티입니다. 상대 경로일 수 있습니다. 'bin' 하위 디렉터리가 있습니다.

Starlark 정의 변수

규칙 및 도구 모음 작성자가 정의할 수 있음 전체 맞춤 변수를 반환하여 TemplateVariableInfo 제공업체 그러면 toolchains 속성을 통해 이에 종속된 모든 규칙에서 값을 읽을 수 있습니다.

Starlark 정의 변수의 예 보기