'Make' 변수

• 용도
• 사전 정의된 변수
• 사전 정의된 genrule 변수
• 사전 정의된 소스/출력 경로 변수
• 맞춤 변수

'Make' 변수는 "Subject to 'Make피 변수' 대체"로 표시된 속성에 사용할 수 있는 확장 가능한 문자열 변수의 특별한 클래스입니다.

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

Bazel은 모든 대상에 사용할 수 있는 사전 정의된 변수와 종속 항목 대상에 정의되어 있고 이 변수에 종속된 대상에만 사용할 수 있는 맞춤 변수를 제공합니다.

'Make'라는 용어가 사용된 이유는 역사적 의미가 있습니다. 이러한 변수의 구문과 의미 체계는 원래 GNU Make와 일치하도록 고안되었습니다.

사용

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

my_attr = "prefix $(FOO) suffix"

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

my_attr = "prefix bar suffix"

FOO가 소비 대상에 알려진 변수에 해당하지 않으면 Bazel이 오류와 함께 실패합니다.

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

my_attr = "prefix $@ suffix"

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

사전 정의된 변수

사전 정의된 'Make' 변수는 모든 대상에서 'Subject to 'Make 변수' 대체'로 표시된 모든 속성에서 참조할 수 있습니다.

이러한 변수와 주어진 빌드 옵션 집합의 값을 보려면 다음을 실행합니다.

bazel info --show_make_env [build options]

대문자로 된 맨 위 출력 줄을 확인합니다.

사전 정의된 변수의 예 보기

도구 모음 옵션 변수

• COMPILATION_MODE: fastbuild, dbg 또는 opt입니다. (자세히 알아보기)

경로 변수

• 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: 출력 디렉터리 outs에 항목이 하나 있으면 이 파일이 포함된 디렉터리로 확장됩니다. 항목이 여러 개 있다면 모든 출력 파일이 동일한 하위 디렉터리에 있는 경우에도 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: 빌드된 바이너리가 런타임에 종속 항목을 찾기 위해 기본 저장소에 해당하는 실행 파일 디렉터리의 하위 디렉터리를 기준으로 한 경로를 나타냅니다. 참고: --enable_runfiles가 사용 설정된 경우에만 작동하며 Windows에서는 기본적으로 그렇지 않습니다. 크로스 플랫폼 지원에는 대신 rlocationpath를 사용하세요.

  execpath와 유사하지만 위에 설명된 구성 접두사를 제거합니다. 위의 예에서는 empty.source와 app가 모두 순수한 작업공간 기준 경로(testapp/empty.source 및 testapp/app)를 사용함을 의미합니다.

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

  여기에는 execpath와 동일한 '출력 1개만' 요구사항이 있습니다.

• rlocationpath: 런타임 시 실행 파일 디렉터리 (있는 경우)에서 또는 실행 파일 매니페스트를 사용하여 종속 항목을 찾기 위해 빌드된 바이너리가 runfile 라이브러리의 Rlocation 함수에 전달할 수 있는 경로입니다.

  구성 프리픽스를 포함하지 않는다는 점에서 rootpath와 비슷하지만 항상 저장소 이름으로 시작한다는 점이 다릅니다. 위의 예에서는 empty.source 및 app의 결과가 myproject/testapp/empty.source 및 myproject/testapp/app라는 결과로 이어집니다.

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

  런타임 시 종속 항목을 찾을 때 선호되는 방법은 이 경로를 바이너리에 전달하고 실행 파일 라이브러리를 사용하여 파일 시스템 경로로 확인하는 것입니다. rootpath와 비교하면 모든 플랫폼에서 작동하며 runfile 디렉터리를 사용할 수 없는 경우에도 작동한다는 장점이 있습니다.

  여기에는 execpath와 동일한 '출력 1개만' 요구사항이 있습니다.

• location: 확장되는 속성에 따라 execpath 또는 rootpath의 동의어입니다. 이는 Starlark 이전 버전의 기존 동작이며 특정 규칙에서 어떤 역할을 하는지 잘 모르는 경우에는 권장되지 않습니다. 자세한 내용은 #2475를 참고하세요.

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

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

라벨이 표준 형식일 필요는 없습니다. foo, :foo, //somepkg:foo 모두 괜찮습니다.

맞춤 변수

맞춤 'Make' 변수는 "Make 변수' 대체"로 표시된 모든 속성에서 참조할 수 있지만 이러한 변수를 정의하는 다른 타겟에 의존하는 타겟에서만 참조할 수 있습니다.

모든 변수는 코어 Bazel에 변수를 베이킹해야 하는 합당한 이유가 없는 한 모든 변수는 맞춤설정해야 합니다. 이렇게 하면 Bazel이 타레를 소비하는 데 관심이 없을 수도 있는 변수를 제공하기 위해 비용이 많이 들 수 있는 종속 항목을 로드하지 않아도 됩니다.

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: Crosstool의 'ar' 명령어
• C_COMPILER: C/C++ 컴파일러 식별자입니다(예: llvm).

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

  항상 CC와 함께 CC_FLAGS를 사용하는 것이 좋습니다. 그렇게 하지 않는 데 따르는 위험은 사용자가 감수해야 합니다.

• CC_FLAGS: genrules에서 사용할 수 있는 C/C++ 컴파일러의 최소 플래그 집합입니다. 특히 여기에는 CC가 여러 아키텍처를 지원하는 경우 올바른 아키텍처를 선택하는 플래그가 포함되어 있습니다.
• NM: Crosstool의 '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에 있는 대부분의 도구는 직접 사용해서는 안 됩니다. 기본 제공 Java 규칙은 인터페이스 Jars, 헤더 인터페이스 Jars, 고도로 최적화된 Jar 패키징 및 병합 구현 등 업스트림 도구에서 표현할 수 있는 것보다 훨씬 정교한 Java 컴파일 및 패키징 접근 방식을 사용합니다.

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

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

Starlark에서 정의한 변수

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

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