Make Variables

문제 신고 소스 보기 Nightly · 8.3 · 8.2 · 8.1 · 8.0 · 7.6

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

'제조업체' 변수는 '제조업체 변수' 대체 대상으로 표시된 속성에 사용할 수 있는 특수한 확장 가능한 문자열 변수입니다.

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

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

'Make'라는 용어를 사용하는 이유는 역사적입니다. 이러한 변수의 구문과 의미는 원래 GNU Make와 일치하도록 의도되었습니다.

사용

'변수 만들기' 대체가 적용되는 속성은 다음과 같이 '제조업체' 변수 FOO를 참조할 수 있습니다.

my_attr = "prefix $(FOO) suffix"

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

my_attr = "prefix bar suffix"

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

이름이 @와 같은 비문자 기호인 'make' 변수는 괄호 없이 달러 기호만 사용하여 참조할 수도 있습니다. 예를 들면 다음과 같습니다.

my_attr = "prefix $@ suffix"

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

Predefined variables

Predefined "Make" variables can be referenced by any attribute marked as "Subject to 'Make variable' substitution" on any target.

To see the list of these variables and their values for a given set of build options, run

bazel info --show_make_env [build options]

and look at the top output lines with capital letters.

See an example of predefined variables.

Toolchain option variables

• COMPILATION_MODE: fastbuild, dbg, or opt. (more details)

Path variables

• BINDIR: The base of the generated binary tree for the target architecture.

  Note that a different tree may be used for programs that run during the build on the host architecture, to support cross-compiling.

  If you want to run a tool from within a genrule, the recommended way to get its path is $(execpath toolname), where toolname must be listed in the genrule's tools attribute.

• GENDIR: The base of the generated code tree for the target architecture.

Machine architecture variables

• TARGET_CPU: The target architecture's CPU, e.g. k8.

Predefined genrule variables

The following are specially available to genrule's cmd attribute and are generally important for making that attribute work.

See an example of predefined genrule variables.

• OUTS: The genrule's outs list. If you have only one output file, you can also use $@.
• SRCS: The genrule's srcs list (or more precisely: the path names of the files corresponding to labels in the srcs list). If you have only one source file, you can also use $<.
• <: SRCS, if it is a single file. Else triggers a build error.
• @: OUTS, if it is a single file. Else triggers a build error.

• RULEDIR: The output directory of the target, that is, the directory corresponding to the name of the package containing the target under the genfiles or bin tree. For //my/pkg:my_genrule this always ends in my/pkg, even if //my/pkg:my_genrule's outputs are in subdirectories.

• @D: The output directory. If outs has one entry, this expands to the directory containing that file. If it has multiple entries, this expands to the package's root directory in the genfiles tree, even if all output files are in the same subdirectory!

  Note: Use RULEDIR over @D because RULEDIR has simpler semantics and behaves the same way regardless of the number of output files.

  If the genrule needs to generate temporary intermediate files (perhaps as a result of using some other tool like a compiler), it should attempt to write them to @D (although /tmp will also be writable) and remove them before finishing.

  Especially avoid writing to directories containing inputs. They may be on read-only filesystems. Even if not, doing so would trash the source tree.

Note: If the filenames corresponding to the input labels or the output filenames contain spaces, ', or other special characters (or your genrule is part of a Starlark macro which downstream users may invoke on such files), then $(SRCS) and $(OUTS) are not suitable for interpolation into a command line, as they do not have the semantics that "${@}" would in Bash.

One workaround is to convert to a Bash array, with

mapfile SRCS <<< "$$(sed -e 's/ /\\n/g' <<'genrule_srcs_expansion'
$(SRC)
genrule_srcs_expansion
)을 작성한 다음 후속 명령줄에서 $(SRCS) 대신 "$$\{SRCS[@]}"을 사용합니다. 더 강력한 옵션은 대신 Starlark 규칙을 작성하는 것입니다.



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

  사전 정의된 변수 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를 사용한다는 의미입니다.
    
    

      외부 저장소 repo에 있는 파일의 rootpath는 ../repo/로 시작하고 저장소 관련 경로가 뒤따릅니다.
    
    

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

  

    

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

      구성 접두사를 포함하지 않는다는 점에서 rootpath와 유사하지만 항상 저장소 이름으로 시작한다는 점이 다릅니다. 위의 예시에서 이는 
      empty.source 및 app이 myproject/testapp/empty.source 및 
      myproject/testapp/app 경로를 생성한다는 의미입니다.
    
    

      외부 저장소 repo에 있는 파일의 rlocationpath는 repo/로 시작하고 저장소 관련 경로가 뒤따릅니다.
    
    

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

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

  

    location: 확장되는 속성에 따라 execpath 또는 rootpath의 동의어입니다. 이는 기존 Starlark 이전 동작이며 특정 규칙에 대해 어떤 작업을 하는지 잘 알지 못하는 한 권장되지 않습니다. 자세한 내용은 #2475를 참고하세요.
  



  execpaths, rootpaths, rlocationpaths, locations는 각각 execpath, rootpath, rlocationpath, location의 복수형입니다. 라벨은 여러 출력을 생성할 수 있으며, 이 경우 각 출력은 공백으로 구분되어 나열됩니다. 출력이 없는 규칙과 형식이 잘못된 라벨은 빌드 오류를 생성합니다.



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



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


맞춤 변수


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



  모든 변수는 핵심 Bazel에 포함할 만한 충분한 이유가 없는 한 맞춤설정해야 합니다. 이렇게 하면 Bazel이 타겟을 사용하는 변수가 신경 쓰지 않을 수 있는 잠재적으로 비용이 많이 드는 종속 항목을 로드하지 않아도 됩니다.


C++ 도구 모음 변수

  다음은 C++ 도구 모음 규칙에 정의되어 있으며 toolchains =
  ["@bazel_tools//tools/cpp:toolchain_type"]를 설정하는 모든 규칙에서 사용할 수 있습니다. 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: genrule에서 사용할 수 있는 C/C++ 컴파일러의 최소 플래그 집합입니다. 특히 여기에는 CC가 여러 아키텍처를 지원하는 경우 올바른 아키텍처를 선택하는 플래그가 포함되어 있습니다.
  


  
 DUMPBIN: Microsoft Visual Studio의 Microsoft COFF 바이너리 파일 덤퍼 (dumpbin.exe)입니다. 

  
 NM: crosstool의 'nm' 명령어입니다. 
  
 OBJCOPY: C/C++ 컴파일러와 동일한 스위트의 objcopy 명령어입니다. 

  
 STRIP: C/C++ 컴파일러와 동일한 제품군의 스트립 명령어입니다.


Java 도구 모음 변수


  다음은 Java 도구 모음 규칙에 정의되어 있으며 toolchains =
["@rules_java//toolchains:current_java_runtime"] (또는 호스트 도구 모음과 동등한 "@rules_java//toolchains:current_host_java_runtime")를 설정하는 모든 규칙에 사용할 수 있습니다.



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



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



  
 JAVA: 'java' 명령어 (Java 가상 머신) 가능한 경우 이 방법을 피하고 대신 java_binary 규칙을 사용하세요. 상대 경로일 수 있습니다. java를 호출하기 전에 디렉터리를 변경해야 하는 경우 변경하기 전에 작업 디렉터리를 캡처해야 합니다.
  

  
JAVABASE: Java 유틸리티가 포함된 기본 디렉터리입니다. 상대 경로일 수 있습니다. 'bin' 하위 디렉터리가 있습니다.
  


Starlark 정의 변수


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



  Starlark 정의 변수의 예시를 참고하세요.