"Make" 변수

컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.

"Make" 변수는 "Subject &'MakeVariable' subplacement"로 표시된 속성에 사용 가능한 확장형 문자열 변수의 특수 클래스입니다.

이를 통해 특정 도구 모음 경로를 사용자가 구성한 빌드 작업에 삽입할 수 있습니다.

Bazel은 모든 종속 항목에서 사용할 수 있는 사전 정의된 변수와 종속 항목 대상에 정의되고 종속 항목에만 사용 가능한 커스텀 변수를 제공합니다.

'Make"'라는 용어는 이전부터 사용되었으며, 이러한 변수의 구문과 의미는 원래 GNU Make와 일치하도록 만들어졌습니다.

사용

my_attr = "prefix $(FOO) suffix"

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

my_attr = "prefix bar suffix"

FOO가 사용 중인 타겟에 알려진 변수에 상응하는 경우 Bazel이 오류와 함께 실패합니다.

또한 이름이 @가 아닌 문자 기호인 "Make" 변수는 괄호 없이 달러 기호만 사용하여 참조할 수 있습니다. 예를 들면 다음과 같습니다.

my_attr = "prefix $@ suffix"

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

사전 정의된 변수

모든 타겟에서 사전 정의된 'Make " 변수'를 "Subject &'Makevariable' subplacement"로 표시된 속성에서 참조할 수 있습니다.

이러한 변수 목록과 특정 빌드 옵션 세트의 값을 보려면 다음을 실행하세요.

bazel info --show_make_env [build options]

대문자가 있는 최상위 출력 줄을 살펴보겠습니다.

사전 정의된 변수의 예시 보기

도구 모음 옵션 변수

경로 변수

  • BINDIR: 타겟 아키텍처에 대해 생성된 바이너리 트리의 기본입니다.

    크로스 컴파일을 지원하기 위해 호스트 아키텍처의 빌드 중에 실행되는 프로그램에 다른 트리를 사용할 수 있습니다.

    genrule 내에서 도구를 실행하려면 $(execpath toolname)를 사용하여 경로를 가져올 것을 권장합니다. 여기서 toolnamegenruletools 속성에 나열해야 합니다.

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

머신 아키텍처 변수

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

사전 정의된 genrule 변수

이 속성은 genrulecmd 속성에 특별히 사용할 수 있으며 일반적으로 이 속성이 작동하도록 하는 데 중요합니다.

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

  • OUTS: genruleouts 목록입니다. 출력 파일이 하나뿐이면 $@을 사용할 수도 있습니다.
  • SRCS: genrulesrcs 목록 (또는 더 정확하게는 srcs 목록의 라벨에 해당하는 파일의 경로 이름)입니다. 소스 파일이 하나만 있다면 $<를 사용할 수도 있습니다.
  • <: SRCS(단일 파일인 경우) 그 외는 빌드 오류를 트리거합니다.
  • @: OUTS(단일 파일인 경우) 그 외는 빌드 오류를 트리거합니다.
  • RULEDIR: 타겟의 출력 디렉터리, 즉 genfiles 또는 bin 트리 아래에 타겟이 포함된 패키지의 이름에 상응하는 디렉터리 //my/pkg:my_genrule의 경우 //my/pkg:my_genrule의 출력이 하위 디렉터리에 있더라도 항상 my/pkg에서 종료됩니다.

  • @D: 출력 디렉터리입니다. outs 항목이 한 개 있는 경우 이 파일이 포함된 디렉터리로 확장됩니다. 항목이 여러 개 있다면 모든 출력 파일이 같은 하위 디렉터리에 있더라도 genfiles 트리의 패키지 루트 디렉터리로 확장됩니다.

    참고: RULEDIR는 시맨틱이 더 단순하고 출력 파일 수와 상관없이 동일한 방식으로 작동하기 때문에 @D보다 RULEDIR를 사용합니다.

    genrule이 임시 중간 파일을 생성해야 하는 경우 (예: 컴파일러와 같은 다른 도구를 사용한 결과) @D에 쓰기를 시도해야 합니다 (/tmp도 쓰기 가능하더라도). 종료하기 전에 삭제해야 합니다.

    특히 입력이 포함된 디렉터리에 쓰지 않는 것이 좋습니다. 읽기 전용 파일 시스템에 있을 수 있습니다. 그렇지 않으면 소스 트리가 휴지통으로 이동합니다.

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

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

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

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

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

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

    출력 파일은 비슷하게 스테이징되지만 하위 경로 bazel-out/cpu-compilation_mode/bin(또는 특정 출력의 경우 bazel-out/cpu-compilation_mode/genfiles 또는 호스트 도구의 출력의 경우 bazel-out/host/bin)로 시작됩니다. 위 예에서 bazel-out/cpu-compilation_mode/bin는 호스트 도구로, show_app_output 속성에 표시됩니다. 따라서 출력 파일 appbazel-myproject/bazel-out/host/bin/testapp/app에 작성됩니다. 따라서 실행 경로는 bazel-out/host/bin/testapp/app입니다. 이 추가 접두사를 사용하면 결과가 서로 클로버링되지 않고 동일한 빌드에 두 개의 다른 CPU를 사용하여 동일한 타겟을 빌드할 수 있습니다.

    이 변수에 전달된 라벨은 정확히 하나의 파일을 나타내야 합니다. 소스 파일을 나타내는 라벨의 경우 자동으로 true입니다. 규칙을 나타내는 라벨의 경우 정확히 1개의 출력이 생성됩니다. false이거나 라벨 형식이 잘못된 경우 오류가 발생하여 빌드가 실패합니다.

  • rootpath: 빌드된 바이너리가 런타임에 종속 항목을 찾는 데 사용할 수 있는 runfile 경로를 나타냅니다.

    이는 execpath과 동일하지만 위에 설명된 출력 접두사를 제거합니다. 위의 예에서 empty.sourceapp은 모두 작업공간 기준 경로인 testapp/empty.sourcetestapp/app을 사용합니다.

    이는 execpath와 동일한 요구사항만 있습니다.

  • location: 확장되는 속성에 따라 execpath 또는 rootpath의 동의어입니다. 이는 레거시 스타라크 동작이며 특정 규칙에 대해 실제로 어떻게 작동하는지 알고 있지 않는 한 권장되지 않습니다. 자세한 내용은 #2475를 참조하세요.

execpaths, rootpaths, locations는 각각 execpath, rootpath, location의 복수형입니다. 여러 출력을 생성하는 라벨을 지원합니다. 이러한 경우 각 출력이 공백으로 나열됩니다. 0 출력 규칙과 형식이 잘못된 라벨로 인해 빌드 오류가 발생합니다.

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

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

맞춤 변수

맞춤 '마켓' 변수는 "제목 및'만들기 변수' 대체로 표시된 모든 속성에서 참조할 수 있지만, 이러한 변수를 정의하는 다른 타겟에 의존하는 경우에만 사용됩니다.

모든 핵심 변수는 코어 Bazel에 베이킹해야 하는 정말 좋은 이유가 아니라면 모든 변수를 맞춤설정하는 것이 좋습니다. 이렇게 하면 Bazel이 Treet을 소비하는 변수를 공급하기 위해 비용이 많이 들 수 있는 종속 항목을 로드하지 않아도 됩니다.

C++ 도구 모음 변수

이는 C++ 도구 모음 규칙에 정의되며 toolchains = ["@bazel_tools//tools/cpp:current_cc_toolchain"] (또는 이에 상응하는 호스트 도구 모음의 경우 "@bazel_tools//tools/cpp:current_cc_host_toolchain")를 설정하는 모든 규칙에서 사용할 수 있습니다. java_binary와 같은 일부 규칙은 규칙 정의에 C++ 도구 모음을 암시적으로 포함합니다. 이러한 변수는 자동으로 상속됩니다.

기본 제공 C++ 규칙은 \'에서 컴파일러를 실행'하는 것보다 훨씬 더 정교합니다. 모듈을 사용하거나 포함하지 않는 *SAN, ThinLTO 등의 다양한 컴파일 모드를 지원하고, 여러 플랫폼에서 빠르게 테스트를 실행하는 동시에 신중하게 바이너리를 최적화하기 위해 기본 제공 규칙은 적절한 입력, 출력, 명령줄 플래그를 잠재적으로 내부적으로 생성되는 여러 작업에 설정하기 위해 매우 길게 적용됩니다.

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

  • ABI: C++ ABI 버전.
  • AR: 크로스 도구의 &&t&ar; 명령어입니다.
  • C_COMPILER: C/C++ 컴파일러 식별자(예: llvm)
  • CC: C 및 C++ 컴파일러 명령어

    항상 CC_FLAGSCC와 함께 사용하는 것을 적극 권장합니다. 그렇지 않으면 위험을 감수해야 합니다.

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

자바 도구 모음 변수

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

JDK의 도구 대부분을 직접 사용하면 안 됩니다. 기본 제공 자바 규칙은 인터페이스 항아리, 헤더 인터페이스 항, 고도로 최적화된 jar 패키징 및 병합 구현 등 업스트림 도구에서 표현할 수 있는 것보다 자바 컴파일 및 패키징에 대해 보다 정교한 접근 방식을 사용합니다.

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

  • JAVA: '"java" 명령어 (자바 가상 머신) 이러한 상황을 피하고 가능한 경우 대신 java_binary 규칙을 사용하세요. 상대 경로일 수 있습니다. java를 호출하기 전에 디렉터리를 변경해야 한다면 작업 디렉터리를 캡처한 후 변경해야 합니다.
  • JAVABASE: 자바 유틸리티가 포함된 기본 디렉터리입니다. 상대 경로일 수 있습니다. &bin에 하위 디렉터리가 있습니다.

Starlark 정의 변수

규칙 및 도구 모음 작성기는 TemplateVariableInfo 제공자를 반환하여 완전히 커스텀 변수를 정의할 수 있습니다. 그러면 toolchains 속성을 통해 이러한 규칙에 의존하는 모든 규칙이 값을 읽을 수 있습니다.

Starlark에서 정의한 변수의 예를 참고하세요.