BazelCon 2022는 11월 16~17일에 뉴욕과 온라인에서 개최됩니다.
지금 등록하기

명령어 및 옵션

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

이 페이지에서는 bazel build, bazel run, bazel test 등 다양한 Bazel 명령어에서 사용할 수 있는 옵션을 설명합니다. 이 페이지는 Bazel로 빌드의 Bazel 명령어 목록과 함께 사용할 수 있습니다.

대상 구문

build 또는 test과 같은 일부 명령어는 대상 목록에서 작동할 수 있습니다. 이는 빌드할 대상 지정에 설명된 대로 라벨보다 더 유연한 구문을 사용합니다.

옵션

다음 섹션에서는 빌드 중에 사용할 수 있는 옵션을 설명합니다. 도움말 명령어에 --long가 사용되면 온라인 도움말 메시지는 각 옵션의 의미, 유형, 기본값에 관한 요약 정보를 제공합니다.

대부분의 옵션은 한 번만 지정할 수 있습니다. 여러 번 지정되면 마지막 인스턴스가 적용됩니다. 여러 번 지정할 수 있는 옵션은 온라인 도움말에서 '여러 번 사용할 수 있음' 텍스트로 식별됩니다.

패키지 위치

--package_path

이 옵션은 지정된 패키지의 BUILD 파일을 찾기 위해 검색되는 디렉터리 집합을 지정합니다.

Bazel은 패키지 경로를 검색하여 패키지를 찾습니다. 이 목록은 부분 소스 트리의 루트가 되며 콜론으로 구분된 bazel 디렉터리 목록입니다.

--package_path 옵션을 사용하여 커스텀 패키지 경로를 지정하려면 다음 안내를 따르세요.

  % bazel build --package_path %workspace%:/some/other/root

패키지 경로 요소는 다음 세 가지 형식으로 지정할 수 있습니다.

  1. 첫 번째 문자가 /이면 절대 경로입니다.
  2. 경로가 %workspace%로 시작하면 가장 가까운 bazel 디렉터리를 기준으로 경로가 사용됩니다. 예를 들어 작업 디렉터리가 /home/bob/clients/bob_client/bazel/foo이면 package-path의 문자열 %workspace%/home/bob/clients/bob_client/bazel로 확장됩니다.
  3. 그 외 모든 항목은 작업 디렉터리를 기준으로 수행됩니다. 이는 대체로 의도한 작업이 아니며, bazel 작업공간 아래 디렉터리에서 Bazel을 사용하면 예기치 않게 동작할 수 있습니다. 예를 들어 package-path 요소 .를 사용한 다음 /home/bob/clients/bob_client/bazel/foo 디렉터리로 cd하면 /home/bob/clients/bob_client/bazel/foo 디렉터리에서 패키지가 확인됩니다. 에서 확인할 수 있습니다.

기본이 아닌 패키지 경로를 사용하는 경우 편의상 Bazel 구성 파일에 지정합니다.

Bazel은 현재 디렉터리에 패키지가 필요하지 않습니다. 따라서 필요한 모든 패키지를 패키지 경로의 다른 위치에서 찾을 수 있다면 빈 bazel 작업공간에서 빌드할 수 있습니다.

예: 빈 클라이언트에서 빌드

  % mkdir -p foo/bazel
  % cd foo/bazel
  % touch WORKSPACE
  % bazel build --package_path /some/other/path //foo

--deleted_packages

이 옵션은 Bazel이 삭제해야 할 패키지 목록을 쉼표로 구분하고 패키지 경로의 디렉터리에서 로드하려고 시도하지 않도록 지정합니다. 이 옵션을 사용하면 실제로 삭제하지 않는 패키지 삭제를 시뮬레이션할 수 있습니다.

확인 중 오류 발생

이러한 옵션은 Bazel의 오류 검사 또는 경고를 제어합니다.

--[no]check_visibility

이 옵션을 False로 설정하면 가시성 검사가 경고로 강등됩니다. 이 옵션의 기본값은 true이므로 기본적으로 가시성 확인이 수행됩니다.

--output_filter=regex

--output_filter 옵션은 정규 표현식과 일치하는 타겟의 빌드 및 컴파일 경고만 표시합니다. 대상이 지정된 정규 표현식과 일치하지 않고 실행이 성공하면 표준 출력 및 표준 오류가 발생합니다.

이 옵션의 일반적인 값은 다음과 같습니다.

`--output_filter='^//(첫 번째/프로젝트|두 번째/프로젝트):'` 지정된 패키지의 출력을 표시합니다.
`--output_filter='^//((?!(first/bad_project|second/bad_project):).)*$'` 지정된 패키지의 출력을 표시하지 않습니다.
`--output_filter=` 모두 표시
`--output_filter=DONT_MATCH_ANYTHING` 아무것도 표시하지 않습니다.

도구 플래그

이러한 옵션을 통해 Bazel에서 다른 도구로 전달할 옵션을 제어할 수 있습니다.

--copt=cc-option

이 옵션은 컴파일러에 전달되는 인수를 사용합니다. 인수는 C, C++, 어셈블러 코드 전처리, 컴파일 및 어셈블을 위해 호출될 때마다 컴파일러에 전달됩니다. 연결 시 전달되지 않습니다.

이 옵션은 여러 번 사용할 수 있습니다. 예:

  % bazel build --copt="-g0" --copt="-fpic" //foo

디버그 테이블 없이 foo 라이브러리를 컴파일하여 위치 독립적 코드를 생성합니다.

--host_copt=cc-option

이 옵션은 호스트 구성에서 컴파일되는 소스 파일의 컴파일러에 전달되는 인수를 사용합니다. --copt 옵션과 유사하지만 호스트 구성에만 적용됩니다.

--host_conlyopt=cc-option

이 옵션은 호스트 구성에서 컴파일된 C 소스 파일의 컴파일러에 전달되는 인수를 사용합니다. --conlyopt 옵션과 유사하지만 호스트 구성에만 적용됩니다.

--host_cxxopt=cc-option

이 옵션은 호스트 구성에서 컴파일된 C++ 소스 파일의 컴파일러에 전달되는 인수를 사용합니다. --cxxopt 옵션과 유사하지만 호스트 구성에만 적용됩니다.

--host_linkopt=linker-option

이 옵션은 호스트 구성에서 컴파일된 소스 파일의 링커에 전달되는 인수를 사용합니다. --linkopt 옵션과 유사하지만 호스트 구성에만 적용됩니다.

--conlyopt=cc-option

이 옵션은 C 소스 파일을 컴파일할 때 컴파일러에 전달되는 인수를 사용합니다.

이는 --copt와 유사하지만 C 컴파일에만 적용되며 C++ 컴파일 또는 연결에는 적용되지 않습니다. 따라서 --conlyopt을 사용하여 C 관련 옵션(예: -Wno-pointer-sign)을 전달할 수 있습니다.

--cxxopt=cc-option

이 옵션은 C++ 소스 파일을 컴파일할 때 컴파일러에 전달되는 인수를 사용합니다.

이는 --copt와 유사하지만 C 컴파일 또는 연결에는 적용되지 않고 C++ 컴파일에만 적용됩니다. 따라서 --cxxopt를 사용하여 C++ 관련 옵션(예: -fpermissive 또는 -fno-implicit-templates)을 전달할 수 있습니다.

예:

  % bazel build --cxxopt="-fpermissive" --cxxopt="-Wno-error" //foo/cruddy_code

--linkopt=linker-option

이 옵션은 연결 시 컴파일러에 전달되는 인수를 사용합니다.

이는 --copt와 비슷하지만 컴파일에만 적용되며 연결에만 적용됩니다. 따라서 --linkopt를 사용하여 연결 시에만 의미 있는 컴파일러 옵션 (예: -lssp 또는 -Wl,--wrap,abort)을 전달할 수 있습니다. 예:

  % bazel build --copt="-fmudflap" --linkopt="-lmudflap" //foo/buggy_code

빌드 규칙에서는 속성에 링크 옵션을 지정할 수도 있습니다. 이 옵션의 설정이 항상 우선 적용됩니다. cc_library.linkopts도 참고하세요.

--strip (always|never|sometimes)

이 옵션은 Bazel에서 -Wl,--strip-debug 옵션을 사용하여 링커를 호출하여 모든 바이너리와 공유 라이브러리에서 디버깅 정보를 제거할지 결정합니다. --strip=always은 항상 디버깅 정보를 삭제하는 것을 의미합니다. --strip=never는 디버깅 정보를 제거하지 않음을 의미합니다. --strip=sometimes의 기본값은 --compilation_modefastbuild인 경우 삭제를 의미합니다.

  % bazel build --strip=always //foo:bar

생성된 모든 바이너리에서 디버깅 정보를 제거하면서 타겟을 컴파일합니다.

Bazel의 --strip 옵션은 ld의 --strip-debug 옵션과 일치합니다. 디버깅 정보만 제거합니다. 어떤 이유로든 debug 기호뿐만 아니라 모든 기호를 삭제하려면 ld의 --strip-all 옵션을 사용해야 합니다. --linkopt=-Wl,--strip-all를 Bazel에 전달하면 됩니다. 또한 Bazel의 --strip 플래그를 설정하면 --linkopt=-Wl,--strip-all이 재정의되므로 둘 중 하나만 설정해야 합니다.

단일 바이너리만 빌드하고 모든 기호를 제거하려는 경우 --stripopt=--strip-all을 전달하고 타겟의 //foo:bar.stripped 버전을 명시적으로 빌드할 수도 있습니다. --stripopt의 섹션에 설명한 것처럼 이는 빌드의 모든 링크 작업에 제거를 포함하지 않고 최종 바이너리가 연결된 후에 제거 작업을 적용합니다.

--stripopt=strip-option

*.stripped 바이너리를 생성할 때 strip 명령어에 전달하는 추가 옵션입니다. 기본값은 -S -p입니다. 이 옵션은 여러 번 사용할 수 있습니다.

--fdo_instrument=profile-output-dir

--fdo_instrument 옵션을 사용하면 빌드된 C/C++ 바이너리가 실행될 때 FDO (의견 중심 최적화) 프로필 출력을 생성할 수 있습니다. GCC의 경우 제공된 인수가 각 .o 파일의 프로필 정보가 포함된 .gcda 파일의 객체별 파일 디렉터리 트리의 디렉터리 프리픽스로 사용됩니다.

프로필 데이터 트리가 생성되면 프로필 트리를 압축하여 FDO 최적화 컴파일을 사용 설정하는 --fdo_optimize=profile-zip Bazel 옵션에 제공해야 합니다.

LLVM 컴파일러의 경우 인수는 원시 LLVM 프로필 데이터 파일이 덤프되는 디렉터리이기도 합니다. 예: --fdo_instrument=/path/to/rawprof/dir/.

--fdo_instrument--fdo_optimize 옵션은 동시에 사용할 수 없습니다.

--fdo_optimize=profile-zip

--fdo_optimize 옵션을 사용하면 컴파일 시 객체별 파일 프로필 정보를 사용하여 FDO (의견 지향 최적화)를 최적화할 수 있습니다. GCC의 경우 제공된 인수는 각 .o 파일의 프로필 정보가 포함된 .gcda 파일의 이전에 생성된 파일 트리를 포함하는 zip 파일입니다.

또는 제공된 인수가 확장자 .afdo로 식별된 자동 프로필을 가리킬 수 있습니다.

LLVM 컴파일러의 경우 제공된 인수는 llvm-procdata 도구에서 준비한 색인이 생성된 LLVM 프로필 출력 파일을 가리켜야 하고 .procdata 확장자가 있어야 합니다.

--fdo_instrument--fdo_optimize 옵션은 동시에 사용할 수 없습니다.

--[no]output_symbol_counts

사용 설정되면 C++ 실행 바이너리의 골드 호출 링크가 각각 출력됩니다.기호 수 파일 (--print-symbol-counts 골드 옵션). 각 링커 입력에 대해 파일은 정의된 기호의 수와 바이너리에서 사용된 기호의 수를 로깅합니다. 이 정보는 불필요한 링크 종속 항목을 추적하는 데 사용할 수 있습니다. 기호 수 파일은 바이너리의 출력 경로에 이름이 [targetname].sc로 기록됩니다.

이 옵션은 기본적으로 사용 중지되어 있습니다.

--java_language_version=version

이 옵션은 자바 소스의 버전을 지정합니다. 예:

  % bazel build --java_language_version=8 java/com/example/common/foo:all

자바 8 사양과 호환되는 구성만 컴파일하고 허용합니다. 기본값은 11입니다. --> 가능한 값은 8, 9, 10, 11, 14, 15이며 default_java_toolchain을 사용하여 커스텀 자바 도구 모음을 등록하면 확장될 수 있습니다.

--tool_java_language_version=version

빌드 중에 실행되는 도구를 빌드하는 데 사용되는 자바 언어 버전입니다. 기본값은 11입니다.

--java_runtime_version=version

이 옵션은 코드를 실행하고 테스트를 실행하는 데 사용할 JVM 버전을 지정합니다. 예:

  % bazel run --java_runtime_version=remotejdk_11 java/com/example/common/foo:java_application

원격 저장소에서 JDK 11을 다운로드하고 이를 사용하여 자바 애플리케이션을 실행합니다.

기본값은 localjdk입니다. 가능한 값은 localjdk, localjdk_version, remotejdk_11, remote_jdk17입니다. local_java_repository 또는 remote_java_repostory 저장소 규칙을 사용하여 맞춤 JVM을 등록하여 값을 확장할 수 있습니다.

--tool_java_runtime_version=version

빌드 중에 필요한 도구를 실행하는 데 사용되는 JVM 버전입니다. 기본값은 remotejdk_11입니다.

--jvmopt=jvm-option

이 옵션을 사용하면 자바 VM에 옵션 인수를 전달할 수 있습니다. 큰 인수 1개와 함께 사용하거나 개별 인수와 함께 여러 번 사용할 수 있습니다. 예:

  % bazel build --jvmopt="-server -Xms256m" java/com/example/common/foo:all

서버 VM을 사용하여 모든 자바 바이너리를 실행하고 VM의 시작 힙 크기를 256MB로 설정합니다.

--javacopt=javac-option

이 옵션을 사용하면 javac에 옵션 인수를 전달할 수 있습니다. 큰 인수 1개와 함께 사용하거나 개별 인수와 함께 여러 번 사용할 수 있습니다. 예:

  % bazel build --javacopt="-g:source,lines" //myprojects:prog

(bazel 기본값 대신 javac 기본 디버그 정보를 사용하여 java_binary를 다시 빌드합니다.)

이 옵션은 Bazel 기본 제공 기본 옵션 후 javac 및 규칙별 옵션 앞에 javac로 전달됩니다. 모든 javac 옵션의 사양이 적용됩니다. javac의 기본 옵션은 다음과 같습니다.

  -source 8 -target 8 -encoding UTF-8
-extra_checks[:(off|on)]

이 javac 옵션을 사용하면 추가 정확성 확인이 사용 설정됩니다. 발견된 문제는 모두 오류로 표시됩니다. -extra_checks 또는 -extra_checks:on를 사용하여 강제로 검사를 사용 설정할 수 있습니다. -extra_checks:off는 분석을 완전히 사용 중지합니다. 이 옵션을 지정하지 않으면 기본 동작이 사용됩니다.

--strict_java_deps (default|strict|off|warn|error)

이 옵션은 javac에서 누락된 직접 종속 항목이 있는지 여부를 제어합니다. 자바 타겟은 직접 사용되는 모든 타겟을 종속 항목으로 명시적으로 선언해야 합니다. 이 플래그는 javac가 각 자바 파일의 유형 확인에 실제로 사용되는 jar를 확인하도록 지시하고, 현재 대상의 직접 종속 항목의 출력이 아닌 경우 경고/오류를 표시합니다.

  • off는 검사가 사용 중지되어 있음을 의미합니다.
  • warn은 javac가 누락된 각 직접 종속 항목에 대해 [strict] 유형의 표준 자바 경고를 생성한다는 것을 의미합니다.
  • default, stricterror는 모든 평균 javac가 경고 대신 오류를 생성하므로 누락된 직접 종속 항목이 발견되면 현재 대상이 빌드되지 않습니다. 이는 플래그가 지정되지 않은 경우의 기본 동작이기도 합니다.

빌드 시맨틱스

이러한 옵션은 빌드 명령어 또는 출력 파일 콘텐츠에 영향을 줍니다.

--compilation_mode (fastbuild|opt|dbg) (-c)

--compilation_mode 옵션 (일반적으로-c 특히-c opt )는fastbuild ,dbg 또는opt 이는 최적화 수준 및 디버그 테이블의 완전성과 같은 다양한 C/C++ 코드 생성 옵션에 영향을 미칩니다. Bazel은 컴파일 모드마다 다른 출력 디렉터리를 사용하므로 매번 완전히 다시 빌드할 필요 없이 모드 간에 전환할 수 있습니다.

  • fastbuild는 가능한 한 빨리 빌드한다는 것을 의미합니다. 최소한의 디버깅 정보 (-gmlt -Wl,-S)를 생성하고 최적화하지 마세요. 이것이 기본값입니다. 참고: -DNDEBUG는 설정되지 않습니다.
  • dbg는 gdb 또는 다른 디버거를 사용할 수 있도록 디버깅이 사용 설정된 상태로 빌드(-g)된다는 의미입니다.
  • opt최적화가 사용 설정되어 있고assert() 통화 사용 중지됨 (-O2 -DNDEBUG ). 디버깅 정보는 다음에서 생성되지 않습니다.opt 모드를 통과하지 못한 경우--copt -g 에서 확인할 수 있습니다.

--cpu=cpu

이 옵션은 빌드 중에 바이너리를 컴파일하는 데 사용할 타겟 CPU 아키텍처를 지정합니다.

--action_env=VAR=VALUE

모든 작업 실행 중에 사용할 수 있는 환경 변수 집합을 지정합니다. 변수는 호출 환경에서 가져온 값(이름)으로 지정되거나 호출 환경과 관계없이 값을 설정하는 name=value 쌍으로 지정될 수 있습니다.

--action_env 플래그는 여러 번 지정할 수 있습니다. 여러 --action_env 플래그에서 값이 동일한 변수에 할당되면 최신 할당이 적용됩니다.

--experimental_action_listener=label

experimental_action_listener 옵션은 Bazel이 label에서 지정한 action_listener 규칙의 세부정보를 사용하여 extra_actions을 삽입하도록 지시합니다. 있습니다.

--[no]experimental_extra_action_top_level_only

이 옵션이 true로 설정되면 --experimental_action_listener 명령줄 옵션에서 지정된 추가 작업이 최상위 대상에 대해서만 예약됩니다.

--experimental_extra_action_filter=regex

experimental_extra_action_filter 옵션은 Bazel에 extra_actions를 예약할 타겟 집합을 필터링하도록 지시합니다.

이 플래그는 --experimental_action_listener 플래그와 함께만 사용할 수 있습니다.

기본적으로 요청된 target-to-build 타겟의 전이 클로저에서 extra_actions가 모두 실행되도록 예약됩니다. --experimental_extra_action_filter은 소유자의 라벨이 지정된 정규 표현식과 일치하는 extra_actions으로 예약을 제한합니다.

다음 예시에서는 소유자 라벨에 '/bar/'가 포함된 작업에만 적용되도록 extra_actions 예약을 제한합니다.

% bazel build --experimental_action_listener=//test:al //foo/... \
  --experimental_extra_action_filter=.*/bar/.*

--host_cpu=cpu

이 옵션은 호스트 도구를 빌드하는 데 사용해야 하는 CPU 아키텍처의 이름을 지정합니다.

--fat_apk_cpu=cpu[,cpu]*

android_binary 규칙의 전이 deps에서 C/C++ 라이브러리를 빌드할 CPU입니다. 다른 C/C++ 규칙은 영향을 받지 않습니다. 예를 들어 cc_libraryandroid_binary 규칙 및 cc_binary 규칙의 전이 deps에 나타날 경우 cc_library가 최소 두 번 빌드됩니다. android_binary 규칙에 --fat_apk_cpu로 지정된 각 CPU에 대해 한 번 그리고 cc_binary 규칙에 대해 --cpu로 지정된 CPU에 대해 한 번.

기본값은 armeabi-v7a입니다.

한 개의 .so 파일이 생성되어 --fat_apk_cpu로 지정된 각 CPU의 APK에 패키징됩니다. .so 파일의 이름은 android_binary 규칙의 이름 앞에 'lib'를 추가합니다. 예를 들어 android_binary의 이름이 'foo'이면 파일은 libfoo.so입니다.

--per_file_copt=[+-]regex[,[+-]regex]...@option[,option]...

포함 정규 표현식 중 하나와 일치하고 제외 표현식과 일치하지 않는 라벨 또는 실행 경로가 있는 모든 C++ 파일은 지정된 옵션으로 빌드됩니다. 라벨 일치는 라벨의 표준 형식을 사용합니다(예: //package:label_name).

실행 경로는 C++ 파일의 기본 이름(확장 프로그램 포함)을 포함한 작업공간 디렉터리에 대한 상대 경로입니다. 또한 플랫폼에 종속된 모든 접두어도 포함됩니다.

생성된 파일 (예: genrule 출력)과 일치시키기 위해 Bazel은 실행 경로만 사용할 수 있습니다. 이 경우 정규식은 '//'로 시작해서는 안 됩니다. 이는 어떤 실행 경로와도 일치하지 않기 때문입니다. 패키지 이름은 --per_file_copt=base/.*\.pb\.cc@-g0와 같이 사용할 수 있습니다. 이는 base라는 디렉터리에 있는 모든 .pb.cc 파일과 일치합니다.

이 옵션은 여러 번 사용할 수 있습니다.

이 옵션은 사용된 컴파일 모드에 관계없이 적용됩니다. 예를 들어 --compilation_mode=opt로 컴파일하고 더 강력한 최적화가 사용 설정되어 있거나 최적화가 사용 중지된 일부 파일을 선택적으로 컴파일할 수 있습니다.

주의사항: 일부 파일이 디버그 기호로 선택적으로 컴파일되는 경우 연결 중에 기호가 제거될 수 있습니다. 이를 방지하려면 --strip=never를 설정하면 됩니다.

구문: [+-]regex[,[+-]regex]...@option[,option]... 여기서 regex+로 시작되어 포함 패턴을 식별하고 -를 제외 패턴을 식별합니다. option는 C++ 컴파일러에 전달되는 임의 옵션을 나타냅니다. 옵션에 ,가 포함된 경우 \,와 같이 따옴표를 사용해야 합니다. 옵션에는 @도 포함될 수 있습니다. 첫 번째 @만 정규 표현식을 옵션과 구분하는 데 사용되기 때문입니다.

: --per_file_copt=//foo:.*\.cc,-//foo:file\.cc@-O0,-fprofile-arcs는 모든 .cc 파일의 C++ 컴파일러에 -O0-fprofile-arcs 옵션을 추가합니다. file.cc을(를) 제외한 //foo/에서

--dynamic_mode=mode

C++ 바이너리가 동적으로 연결되는지, 빌드 규칙의 linkstatic 속성과 상호작용하는지 확인합니다.

모드:

  • auto: 플랫폼에 종속된 모드로 변환됩니다. Linux의 경우 default, cygwin의 경우 off입니다.
  • default: bazel이 동적으로 연결할지 선택할 수 있습니다. 자세한 내용은 linkstatic을 참조하세요.
  • fully: 모든 타겟을 동적으로 연결합니다. 이렇게 하면 연결 시간이 단축되고 결과 바이너리의 크기가 줄어듭니다.
  • off: 대부분 정적 모드인 모든 대상을 연결합니다. linkopt에 -static가 설정된 경우 타겟이 완전 정적으로 변경됩니다.

--fission (yes|no|[dbg][,opt][,fastbuild])

.o 파일 대신 C++ 디버그 정보를 C. 디버그 파일에 쓰는 Fission을 사용 설정합니다. 이 경우 그렇지 않습니다. 이렇게 하면 링크의 입력 크기가 상당히 줄어들며 링크 시간도 줄어듭니다.

[dbg][,opt][,fastbuild]로 설정하면 (예: --fission=dbg,fastbuild) 지정된 컴파일 모드 집합에만 결합이 사용 설정됩니다. 이는 bazelrc 설정에 유용합니다. yes로 설정하면 통합이 전체적으로 사용 설정됩니다. no로 설정하면 통합이 범용적으로 사용 중지됩니다. 기본값은 no입니다.

--force_ignore_dash_static

이 플래그가 설정되면 cc_* 규칙 BUILD 파일의 과정에 있는 -static 옵션이 무시됩니다. 이는 C++ 강화 빌드의 해결 방법만을 대상으로 합니다.

--[no]force_pic

사용 설정되면 모든 C++ 컴파일이 위치 독립적 코드 ('-fPIC')를 생성하고, 링크는 PIC가 아닌 라이브러리보다 PIC가 사전 빌드된 라이브러리를 선호하고, 링크는 위치 독립적 실행 파일 ('-pie')을 생성합니다. 에서 확인할 수 있습니다. 기본값은 사용 중지입니다.

--android_resource_shrinking

android_binary 규칙에 대한 리소스 축소를 실행할지 선택합니다. android_binary 규칙에서는 축소할_리소스 속성의 기본값을 설정합니다. 자세한 내용은 이 규칙의 문서를 참고하세요. 기본값은 꺼짐입니다.

--custom_malloc=malloc-library-target

이 플래그를 지정하면 항상 지정된 malloc 구현을 사용하고 malloc을 지정하지 않고 기본값을 사용하는 타겟을 포함하여 모든 malloc="target" 속성이 재정의됩니다.

--crosstool_top=label

이 옵션은 빌드 중에 모든 C++ 컴파일에 사용될 크로스도구 컴파일러 모음의 위치를 지정합니다. Bazel이 CROSSTOOL 파일에서 이 위치를 찾아 이를 사용하여 --compiler 설정을 자동으로 결정합니다.

--host_crosstool_top=label

지정하지 않으면 Bazel은 --crosstool_top 값을 사용하여 빌드 중에 실행되는 도구와 같은 호스트 구성에서 코드를 컴파일합니다. 이 플래그의 주요 목적은 크로스 컴파일을 사용 설정하는 것입니다.

--apple_crosstool_top=label

objc*, ios*, Apple* 규칙의 전이 deps에서 C/C++ 규칙을 컴파일하는 데 사용되는 크로스툴입니다. 이러한 대상의 경우 이 플래그는 --crosstool_top를 덮어씁니다.

--android_crosstool_top=label

android_binary 규칙의 전이 deps에서 C/C++ 규칙을 컴파일하는 데 사용되는 크로스 도구 이는 빌드의 다른 대상에 다른 크로스도구가 필요한 경우에 유용합니다. 기본값은 WORKSPACE 파일의 android_ndk_repository 규칙에 의해 생성된 교차 도구를 사용하는 것입니다. --fat_apk_cpu도 참조하세요.

--compiler=version

이 옵션은 빌드 중에 바이너리 컴파일에 사용할 C/C++ 컴파일러 버전 (예: gcc-4.1.0)을 지정합니다. 커스텀 교차 도구를 사용하여 빌드하려면 이 플래그를 지정하는 대신 CROSSTOOL 파일을 사용해야 합니다.

--android_sdk=label

이 옵션은 Android 관련 규칙을 빌드하는 데 사용될 Android SDK/플랫폼 도구 모음과 Android 런타임 라이브러리를 지정합니다.

android_sdk_repository 규칙이 WORKSPACE 파일에 정의된 경우 Android SDK가 자동으로 선택됩니다.

--java_toolchain=label

이 옵션은 자바 소스 파일을 컴파일하는 데 사용되는 java_toolchain의 라벨을 지정합니다.

--host_java_toolchain=label

지정하지 않으면 bazel은 --java_toolchain 값을 사용하여 빌드 중에 실행되는 도구와 같이 호스트 구성에서 코드를 컴파일합니다. 이 플래그의 주요 목적은 크로스 컴파일을 사용 설정하는 것입니다.

--javabase=(label)

이 옵션은라벨 기본 자바 설치의Bazel Run ,bazel 테스트, 그리고java_binaryjava_test 있습니다. JAVABASEJAVA 'Make' 변수는 이 옵션에서 파생됩니다.

--host_javabase=label

이 옵션은 호스트 구성에서 사용할 기본 자바 설치의 label을 설정합니다(예: JavaBuilder 및 Singlejar를 포함한 호스트 빌드 도구).

자바 소스 파일을 컴파일하는 데 사용되는 자바 컴파일러는 선택하지 않습니다. 컴파일러는 --java_toolchain 옵션을 설정하여 선택할 수 있습니다.

실행 전략

이러한 옵션은 Bazel에서 빌드를 실행하는 방식에 영향을 줍니다. 빌드에 의해 생성된 출력 파일에는 큰 영향을 미치지 않습니다. 일반적으로 주요 효과는 빌드 속도에 있습니다.

--spawn_strategy=strategy

이 옵션은 명령어가 실행되는 위치와 방법을 제어합니다.

  • standalone는 명령어가 로컬 하위 프로세스로 실행되도록 합니다. 이 값은 지원 중단되었습니다. 대신 local 열을 사용하세요.
  • sandboxed는 로컬 머신의 샌드박스 내에서 명령어가 실행되도록 합니다. 이를 위해서는 모든 입력 파일, 데이터 종속 항목 및 도구가 srcs, data, tools 속성에 직접 종속 항목으로 표시되어야 합니다. Bazel은 샌드박스 실행을 지원하는 시스템에서 기본적으로 로컬 샌드박스를 사용 설정합니다.
  • local는 명령어가 로컬 하위 프로세스로 실행되도록 합니다.
  • worker은 영구 작업자(사용 가능한 경우)를 사용하여 명령어가 실행되도록 합니다.
  • docker은 로컬 머신의 Docker 샌드박스 내에서 명령어가 실행되도록 합니다. 이를 위해서는 docker가 설치되어 있어야 합니다.
  • remote는 명령어가 원격으로 실행되도록 합니다. 이는 원격 실행자가 별도로 구성된 경우에만 사용할 수 있습니다.

--strategy mnemonic=strategy

이 옵션은 명령을 실행하는 위치와 방법을 제어하여--spawn_strategy (및--genrule_strategy 니모닉으로 구성됩니다. 지원되는 전략과 효과는 --spawn_strategy를 참조하세요.

--strategy_regexp=<filter,filter,...>=<strategy>

이 옵션은 특정 regex_filter와 일치하는 설명이 있는 명령어를 실행하는 데 사용할 전략을 지정합니다. regex_filter 일치에 대한 자세한 내용은 --per_file_copt를 참조하세요. 지원되는 전략과 효과는 --spawn_strategy를 참조하세요.

설명과 일치하는 마지막 regex_filter가 사용됩니다. 이 옵션은 전략을 지정하기 위한 다른 플래그를 재정의합니다.

  • 예: --strategy_regexp=//foo.*\\.cc,-//foo/bar=local은 설명이 //foo.*.cc와 일치하지만 //foo/bar와 일치하지 않는 경우 local 전략을 사용하여 작업을 실행한다는 의미입니다.
  • 예: --strategy_regexp='Compiling.*/bar=local' --strategy_regexp=Compiling=sandboxedsandboxed 전략으로 '//foo/bar/baz'를 컴파일하지만 순서를 반대로 하면 local로 실행됩니다.
  • 예: --strategy_regexp='Compiling.*/bar=local,sandboxed'local 전략으로 'foo/bar/baz 컴파일'을 실행하고 실패하면 sandboxed로 대체됩니다.

--genrule_strategy=strategy

지원 중단된 --strategy=Genrule=strategy 약어입니다.

--jobs=n (-j)

정수 인수를 취하는 이 옵션은 빌드의 실행 단계에서 동시에 실행해야 하는 작업 수를 지정합니다.

--progress_report_interval=n

Bazel은 주기적으로 완료되지 않은 작업 (예: 장기 실행 테스트)의 진행률 보고서를 주기적으로 출력합니다. 이 옵션은 보고 빈도를 설정합니다. 진행률은 n초마다 출력됩니다.

기본값은 0이며, 이는 증분 알고리즘을 의미합니다. 첫 번째 보고서는 10초 후에 출력되고 30초 후에 출력되며 진행률은 1분마다 보고됩니다.

--local_{ram,cpu}_resources resources or resource expression

이러한 옵션은 Bazel이 로컬에서 실행할 빌드 및 테스트 활동을 예약할 때 고려할 수 있는 로컬 리소스 양 (MB 단위의 RAM과 CPU 논리 코어 수)을 지정합니다. 정수 또는 키워드 (HOST_RAM 또는 HOST_CPUS)를 선택적으로 취할 수 있습니다.[-|* 부동 소수점] (예:--local_cpu_resources=2 ,--local_ram_resources=HOST_RAM*.5 ,--local_cpu_resources=HOST_CPUS-1 플래그는 독립적이어야 합니다. 둘 중 하나만 설정할 수 있습니다. 기본적으로 Bazel은 로컬 시스템 구성에서 직접 RAM의 크기와 CPU 코어의 수를 추정합니다.

기본적으로 사용 설정되는 이 옵션은 테스트 및 바이너리의 실행 파일 심볼릭 링크를 출력 디렉터리에 빌드해야 하는지 여부를 지정합니다. --nobuild_runfile_links를 사용하면 실행 파일 트리 빌드에 오버헤드가 발생하지 않고 모든 타겟을 컴파일할 수 있습니다.

테스트 (또는 애플리케이션)가 실행되면 런타임 데이터 종속 항목이 한곳에 수집됩니다. Bazel의 출력 트리 내에서 이 'runfiles' 트리는 일반적으로 상응하는 바이너리 또는 테스트의 동위로 루팅됩니다. 테스트를 실행하는 동안 $TEST_SRCDIR/workspace/packagename/filename 형식의 경로를 사용하여 실행 파일에 액세스할 수 있습니다. 실행 파일 트리를 사용하면 테스트에서 종속 항목이 선언된 모든 파일에 액세스할 수 있습니다. 기본적으로 실행 파일 트리는 필수 파일에 대한 기호화된 링크 집합을 생성하여 구현됩니다. 링크 세트가 커질수록 운영 비용이 증가하며, 일부 대규모 빌드의 경우 특히 각 개별 테스트 (또는 애플리케이션)에 자체 테스트 또는 NOS가 필요하기 때문에 전체 빌드 시간에 상당한 영향을 미칠 수 있습니다. runfiles 트리.

--[no]build_runfile_manifests

기본적으로 사용 설정되는 이 옵션은 실행 파일 매니페스트를 출력 트리에 쓸지 여부를 지정합니다. 사용 중지하면 --nobuild_runfile_links가 암시됩니다.

로컬에서 실행 파일 트리가 메모리 내 매니페스트에서 원격으로 생성되므로 테스트를 원격으로 실행할 때 사용 중지할 수 있습니다.

--[no]discard_analysis_cache

이 옵션을 사용하면 Bazel이 실행 전에 분석 캐시를 삭제하여 실행 단계를 위해 추가 메모리(약 10%)를 확보합니다. 단점은 증분 빌드가 더 느려진다는 것입니다. 메모리 절약 모드도 참조하세요.

--[no]keep_going (-k)

GNU Make에서와 마찬가지로 첫 번째 오류가 발생하면 빌드의 실행 단계가 중지됩니다. 오류가 발생하더라도 최대한 많이 빌드하는 것이 유용한 경우가 있습니다. 이 옵션을 사용하면 이 동작을 사용할 수 있고, 이 옵션을 지정하면 빌드에서 기본 요건을 충족하는 모든 대상을 빌드하려고 시도하지만 오류는 무시됩니다.

이 옵션은 일반적으로 빌드의 실행 단계와 관련이 있지만 분석 단계에도 영향을 줍니다. 빌드 명령어에 여러 타겟이 지정되어 있지만 그중 일부는 성공적으로 분석될 수 있는 경우입니다. --keep_going가 지정되지 않으면 빌드가 중지되고 이 경우 빌드가 실행 단계로 진행됩니다(성공적으로 분석된 대상의 경우에만).

--[no]use_ijars

이 옵션은 Bazel에서 java_library 타겟을 컴파일하는 방법을 변경합니다. Bazel은 종속 java_library 타겟을 컴파일하기 위해 java_library의 출력을 사용하는 대신 비공개가 아닌 멤버의 서명(공개, 기본 액세스 패키지 및 필드)와 인터페이스 jar를 사용하여 종속 타겟을 컴파일합니다. 이렇게 하면 메서드의 본문이나 비공개 멤버만 변경될 때 재컴파일이 방지됩니다.

--[no]interface_shared_objects

이 옵션을 사용하면 인터페이스 공유 객체가 사용 설정되므로 바이너리와 기타 공유 라이브러리가 구현이 아닌 공유 객체의 인터페이스에 종속됩니다. 구현만 변경되면 Bazel은 변경된 공유 라이브러리에 종속되는 대상을 불필요하게 다시 빌드하지 않을 수 있습니다.

출력 선택

이러한 옵션에 따라 빌드하거나 테스트할 항목이 결정됩니다.

--[no]build

이 옵션을 사용하면 빌드 실행 단계가 실행됩니다. 기본적으로 사용 설정되어 있습니다. 사용 중지되면 실행 단계를 건너뛰고 로드 및 분석 중 처음 두 단계만 발생합니다.

이 옵션은 실제로 아무것도 빌드하지 않고도 BUILD 파일을 검증하고 입력에서 오류를 감지하는 데 유용할 수 있습니다.

--[no]build_tests_only

이 플래그를 지정하면 Bazel이*_testtest_suite 필터링되지 않은 규칙을size[크기] ,시간 제한 ,태그 또는언어 에서 확인할 수 있습니다. 이 플래그를 지정하면 Bazel이 명령줄에 지정된 다른 대상을 무시합니다. 기본적으로 이 옵션은 사용 중지되며, Bazel이 테스트에서 필터링된 *_testtest_suite 규칙을 비롯하여 요청된 모든 항목을 빌드합니다. 이 메서드는 bazel test --build_tests_only foo/...를 실행할 경우 foo 트리에서 모든 빌드 손상을 감지하지 못할 수 있으므로 유용합니다.

--[no]check_up_to_date

이 옵션을 사용하면 Bazel이 빌드를 수행하지 않고 지정된 모든 대상이 최신 상태인지만 확인합니다. 이 경우 빌드가 정상적으로 완료됩니다. 그러나 파일이 오래된 경우 빌드되는 대신 오류가 보고되고 빌드가 실패합니다. 이 옵션은 빌드 비용을 들이지 않고도 빌드가 소스 수정보다 최근에 수행되었는지 (예: 사전 제출 검사) 판단하는 데 유용할 수 있습니다.

--check_tests_up_to_date도 참조하세요.

--[no]compile_one_dependency

인수 파일의 단일 종속 항목을 컴파일합니다. 예를 들어 수정/빌드/테스트 주기에서 소스 파일에 종속된 단일 대상을 다시 빌드하여 오류를 최대한 빨리 감지하는 등 IDE의 소스 파일을 구문 확인하는 데 유용합니다. 이 인수는 플래그가 아닌 모든 인수가 해석되는 방식에 영향을 줍니다. 각 인수는 파일 대상 라벨이거나 현재 작업 디렉터리를 기준으로 일반 파일 이름이어야 하고 각 소스 파일 이름에 종속되는 규칙이어야 합니다. 빌드되었습니다. 사유

C++ 및 자바 소스, 동일한 언어 공간의 규칙이 우선적으로 선택됩니다. 같은 환경설정의 여러 규칙이 있는 경우 BUILD 파일에서 처음 표시되는 규칙이 선택됩니다. 소스 파일을 참조하지 않고 명시적으로 이름이 지정된 대상 패턴에서는 오류가 발생합니다.

--save_temps

--save_temps 옵션을 사용하면 컴파일러의 임시 출력이 저장됩니다. 여기에는 .s 파일 (어셈블러 코드), .i (전처리된 C) 및 .ii(전처리된 C++) 파일이 포함됩니다. 이러한 출력은 디버깅에 유용한 경우가 많습니다. 임시 버전은 명령줄에 지정된 대상 조합에 대해서만 생성됩니다.

--save_temps 플래그는 현재 cc_* 규칙에만 작동합니다.

Bazel이 추가 출력 파일의 위치를 출력하도록 하려면 --show_result n 설정이 충분히 높은지 확인합니다.

--build_tag_filters=tag[,tag]*

이 플래그를 지정하면 Bazel은 필수 태그가 최소 한 개 이상(지정된 경우) 있고 제외된 태그가 없는 대상만 빌드합니다. 빌드 태그 필터는 쉼표로 구분된 태그 키워드 목록으로 지정되며, 선택적으로 제외 태그를 나타내는 데 사용되는 '-' 기호를 사용합니다. 필수 태그 앞에는 '+' 기호가 있을 수도 있습니다.

테스트를 실행할 때 Bazel은 이 필터와 일치하지 않더라도 빌드되고 실행되는 테스트 타겟의 --build_tag_filters를 무시합니다. 테스트 대상을 빌드하려면 --test_tag_filters를 사용하거나 명시적으로 제외하여 테스트 대상을 필터링하세요.

--test_size_filters=size[,size]*

이 플래그를 지정하면 Bazel에서 지정된 크기의 타겟만 테스트하거나 --build_tests_only도 지정된 경우 빌드합니다. 테스트 크기 필터는 허용된 테스트 크기 값 (소형, 중형, 대형 또는 대형)을 쉼표로 구분한 목록으로 지정되며, 선택적으로 제외 테스트 크기를 나타내는 데 사용되는 '-' 기호가 앞에 붙습니다. 예:

  % bazel test --test_size_filters=small,medium //foo:all
  % bazel test --test_size_filters=-large,-enormous //foo:all

//foo 안의 소규모 테스트와 중간 테스트만 테스트합니다.

기본적으로 테스트 크기 필터링은 적용되지 않습니다.

--test_timeout_filters=timeout[,timeout]*

이 플래그를 지정하면 Bazel에서 지정된 제한 시간이 있는 타겟만 테스트 (또는 --build_tests_only도 지정되면 빌드)합니다. 테스트 제한 시간 필터는 허용된 테스트 제한 시간 값을 쉼표로 구분한 목록 (짧게, 보통, 길게 또는 무한)으로 지정하며, 선택적으로 테스트 시간 초과를 나타내는 데 사용되는 '-' 기호를 뒤에 붙습니다. 구문 예는 --test_size_filters를 참조하세요.

기본적으로 테스트 시간 제한 필터링은 적용되지 않습니다.

--test_tag_filters=tag[,tag]*

이 플래그를 지정하면 Bazel에서 필수 태그가 하나 이상 (지정된 경우) 있고 제외된 태그가 없는 경우에만 테스트 대상을 테스트합니다(또는 --build_tests_only도 지정된 경우 빌드). 테스트 태그 필터는 쉼표로 구분된 태그 키워드 목록으로 지정되며, 선택적으로 제외 태그를 나타내는 데 사용되는 '-' 기호를 사용합니다. 필수 태그 앞에는 '+' 기호가 있을 수도 있습니다.

예:

  % bazel test --test_tag_filters=performance,stress,-flaky //myproject:all

performance 또는 stress 태그가 지정되었지만 flaky 태그로 태그되지 않은 타겟을 테스트합니다.

기본적으로 테스트 태그 필터링은 적용되지 않습니다. 테스트의 sizelocal 태그도 이러한 방식으로 필터링할 수 있습니다.

--test_lang_filters=lang[,lang]*

공식 *_test 규칙을 사용하여 언어의 테스트 언어 목록을 쉼표로 구분하여 지정합니다(전체 목록은 빌드 백과사전 참고). 선택적으로 각 언어 앞에 '-'를 추가하여 제외된 언어를 지정할 수 있습니다. 각 언어에 사용되는 이름은 *_test 규칙의 언어 프리픽스와 동일해야 합니다(예: cc, java 또는 sh).

이 플래그를 지정하면 Bazel에서 지정된 언어의 타겟만 테스트하거나 --build_tests_only도 지정하는 경우 빌드합니다.

예:

  % bazel test --test_lang_filters=cc,java foo/...

foo/...에서 C/C++ 및 자바 테스트 (각각 cc_testjava_test 규칙을 사용하여 정의됨)만 테스트하지만

  % bazel test --test_lang_filters=-sh,-java foo/...

sh_testjava_test 테스트를 제외하고 foo/...에서 모든 테스트를 실행합니다.

기본적으로 테스트 언어 필터링은 적용되지 않습니다.

--test_filter=filter-expression

테스트 실행기가 실행할 테스트의 하위 집합을 선택하는 데 사용할 수 있는 필터를 지정합니다. 호출에 지정된 모든 대상이 빌드되지만 표현식에 따라 일부 대상만 실행될 수 있습니다. 경우에 따라서는 특정 테스트 메서드만 실행됩니다.

filter-expression의 특정 해석은 테스트 실행을 담당하는 테스트 프레임워크에 달려 있습니다. glob, 하위 문자열 또는 정규식일 수 있습니다. --test_filter는 서로 다른 --test_arg 필터 인수를 전달하는 것보다 편리하지만 모든 프레임워크에서 지원되지는 않습니다.

상세 출력

이러한 옵션은 Bazel 출력의 상세 출력을 터미널 또는 추가 로그 파일로 제어합니다.

--explain=logfile

파일 이름 인수가 필요한 이 옵션을 사용하면 bazel build의 실행 단계에서 종속 항목 검사기가 각 빌드 단계에서 실행 이유 또는 실행 여부를 설명합니다. 있습니다. 설명은 logfile에 기록됩니다.

예상치 못한 재빌드가 발생하는 경우 이 옵션을 사용하면 이유를 이해하는 데 도움이 될 수 있습니다. 이를 모든 후속 빌드에서 로깅하도록 .bazelrc에 추가한 다음 예기치 않게 실행된 실행 단계가 표시되면 로그를 검사합니다. 이 옵션은 사소한 성능 저하를 초래할 수 있으므로 더 이상 필요하지 않을 때는 삭제하는 것이 좋습니다.

--verbose_explanations

이 옵션은 --Explain 옵션을 사용 설정할 때 생성된 설명의 세부정보 수준을 높입니다.

특히 자세한 설명이 사용 설정되고 이를 빌드하는 데 사용된 명령어가 변경되어 출력 파일이 다시 빌드되는 경우, 설명 파일의 출력에는 새 명령어의 전체 세부정보가 포함됩니다. (최소한 대부분의 명령어에 대해서는)

이 옵션을 사용하면 생성된 설명 파일의 길이와 --explain 사용 시 성능 저하가 크게 늘어날 수 있습니다.

--explain가 사용 설정되어 있지 않으면 --verbose_explanations는 적용되지 않습니다.

--profile=file

파일 이름 인수를 사용하는 이 옵션으로 Bazel이 프로파일링 데이터를 파일에 작성합니다. 그런 다음 bazel analyze-profile 명령어를 사용하여 데이터를 분석하거나 파싱할 수 있습니다. 빌드 프로필은 Bazel의 build 명령어가 어디에 시간을 할애하는지 이해하는 데 유용할 수 있습니다.

--[no]show_loading_progress

이 옵션을 사용하면 Bazel이 패키지 로드 진행률 메시지를 출력합니다. 사용 중지하면 메시지가 표시되지 않습니다.

--[no]show_progress

이 옵션은 진행률 메시지를 표시합니다. 기본적으로 사용 설정되어 있습니다. 사용 중지되면 진행률 메시지가 표시되지 않습니다.

--show_progress_rate_limit=n

이 옵션을 사용하면 bazel이 n초당 진행률 메시지 하나만 표시합니다. 여기서 n은 실수입니다. n이 -1이면 모든 진행률 메시지가 표시됩니다. 이 옵션의 기본값은 0.02입니다. 즉, bazel에서 진행률 메시지를 0.02초마다 하나씩 제한합니다.

--show_result=n

이 옵션은 bazel build 명령어 끝에 결과 정보 출력을 제어합니다. 기본적으로 단일 빌드 대상이 지정된 경우 Bazel은 대상이 성공적으로 업데이트되었는지 여부를 확인하고 그렇지 않으면 출력 파일 목록이 대상을 만들었습니다. 여러 대상이 지정되면 결과 정보가 표시되지 않습니다.

결과 정보는 단일 대상 또는 몇 개의 대상을 빌드하는 데 유용할 수 있지만 대규모 빌드 (예: 전체 최상위 프로젝트 트리)의 경우 이 정보가 부담스럽고 산만할 수 있습니다. 이 옵션으로 파일을 제어할 수 있습니다. --show_result은 전체 결과 정보를 출력해야 하는 최대 대상 수인 정수 인수를 사용합니다. 기본값은 1입니다. 이 임계값보다 높으면 개별 대상에 대한 결과 정보는 표시되지 않습니다. 따라서 0으로 설정하면 결과 정보가 항상 표시되지 않고 값이 매우 크면 결과가 항상 출력됩니다.

사용자가 작은 타겟 그룹 (예: compile-edit-test 주기)과 큰 타겟 그룹(예: 예를 들어 새 작업공간을 설정하거나 회귀 테스트를 실행할 때를 예로 들 수 있습니다. 전자의 경우 결과 정보는 매우 유용하지만 후자의 경우 그렇지 않습니다. 모든 옵션과 마찬가지로 .bazelrc 파일을 통해 암시적으로 지정할 수 있습니다.

빌드된 실행 파일을 실행하기 위해 파일 이름을 복사하여 셸에 쉽게 붙여넣을 수 있도록 파일이 출력됩니다. 각 타겟의 '최신' 메시지 또는 '실패' 메시지는 빌드를 구동하는 스크립트로 쉽게 파싱할 수 있습니다.

--sandbox_debug

이 옵션을 사용하면 Bazel에서 작업 실행에 샌드박스를 사용할 때 추가 디버깅 정보를 출력합니다. 또한 이 옵션을 사용하면 샌드박스 디렉터리가 보존되므로 실행 중에 작업에 표시되는 파일을 검사할 수 있습니다.

--subcommands(-s)

이 옵션을 사용하면 Bazel의 실행 단계에서 실행 전에 각 명령어의 전체 명령줄이 출력됩니다.

  >>>>> # //examples/cpp:hello-world [action 'Linking examples/cpp/hello-world']
  (cd /home/johndoe/.cache/bazel/_bazel_johndoe/4c084335afceb392cfbe7c31afee3a9f/bazel && \
    exec env - \
    /usr/bin/gcc -o bazel-out/local-fastbuild/bin/examples/cpp/hello-world -B/usr/bin/ -Wl,-z,relro,-z,now -no-canonical-prefixes -pass-exit-codes -Wl,-S -Wl,@bazel-out/local_linux-fastbuild/bin/examples/cpp/hello-world-2.params)

가능한 경우 명령어를 Bourne 셸 호환 구문으로 인쇄하여 셸 명령어 프롬프트에 쉽게 복사하여 붙여넣을 수 있습니다. 셸을 cdexec 호출로부터 보호하기 위해 괄호가 제공되므로 이를 복사해야 합니다. 하지만 심볼릭 링크 생성과 같은 일부 명령어는 Bazel 내에서 내부적으로 구현됩니다. 이 경우에는 표시할 명령줄이 없습니다.

명령어 인수를 한 줄이 아닌 목록으로 출력하기 위해 --subcommands=pretty_print을 전달할 수 있습니다. 그러면 긴 명령줄을 더 쉽게 읽을 수 있습니다.

아래의 --verbose_failures도 참조하세요.

도구 친화적인 형식의 파일에 하위 명령어를 로깅하려면 --Execution_log_json_file--Execution_log_binary_file을 참고하세요.

--verbose_failures

이 옵션을 사용하면 Bazel의 실행 단계에서 실패한 명령어의 전체 명령줄을 출력합니다. 이는 실패한 빌드를 디버깅하는 데 매우 유용할 수 있습니다.

실패한 명령어는 셸 프롬프트에 호환되는 구문으로 출력되며, 셸 프롬프트에 복사하여 붙여넣기에 적합합니다.

작업공간 상태

소스 제어 버전 또는 기타 작업공간 관련 정보와 같은 추가 정보를 바이너리에 삽입하려면 다음 옵션을 사용하여 Bazel에서 빌드한 바이너리를 '스탬프' 처리하세요. genrule, cc_binarystamp 속성을 지원하는 규칙과 함께 이 메커니즘을 사용할 수 있습니다.

--workspace_status_command=program

이 플래그를 사용하면 각 빌드 전에 Bazel에서 실행하는 바이너리를 지정할 수 있습니다. 프로그램은 현재 소스 제어 버전과 같은 작업공간 상태에 관한 정보를 보고할 수 있습니다.

플래그 값은 네이티브 프로그램 경로여야 합니다. Linux/macOS에서는 실행 파일일 수 있습니다. Windows에서는 일반적으로 네이티브 바이너리로, '.exe', '.bat' 또는 '.cmd'여야 합니다.

프로그램은 키-값 쌍을 0개 이상의 표준 출력으로 출력해야 하며, 각 줄에 하나의 항목이 있어야 하며, 그렇지 않으면 빌드가 실패합니다. 키 이름은 무엇이든 할 수 있지만 대문자와 밑줄만 사용할 수 있습니다. 키 이름 뒤에 있는 첫 번째 공백은 이를 값과 구분합니다. 값은 줄의 나머지 부분입니다 (추가 공백 포함). 키 및 값 모두 여러 행에 걸쳐 있을 수 없습니다. 키는 복제할 수 없습니다.

Bazel은 키를 'stable'과 'volatile'이라는 두 버킷으로 나 partitions니다. 'stable'과 'volatile'은 약간 직관적이지 않으므로 신경 쓰지 마세요.

그러면 Bazel이 키-값 쌍을 두 파일에 씁니다.

  • bazel-out/stable-status.txt에는 키 이름이 STABLE_로 시작하는 모든 키와 값이 포함됩니다.
  • bazel-out/volatile-status.txt에는 나머지 키와 키 값이 포함됩니다.

계약은 다음과 같습니다.

  • '안정적인' 키의 값은 가능하면 거의 변경되지 않습니다. bazel-out/stable-status.txt의 콘텐츠가 변경되면 Bazel은 종속된 작업을 무효화합니다. 즉, 안정적인 키의 값이 변경되면 Bazel이 스탬프 처리된 작업을 다시 실행합니다. 따라서 공개 상태에는 항상 변경되고 Bazel이 각 빌드 시 스탬프 처리된 작업을 다시 실행하므로 타임스탬프 같은 항목이 포함되면 안 됩니다.

    Bazel은 항상 다음과 같은 안정적인 키를 출력합니다.

    • BUILD_EMBED_LABEL: --embed_label의 값
    • BUILD_HOST: Bazel이 실행되는 호스트 머신의 이름
    • BUILD_USER: Bazel이 실행 중인 사용자의 이름입니다.
  • 'volatile' 키 값은 자주 변경될 수 있습니다. Bazel은 타임스탬프와 마찬가지로 항상 변경될 것으로 예상하고 bazel-out/volatile-status.txt 파일을 적절하게 업데이트합니다. 하지만 항상 스탬프 처리된 작업이 재실행되지 않도록 Bazel은 휘발성 파일이 변경되지 않는 것으로 가장합니다. 즉, 휘발성 상태 파일만 콘텐츠가 변경된 경우 Bazel이 이 파일에 의존하는 작업을 무효화하지 않습니다. 작업의 다른 입력이 변경되면 Bazel이 해당 작업을 다시 실행하면 작업에 업데이트된 휘발성 상태가 표시되지만 휘발성 상태만 변경되더라도 작업이 무효화되지 않습니다.

    Bazel은 항상 다음과 같은 휘발성 키를 출력합니다.

    • BUILD_TIMESTAMP: Unix Epoch 이후 빌드 시간(초)(System.currentTimeMillis() 값을 1,000으로 나눈 값)

Linux/macOS에서는 --workspace_status_command=/bin/true을 전달하여 작업공간 상태 검색을 중지할 수 있습니다. true가 아무 작업도 하지 않고 (0으로 종료) 출력을 출력하지 않기 때문입니다. Windows에서는 MSYS의 true.exe 경로를 전달하여 동일한 효과를 얻을 수 있습니다.

어떤 이유로든 작업공간 상태 명령어가 실패하면 (0이 아닌 종료) 빌드가 실패합니다.

Git를 사용하는 Linux의 프로그램 예:

#!/bin/bash
echo "CURRENT_TIME $(date +%s)"
echo "RANDOM_HASH $(cat /proc/sys/kernel/random/uuid)"
echo "STABLE_GIT_COMMIT $(git rev-parse HEAD)"
echo "STABLE_USER_NAME $USER"

--workspace_status_command를 사용하여 이 프로그램의 경로를 전달하면 안정적인 상태 파일에 STABLE 행이 포함되고 휘발성 상태 파일에는 나머지 줄이 포함됩니다.

--[no]stamp

이 옵션은 stamp 규칙 속성과 함께 빌드 정보를 바이너리에 삽입할지 여부를 제어합니다.

스탬핑은 stamp 속성을 사용하여 규칙별로 명시적으로 사용 설정하거나 중지할 수 있습니다. 자세한 내용은 빌드 백과사전을 참조하세요. 규칙이 stamp = -1 (*_binary 규칙의 기본값)를 설정하면 이 옵션은 스탬프 사용 설정 여부를 결정합니다.

Bazel은 이 옵션이나 stamp 속성에 관계없이 호스트 구성을 위해 빌드된 바이너리에 스탬프를 걸지 않습니다. stamp = 0 (*_test 규칙의 기본값)를 설정하는 규칙의 경우 스탬프는 --[no]stamp에 관계없이 사용 중지됩니다. --stamp를 지정해도 종속 항목이 변경되지 않은 경우 대상이 다시 빌드되지 않습니다.

--nostamp 설정은 일반적으로 입력 변동성을 줄이고 빌드 캐싱을 최대화하므로 빌드 성능에 적합합니다.

플랫폼

이러한 옵션을 사용하여 빌드 작동 방식을 구성하는 호스트 및 대상 플랫폼을 제어하고 Bazel 규칙에서 사용할 수 있는 실행 플랫폼 및 도구 모음을 제어합니다.

플랫폼도구 모음에 대한 배경 정보를 참조하세요.

--platforms=labels

현재 명령어의 타겟 플랫폼을 설명하는 플랫폼 규칙의 라벨입니다.

--host_platform=label

호스트 시스템을 설명하는 플랫폼 규칙의 라벨입니다.

--extra_execution_platforms=labels

작업을 실행할 실행 플랫폼으로 사용할 수 있는 플랫폼입니다. 플랫폼은 정확한 대상으로 지정되거나 대상 패턴으로 지정될 수 있습니다. 이러한 플랫폼은 register_Execution_platforms()에 의해 WORKSPACE 파일에 선언되기 전에 고려됩니다.

--extra_toolchains=labels

도구 모음 해결 중에 고려해야 할 도구 모음 규칙입니다. 도구 모음은 정확한 타겟으로 또는 대상 패턴으로 지정할 수 있습니다. 이러한 도구 모음은 register_toolchains()를 사용하여 WORKSPACE 파일에 선언되기 전에 고려됩니다.

--toolchain_resolution_debug=regex

도구 모음 유형이 정규식과 일치하는 경우 도구 모음을 찾는 동안 디버그 정보를 출력합니다. 여러 정규 표현식은 쉼표로 분리할 수 있습니다. 정규식은 시작 부분에 -를 사용하여 부정할 수 있습니다. 이는 도구 모음 누락으로 인한 디버깅 실패가 있는 Bazel 또는 Starlark 규칙 개발자에게 도움이 될 수 있습니다.

기타

--flag_alias=alias_name=target_path

더 긴 Starlark 빌드 설정을 더 짧은 이름으로 바인딩하는 데 사용되는 편의 플래그입니다. 자세한 내용은 Starlark 구성을 참조하세요.

생성된 symlink의 단축어를 변경합니다. 심볼릭 링크 프리픽스의 기본값은 bazel-이며 심볼릭 링크는 bazel-bin, bazel-testlogs, bazel-genfiles을 만듭니다.

어떠한 이유로든 기호화된 링크를 만들 수 없는 경우 경고가 표시되지만 빌드는 여전히 성공으로 간주됩니다. 특히 읽기 전용 디렉터리나 쓰기 권한이 없는 디렉터리를 빌드할 수 있습니다. 빌드가 끝나면 정보 메시지에 출력된 경로는 심볼릭 링크가 예상된 위치를 가리키는 경우에만 심볼릭 링크 상대 짧은 형식을 사용합니다. 즉, 생성 중인 심볼릭 링크를 사용할 수 없더라도 이러한 경로의 정확성에 의존할 수 있습니다.

이 옵션의 몇 가지 일반적인 값은 다음과 같습니다.

  • 심볼릭 링크 생성 중단: --symlink_prefix=/를 사용하면 Bazel에서 bazel-outbazel-<workspace> 심볼릭 링크를 비롯한 심볼릭 링크를 만들거나 업데이트하지 않습니다. 에서 확인할 수 있습니다. 심볼릭 링크 생성을 완전히 억제하려면 이 옵션을 사용하세요.

  • 불필요한 요소 줄이기: --symlink_prefix=.bazel/를 사용하면 Bazel이 숨겨진 디렉터리 .bazel 내에 심볼릭 링크 (예: bin)를 만듭니다.

--platform_suffix=string

출력 디렉터리를 결정하는 데 사용되는 구성 닉네임에 접미사를 추가합니다. 이 옵션을 다른 값으로 설정하면 파일을 서로 다른 디렉터리에 넣습니다. 예를 들어 서로 다른 출력 파일을 클로버하는 빌드의 캐시 적중률을 향상시키거나 비교를 위해 출력 파일을 보존하기 위해서입니다.

--default_visibility=(private|public)

Bazel 기본 공개 상태 변경사항을 테스트하기 위한 임시 플래그 일반적인 용도는 아니지만 완전성을 위해 문서화되었습니다.

--[no]use_action_cache

이 옵션은 기본적으로 사용 설정됩니다. 사용 중지하면 Bazel이 로컬 작업 캐시를 사용하지 않습니다. 로컬 작업 캐시를 사용 중지하면 클린 빌드에 필요한 메모리와 디스크 공간이 절약되지만 증분 빌드가 느려집니다.

--starlark_cpu_profile=_file_

값이 파일 이름인 이 플래그는 Bazel이 모든 Starlark 스레드의 CPU 사용량 통계를 수집하고 pprop 형식으로 프로필을 작성하도록 합니다. 파일을 추가합니다.

이 옵션을 사용하면 과도한 계산으로 인해 로드 및 분석 속도가 느려진 Starlark 함수를 식별할 수 있습니다. 예:

$ bazel build --nobuild --starlark_cpu_profile=/tmp/pprof.gz my/project/...
$ pprof /tmp/pprof.gz
(pprof) top
Type: CPU
Time: Feb 6, 2020 at 12:06pm (PST)
Duration: 5.26s, Total samples = 3.34s (63.55%)
Showing nodes accounting for 3.34s, 100% of 3.34s total
      flat  flat%   sum%        cum   cum%
     1.86s 55.69% 55.69%      1.86s 55.69%  sort_source_files
     1.02s 30.54% 86.23%      1.02s 30.54%  expand_all_combinations
     0.44s 13.17% 99.40%      0.44s 13.17%  range
     0.02s   0.6%   100%      3.34s   100%  sorted
         0     0%   100%      1.38s 41.32%  my/project/main/BUILD
         0     0%   100%      1.96s 58.68%  my/project/library.bzl
         0     0%   100%      3.34s   100%  main

동일한 데이터를 다양한 뷰로 보려면 pprof 명령어 svg, web, list를 사용해 보세요.

출시에 Bazel 사용

Bazel은 개발 주기 동안 소프트웨어 엔지니어가 사용하며, 프로덕션에 배포할 바이너리를 준비할 때 출시 엔지니어가 사용합니다. 이 섹션에서는 Bazel을 사용하는 출시 엔지니어를 위한 도움말 목록을 제공합니다.

중요한 옵션

Bazel을 출시 빌드에 사용하는 경우 빌드를 수행하는 다른 스크립트와 동일한 문제가 발생합니다. 자세한 내용은 스크립트에서 Bazel 호출을 참조하세요. 특히 다음과 같은 옵션을 사용하는 것이 좋습니다.

다음 옵션도 중요합니다.

  • --package_path
  • --symlink_prefix: 여러 구성의 빌드를 관리하는 경우 '64비트'와 '32비트'와 같은 고유한 식별자를 사용하여 각 빌드를 구분하는 것이 편리할 수 있습니다. ' 이 옵션은 bazel-bin 등의 심볼릭 링크를 구분합니다.

테스트 실행

Bazel로 테스트를 빌드하고 실행하려면 bazel test 뒤에 테스트 대상의 이름을 입력하세요.

기본적으로 이 명령어는 빌드 및 테스트 활동을 동시에 실행하여 지정된 모든 타겟 (명령줄에 지정된 비테스트 타겟 포함)을 빌드하고 *_testtest_suite 타겟을 테스트합니다. 즉, 기본 요건이 빌드되는 즉시 테스트 실행이 빌드와 함께 인터리브 처리됩니다. 이렇게 하면 일반적으로 속도가 크게 향상됩니다.

bazel test 옵션

--cache_test_results=(yes|no|auto)(-t)

이 옵션을 'auto' (기본값)로 설정하면 Bazel은 다음 조건 중 하나에 해당하는 경우에만 테스트를 다시 실행합니다.

  • Bazel이 테스트 또는 종속 항목의 변경사항을 감지합니다.
  • 테스트가 external로 표시됩니다.
  • --runs_per_test으로 여러 테스트 실행이 요청됨
  • 테스트가 실패했습니다.

'아니요'인 경우 모든 테스트가 무조건 실행됩니다.

'예'인 경우 캐싱이 테스트 실패를 캐시하고 --runs_per_test로 테스트 실행을 할 수 있다는 점을 제외하면 자동 동작이 동일합니다.

해당 옵션을 기본적으로 사용 설정한 사용자는.bazelrc 파일에 포함된 약어는-t (사용) 또는-t- (off) 특정 실행에서 기본값을 재정의할 때 유용합니다.

--check_tests_up_to_date

이 옵션은 Bazel에 테스트를 실행하지 않고 캐시된 테스트 결과만 확인 및 보고하도록 지시합니다. 이전에 빌드되어 실행되지 않은 테스트가 있거나 테스트 결과가 최신이 아닌 경우 (예: 소스 코드 또는 빌드 옵션이 변경됨) Bazel이 보고합니다. 오류 메시지 ('테스트 결과가 최신 상태가 아님')는 테스트 상태를 '상태 없음' (색상 출력이 사용 설정된 경우 빨간색)으로 기록하고 다음을 반환합니다. 0이 아닌 종료 코드입니다.

이 옵션은 [--check_up_to_date](#check-up-to-date) 동작도 의미합니다.

이 옵션은 사전 제출 검사에 유용합니다.

--test_verbose_timeout_warnings

이 옵션은 테스트 시간 제한이 테스트의 실제 실행 시간보다 상당히 길 경우 사용자에게 명시적으로 경고하도록 합니다. 테스트 제한 시간을 불안정해지지 않도록 설정해야 하지만, 제한 시간이 지나치게 a한 테스트는 예기치 않게 잘리는 실제 문제를 숨길 수 있습니다.

예를 들어 1~2분 정도면 보통 실행되는 테스트의 경우 ETERNAL 또는 LONG 제한 시간이 초과되면 안 됩니다. 이 값은 너무 관대한 것입니다.

이 옵션은 사용자가 적절한 제한 시간 값을 결정하고 기존의 제한 시간 값을 확인할 수 있도록 하는 데 유용합니다.

--[no]test_keep_going

기본적으로 모든 테스트는 완료될 때까지 실행됩니다. 그러나 이 플래그가 사용 중지되면 통과하지 않은 테스트에서 빌드가 취소됩니다. 후속 빌드 단계 및 테스트 호출은 실행되지 않으며 진행 중인 호출은 취소됩니다. --notest_keep_going--keep_going를 모두 지정하지 마세요.

--flaky_test_attempts=attempts

이 옵션은 어떠한 이유로 테스트가 실패할 경우 테스트를 시도할 최대 횟수를 지정합니다. 처음에는 실패했지만 성공하는 테스트는 테스트 요약에서 FLAKY로 보고됩니다. 하지만 Bazel 종료 코드 또는 통과한 총 테스트 수를 식별할 때 통과된 것으로 간주됩니다. 허용된 모든 시도에 실패한 테스트는 실패한 것으로 간주됩니다.

기본적으로 (이 옵션을 지정하지 않거나 기본값으로 설정한 경우)는 일반 테스트에 한 번만 시도하고 flaky 속성이 설정된 테스트 규칙에는 3번만 허용됩니다. 정수 값을 지정하여 테스트 시도의 최대 한도를 재정의할 수 있습니다. Bazel은 시스템 악용을 방지하기 위해 최대 10회의 테스트 시도를 허용합니다.

--runs_per_test=[regex@]number

이 옵션은 각 테스트를 실행해야 하는 횟수를 지정합니다. 모든 테스트 실행은 별도의 테스트로 취급됩니다. 대체 기능은 각각에 개별적으로 적용됩니다.

실행이 실패한 대상의 상태는 --runs_per_test_detects_flakes 플래그 값에 따라 다릅니다.

  • 이 항목이 없으면 실행이 실패하면 전체 테스트가 실패합니다.
  • 존재하고 동일한 샤드 반환 PASS 및 FAIL에서 두 번 실행된 경우 테스트는 불안정한 상태를 수신합니다 (다른 실행 실패가 실패하지 않는 한).

단일 번호가 지정되면 모든 테스트가 여러 번 실행됩니다. 또는 정규식@regex를 사용하여 정규 표현식을 지정할 수 있습니다. 이렇게 하면 정규식과 일치하는 타겟으로 --runs_per_test의 효과가 제한됩니다. --runs_per_test=^//pizza:.*@4는 모든 테스트를 //pizza/에서 4번 실행합니다. 이 --runs_per_test 형식은 한 번 이상 지정할 수 있습니다.

--[no]runs_per_test_detects_flakes

이 옵션을 지정하지 않으면 (기본적으로 지정되지 않음) Bazel에서 --runs_per_test를 통해 불안정한 테스트 샤드를 감지합니다. 단일 샤드 실행에 하나 이상의 실행이 실패하고 동일한 샤드 패스에 한 번 이상 실행되면 대상은 플래그와 함께 불안정한 것으로 간주됩니다. 지정하지 않으면 대상은 실패 상태를 보고합니다.

--test_summary=output_style

테스트 결과 요약이 표시되는 방식을 지정합니다.

  • short는 테스트가 실패한 경우 각 테스트의 결과를 테스트 결과가 포함된 파일의 이름과 함께 출력합니다. 이 설정이 기본 설정입니다.
  • terseshort과 같지만 더 짧은 경우: 통과하지 못한 테스트에 관한 정보만 출력합니다.
  • detailed는 각 테스트뿐만 아니라 실패한 각 개별 테스트 사례를 출력합니다. 테스트 출력 파일의 이름은 생략됩니다.
  • none는 테스트 요약을 출력하지 않습니다.

--test_output=output_style

테스트 출력 표시 방법을 지정합니다.

  • summary는 각 테스트의 통과 또는 실패 여부를 요약하여 보여줍니다. 또한 실패한 테스트의 출력 로그 파일 이름도 보여줍니다. 빌드가 끝나면 요약이 출력됩니다 (빌드 중에 테스트가 시작, 통과 또는 실패할 때 간단한 진행 메시지만 표시됨). 기본 동작입니다.
  • errors은 테스트가 완료된 직후에 실패한 테스트의 stdout/stderr 출력을 stdout으로 전송하므로 동시 테스트의 테스트 출력이 서로 인터리브되지 않습니다. 위의 요약 출력에 따라 빌드의 요약을 출력합니다.
  • allerrors와 유사하지만 통과한 테스트를 포함한 모든 테스트의 출력을 출력합니다.
  • streamed는 각 테스트의 stdout/stderr 출력을 실시간으로 스트리밍합니다.

--java_debug

이 옵션을 사용하면 자바 테스트의 자바 가상 머신에서 JDWP 호환 디버거의 연결을 대기한 후 테스트를 시작합니다. 이 옵션은 --test_output=streamed를 암시합니다.

--[no]verbose_test_summary

기본적으로 이 옵션은 사용 설정되어 테스트 시간 및 기타 추가 정보 (예: 테스트 시도)가 테스트 요약에 출력됩니다. --noverbose_test_summary이 지정되면 테스트 요약에는 테스트 이름, 테스트 상태 및 캐시된 테스트 표시기만 포함되며, 가능한 경우 80자(영문 기준) 이내로 유지되도록 형식이 지정됩니다.

--test_tmpdir=path

로컬에서 실행되는 테스트의 임시 디렉터리를 지정합니다. 각 테스트는 이 디렉터리 내의 별도의 하위 디렉터리에서 실행됩니다. 디렉터리는 각 bazel test 명령어의 시작 부분에서 정리됩니다. 기본적으로 bazel은 이 디렉터리를 Bazel 출력 기본 디렉터리 아래에 배치합니다.

--test_timeout=seconds 또는 --test_timeout=seconds,seconds,seconds,seconds

지정된 시간(초)을 새 제한 시간 값으로 사용하여 모든 테스트의 제한 시간 값을 재정의합니다. 값이 1개만 제공되면 모든 테스트 시간 제한 카테고리에 사용됩니다.

또는 쉼표로 구분된 4개의 값이 제공될 수 있으며, 이 시간은 짧은 시간, 중간 수준, 긴, 영구 테스트에 대한 개별 시간 제한을 지정합니다 (이 순서대로). 두 형식 모두 테스트 작성 페이지에 정의된 대로 지정된 제한 시간의 기본 제한 시간으로 테스트 크기가 0이거나 음수가 됩니다. 기본적으로 Bazel은 크기가 암시적으로 설정되든 명시적으로 설정되든 테스트 크기에서 시간 제한 제한을 추론하여 모든 테스트에 이러한 시간 제한을 사용합니다.

제한 시간 크기와 명시적으로 구분되는 테스트에서는 시간 제한이 크기 태그에 의해 암시적으로 설정된 것처럼 동일한 값을 수신합니다. 따라서 'long' 시간 제한을 선언하는 'small' 크기 테스트는 명시적인 제한 시간이 없는 '대형' 테스트와 동일한 유효 시간 제한이 있습니다.

--test_arg=arg

명령줄 옵션/플래그/인수를 각 테스트 프로세스에 전달합니다. 이 옵션을 여러 번 사용하여 여러 인수를 전달할 수 있습니다. 예: --test_arg=--logtostderr --test_arg=--v=3.

--test_env=variable=_value_ 또는 --test_env=variable

각 테스트의 테스트 환경에 삽입해야 하는 추가 변수를 지정합니다. value가 지정되지 않은 경우 bazel test 명령어를 시작하는 데 사용된 셸 환경에서 상속됩니다.

테스트 내에서 System.getenv("var") (자바), getenv("var") (C 또는 C++)를 사용하여 이 환경에 액세스할 수 있습니다.

--run_under=command-prefix

이렇게 하면 실행 전에 테스트 실행기가 테스트 명령어 앞에 삽입할 접두사가 지정됩니다. command-prefix는 Bourne 셸 토큰화 규칙을 사용하여 단어로 분할된 후 실행하려는 명령어 앞에 단어 목록이 추가됩니다.

첫 번째 단어가 정규화된 라벨 (//로 시작)인 경우 빌드됩니다. 그러면 라벨이 다른 명령어와 함께 실행될 명령어 앞에 추가된 상응하는 실행 가능한 위치로 대체됩니다.

몇 가지 주의사항이 있습니다.

  • 테스트 실행에 사용되는 PATH는 환경의 PATH와 다를 수 있으므로 --run_under 명령어에 절대 경로 (첫 번째 단어 포함)를 사용해야 할 수 있습니다. command-prefix).
  • stdin이(가) 연결되어 있지 않으므로 --run_under을(를) 대화형 명령어에 사용할 수 없습니다.

예:

        --run_under=/usr/bin/strace
        --run_under='/usr/bin/strace -c'
        --run_under=/usr/bin/valgrind
        --run_under='/usr/bin/valgrind --quiet --num-callers=20'

테스트 선택

출력 선택 옵션에 설명된 대로 크기, 제한 시간, 태그를 기준으로 테스트를 필터링할 수 있습니다.또는 language를 사용합니다. 편의 일반 이름 필터는 특정 필터 인수를 테스트 실행기에 전달할 수 있습니다.

bazel test의 다른 옵션

구문 및 나머지 옵션은 정확히 bazel build와 동일합니다.

실행 파일 실행

bazel run 명령어는 단일 타겟을 빌드하고 실행하는 데 사용된다는 점을 제외하면 bazel build과 유사합니다. 다음은 일반적인 세션입니다.

  % bazel run java/myapp:myapp -- --arg1 --arg2
  Welcome to Bazel
  INFO: Loading package: java/myapp
  INFO: Loading package: foo/bar
  INFO: Loading complete.  Analyzing...
  INFO: Found 1 target...
  ...
  Target //java/myapp:myapp up-to-date:
    bazel-bin/java/myapp:myapp
  INFO: Elapsed time: 0.638s, Critical Path: 0.34s

  INFO: Running command line: bazel-bin/java/myapp:myapp --arg1 --arg2
  Hello there
  $EXEC_ROOT/java/myapp/myapp
  --arg1
  --arg2

bazel run는 Bazel에서 빌드한 바이너리를 직접 호출하는 것과 비슷하지만 동일하지는 않습니다. 호출되는 바이너리가 테스트인지 여부에 따라 다릅니다.

바이너리가 테스트가 아닌 경우 현재 작업 디렉터리가 바이너리의 실행 파일 트리가 됩니다.

바이너리가 테스트인 경우 현재 작업 디렉터리가 exec 루트가 되며 일반적으로 환경 테스트가 복제되기 위한 선의의 시도가 이루어집니다. 하지만 에뮬레이션이 완벽하지 않으며 여러 샤드가 있는 테스트를 실행할 수 없습니다 (이 문제를 해결하기 위해 --test_sharding_strategy=disabled 명령줄 옵션을 사용할 수 있음).

바이너리에 다음과 같은 추가 환경 변수를 사용할 수도 있습니다.

  • BUILD_WORKSPACE_DIRECTORY: 빌드가 실행된 작업공간의 루트입니다.
  • BUILD_WORKING_DIRECTORY: Bazel이 실행된 현재 작업 디렉터리입니다.

예를 들어 이들은 명령줄에서 파일 이름을 사용자 친화적인 방식으로 해석하는 데 사용할 수 있습니다.

bazel run 옵션

--run_under=command-prefix

이는 bazel test--run_under 옵션 (위 참조)과 동일합니다. 단, bazel run에서 실행하는 명령어에 적용된다는 점이 다릅니다. 이는 bazel test에 의해 실행되는 테스트보다 높고 라벨 아래에서 실행될 수 없습니다.

Bazel에서 로깅 출력 필터링

bazel run으로 바이너리를 호출할 때 Bazel은 Bazel 자체와 로깅 중인 바이너리의 로깅 출력을 출력합니다. --ui_event_filters--noshow_progress 플래그를 사용하여 Bazel 자체의 출력을 억제하면 로그에 노이즈가 줄어듭니다.

예를 들면 다음과 같습니다. bazel run --ui_event_filters=-info,-stdout,-stderr --noshow_progress //java/myapp:myapp

테스트 실행

또한 bazel run은 테스트 바이너리를 실행할 수 있으며, 이는 테스트 작성에 설명된 환경의 근접도에서 테스트를 실행하는 데 영향을 미칩니다. 참고로, --test_arg를 제외하고 이 방식으로 테스트를 실행할 때에는 --test_* 인수가 적용되지 않습니다 .

빌드 출력 정리

clean 명령어

Bazel에는 clean 명령어가 있으며 Make의 명령어와 유사합니다. 이 Bazel 인스턴스가 수행한 모든 빌드 구성의 출력 디렉터리 또는 이 Bazel 인스턴스에서 만든 전체 작업 트리를 삭제하고 내부 캐시를 재설정합니다. 명령줄 옵션 없이 실행하면 모든 구성의 출력 디렉터리가 삭제됩니다.

각 Bazel 인스턴스가 단일 작업공간과 연결되어 있으므로 clean 명령어는 해당 작업공간의 Bazel 인스턴스에서 수행한 모든 빌드의 모든 출력을 삭제합니다.

Bazel 인스턴스에서 만든 전체 작업 트리를 완전히 삭제하려면 --expunge 옵션을 지정하면 됩니다. --expunge로 실행하면 정리 명령어는 빌드 출력 외에 Bazel에서 만든 모든 임시 파일을 포함하는 전체 출력 기본 트리를 삭제합니다. 또한 shutdown 명령어와 동일하게 정리한 후 Bazel 서버를 중지합니다. 예를 들어 Bazel 인스턴스의 모든 디스크 및 메모리 trace를 정리하려면 다음을 지정할 수 있습니다.

  % bazel clean --expunge

또는 --expunge_async를 사용하여 백그라운드에서 삭제할 수 있습니다. 비동기 영구 삭제는 계속 실행되는 동안 동일한 클라이언트에서 Bazel 명령어를 호출하는 것이 안전합니다.

clean 명령어는 더 이상 필요하지 않은 작업공간의 디스크 공간을 회수하는 수단으로 주로 제공됩니다. Bazel의 증분 다시 빌드는 완벽하지 않을 수 있으므로 문제가 발생할 때 clean을 사용하여 일관된 상태를 복구할 수 있습니다.

Bazel의 설계는 이러한 문제를 해결할 수 있고 이러한 버그를 해결하는 것이 우선순위가 높은 것입니다. 잘못된 증분 빌드가 발견되면 clean를 사용하는 대신 버그 신고를 제출하고 도구에서 버그를 보고합니다.

종속 항목 그래프 쿼리

Bazel에는 빌드 중에 사용된 종속 항목 그래프에 관한 질문을 위한 쿼리 언어가 포함되어 있습니다. 쿼리 언어는 query와 cquery라는 두 가지 명령어에 사용됩니다. 두 명령어의 주요 차이점은 로드 단계 이후 쿼리가 실행되고, 분석 단계 후에 cquery가 실행된다는 점입니다. 이러한 도구는 많은 소프트웨어 엔지니어링 작업에 소중한 도움이 됩니다.

쿼리 언어는 그래프를 통한 대수 연산의 개념을 기반으로 합니다. 자세한 내용은

Bazel 쿼리 참조 해당 예시, 참조, 쿼리별 명령줄 옵션은 해당 문서를 참조하세요.

쿼리 도구는 여러 명령줄 옵션을 허용합니다. --output는 출력 형식을 선택합니다. --[no]keep_going (기본적으로 사용 중지됨)는 쿼리 도구에서 오류 발생 시 계속 진행하게 합니다. 오류 발생 시 불완전한 결과가 허용되지 않는 경우 이 동작은 사용 중지될 수 있습니다.

기본적으로 사용 설정된 --[no]tool_deps 옵션을 사용하면 대상 이외의 구성에 있는 종속 항목이 쿼리가 작동하는 종속 항목 그래프에 포함됩니다.

기본적으로 사용 설정된 --[no]implicit_deps 옵션을 사용하면 쿼리가 실행되는 종속 항목 그래프에 암시적 종속 항목이 포함됩니다. 암시적 종속 항목은 BUILD 파일에 명시적으로 지정되지 않고 bazel에서 추가합니다.

예: 'PEBL 트리에서 모든 테스트를 빌드하는 데 필요한 모든 genrule의 정의 (BUILD 파일) 위치를 표시합니다.'

  bazel query --output location 'kind(genrule, deps(kind(".*_test rule", foo/bar/pebl/...)))'

작업 그래프 쿼리

aquery 명령어를 사용하면 빌드 그래프의 작업을 쿼리할 수 있습니다. 사후 분석 구성된 대상 그래프에서 작동하고 작업, 아티팩트 및 관련 관계에 대한 정보를 노출합니다.

이 도구는 여러 명령줄 옵션을 허용합니다. --output는 출력 형식을 선택합니다. 기본 출력 형식(text)은 사람이 읽을 수 있습니다. 머신에서 읽을 수 있는 형식은 proto 또는 textproto를 사용하세요. 특히 aquery 명령어는 일반 Bazel 빌드에서 실행되며 빌드 중에 사용 가능한 옵션 집합을 상속합니다.

또한 기존 query에서도 사용할 수 있는 동일한 함수 집합을 지원하지만 siblings, buildfiles, tests도 지원합니다.

자세한 내용은 작업 그래프 쿼리를 참조하세요.

기타 명령어 및 옵션

help

help 명령어는 온라인 도움말을 제공합니다. 기본적으로 Bazel로 빌드에서 볼 수 있듯이 사용 가능한 명령어 및 도움말 주제의 요약이 표시됩니다. 인수를 지정하면 특정 주제에 대한 자세한 도움말이 표시됩니다. 대부분의 주제는 Bazel 명령어(예: build 또는 query)이지만 명령어에 해당하지 않는 추가 도움말 주제도 있습니다.

--[no]long(-l)

기본적으로 bazel help [topic]은 주제와 관련된 옵션의 요약만 출력합니다. --long 옵션을 지정하면 각 옵션의 유형, 기본값, 자세한 설명도 출력됩니다.

shutdown

Bazel 서버 프로세스는 shutdown 명령어를 사용하여 중지할 수 있습니다. 이 명령어는 Bazel 서버가 유휴 상태가 되는 즉시 (예: 현재 진행 중인 빌드 또는 기타 명령어 완료 후) 종료됩니다. 자세한 내용은 클라이언트/서버 구현을 참조하세요.

Bazel 서버가 유휴 시간 제한 후에 스스로 중지되므로 이 명령어는 거의 필요하지 않습니다. 하지만 주어진 작업공간에서 더 이상 빌드가 발생하지 않을 것으로 알려진 경우 스크립트에 유용할 수 있습니다.

shutdown는 정수 인수 (MB 단위)가 필요한 --iff_heap_size_greater_than _n_ 옵션을 허용합니다. 이 플래그를 지정하면 종료는 이미 사용된 메모리의 양에 따라 결정됩니다. 이는 많은 빌드를 시작하는 스크립트에 유용합니다. Bazel 서버의 메모리 누수가 발생하면 가끔 비정상 종료될 수 있기 때문입니다. 조건부 재시작을 실행하면 이 조건이 선점됩니다.

info

info 명령어는 Bazel 서버 인스턴스 또는 특정 빌드 구성과 연결된 다양한 값을 출력합니다. (빌드를 구동하는 스크립트에서 사용할 수 있음)

info 명령어는 아래 목록의 키 중 하나인 단일 인수 (선택사항)도 허용합니다. 이 경우 bazel info key는 해당 키 값만 출력합니다. (Bazel을 스크립팅할 때 특히 편리합니다. sed -ne /key:/s/key://p을 통해 결과를 파이핑할 필요가 없기 때문입니다.

구성과 상관없는 데이터

  • release: 이 Bazel 인스턴스의 출시 라벨이거나 출시 바이너리가 아닌 경우 '개발 버전'입니다.
  • workspace는 기본 작업공간 디렉터리의 절대 경로입니다.
  • install_base: 현재 Bazel 인스턴스에서 사용하는 설치 디렉터리의 절대 경로입니다. Bazel은 내부적으로 필요한 실행 파일을 이 디렉터리 아래에 설치합니다.

  • output_base: 이 Bazel 인스턴스에서 현재 사용자 및 작업공간 조합에 사용하는 기본 출력 디렉터리의 절대 경로입니다. Bazel은 모든 스크래치 및 빌드 출력을 이 디렉터리 아래에 넣습니다.

  • execution_root: output_base 아래의 실행 루트 디렉터리에 대한 절대 경로입니다. 이 디렉터리는 빌드 중에 실행된 명령어에 액세스할 수 있는 모든 파일의 루트이며 이러한 명령어의 작업 디렉터리입니다. 작업공간 디렉터리에 쓸 수 있으면 이 디렉터리를 가리키는 bazel-<workspace> 심볼릭 링크가 저장됩니다.

  • output_path: 빌드 명령어의 결과로 실제로 생성된 모든 파일에 사용되는 실행 루트 아래의 출력 디렉터리에 대한 절대 경로입니다. 작업공간 디렉터리가 쓰기 가능한 경우 이 디렉터리에 연결되는 bazel-out라는 심볼릭 링크가 있습니다.

  • server_pid: Bazel 서버 프로세스의 프로세스 ID입니다.

  • server_log: Bazel 서버의 디버그 로그 파일에 대한 절대 경로입니다. 이 파일에는 Bazel 서버의 전체 기간 동안 모든 명령어에 대한 디버깅 정보가 포함되어 있으며 Bazel 개발자와 고급 사용자가 인적 사용을 위한 것입니다.

  • command_log: 명령어 로그 파일의 절대 경로입니다. 여기에는 가장 최근 Bazel 명령어의 인터리브 처리된 stdout 및 stderr 스트림이 포함됩니다. bazel info을 실행하면 이 파일의 콘텐츠를 덮어쓰게 됩니다. 이 파일이 최신 Bazel 명령어가 되기 때문입니다. 하지만 --output_base 또는 --output_user_root 옵션의 설정을 변경하지 않는 한 명령어 로그 파일의 위치는 변경되지 않습니다.

  • used-heap-size, committed-heap-size, max-heap-size: 다양한 JVM 힙 크기 매개변수를 보고합니다. 현재 사용 중인 메모리, 현재 시스템에서 JVM에 제공할 수 있는 메모리로 가능한 최대 할당입니다.

  • gc-count, gc-time: 이 Bazel 서버가 시작된 이후의 가비지 컬렉션의 누적 개수와 이를 수행하는 데 소요된 시간입니다. 이러한 값은 모든 빌드가 시작될 때 재설정되지는 않습니다.

  • package_path: bazel에서 패키지를 검색할 콜론으로 구분된 경로 목록입니다. --package_path 빌드 명령줄 인수와 동일한 형식을 갖습니다.

예: Bazel 서버의 프로세스 ID

% bazel info server_pid
1285

구성 관련 데이터

이러한 데이터는 bazel info에 전달된 구성 옵션(예: --cpu, --compilation_mode 등)의 영향을 받을 수 있습니다. info 명령어는 종속 항목 분석을 제어하는 모든 옵션을 허용합니다. 이 중 일부는 빌드의 출력 디렉터리 위치, 컴파일러 선택 등을 결정하기 때문입니다.

  • bazel-bin, bazel-testlogs, bazel-genfiles: 빌드에서 생성된 프로그램이 있는 bazel-* 디렉터리의 절대 경로를 보고합니다. 이는 대체로 항상 성공하지는 않지만 빌드에 성공한 후 기본 작업공간 디렉터리에 생성된 bazel-* 심볼릭 링크와 동일합니다. 하지만 작업공간 디렉터리가 읽기 전용이면 bazel-* 심볼릭 링크를 만들 수 없습니다. 심볼릭 링크가 존재한다고 가정하는 대신 bazel info에 의해 보고된 값을 사용하는 스크립트가 더 강력해집니다.
  • 전체 'Make' 환경 --show_make_env 플래그를 지정하면 현재 구성의 'Make' 환경에 있는 모든 변수 (예: CC, GLIBC_VERSION)도 표시됩니다. BUILD 파일 내에서 $(CC) 또는 varref("CC") 구문을 사용하여 액세스하는 변수입니다.

예: 현재 구성을 위한 C++ 컴파일러 'Make' 환경의 $(CC) 변수이므로 --show_make_env 플래그가 필요합니다.

  % bazel info --show_make_env -c opt COMPILATION_MODE
  opt

예: 현재 구성의 bazel-bin 출력 디렉터리 어떤 이유로든 bazel-bin 심볼릭 링크를 만들 수 없는 경우에도(예: 읽기 전용 디렉터리에서 빌드하는 경우) 올바른 정확성이 보장됩니다.

% bazel info --cpu=piii bazel-bin
/var/tmp/_bazel_johndoe/fbd0e8a34f61ce5d491e3da69d959fe6/execroot/io_bazel/bazel-out/piii-opt/bin
% bazel info --cpu=k8 bazel-bin
/var/tmp/_bazel_johndoe/fbd0e8a34f61ce5d491e3da69d959fe6/execroot/io_bazel/bazel-out/k8-opt/bin

version, --version

버전 명령어는 빌드된 Bazel 바이너리의 버전 세부정보(빌드된 변경 목록 및 날짜 포함)를 출력합니다. 이러한 최신 Bazel 버전이 있는지 또는 버그를 신고하는지 확인하는 데 특히 유용합니다. 몇 가지 흥미로운 값은 다음과 같습니다.

  • changelist: 이 버전의 Bazel이 출시된 변경 목록입니다.
  • label: 이 Bazel 인스턴스의 출시 라벨이거나 출시 바이너리가 아닌 경우 '개발 버전'입니다. 버그 신고 시 매우 유용합니다.

bazel --version는 다른 인수 없이 bazel version --gnu_format와 동일한 출력을 내보냅니다. 단, Bazel 서버를 시작하거나 서버 보관 파일을 압축 해제하는 부작용이 없을 수 있습니다. bazel --version은 작업공간 디렉터리가 없어도 어디서나 실행할 수 있습니다.

mobile-install

mobile-install 명령어는 휴대기기에 앱을 설치합니다. 현재 ART를 실행하는 Android 기기만 지원됩니다.

자세한 내용은 bazel 모바일 설치를 참조하세요.

다음과 같은 옵션이 지원됩니다.

--incremental

설정된 경우 Bazel은 앱을 증분 설치, 즉 마지막 빌드 이후 변경된 부분만 설치하려고 시도합니다. AndroidManifest.xml, 네이티브 코드 또는 자바 리소스 (예: Class.getResource()에서 참조된 리소스)에서 참조되는 리소스는 업데이트할 수 없습니다. 이러한 항목이 변경되면 이 옵션을 생략해야 합니다. Bazel의 취지와는 달리, Android 플랫폼의 제한사항으로 인해사용자의 책임 이 명령어가 적절한 시점과 전체 설치가 필요한 경우를 파악할 수 있습니다.

Marshmallow 이상에서 기기를 사용하는 경우 --split_apks 플래그를 사용하는 것이 좋습니다.

--split_apks

분할 APK를 사용하여 기기에 애플리케이션을 설치하고 업데이트할지 여부입니다. Marshmallow 이상이 설치된 기기에서만 작동합니다. --split_apks를 사용할 때는 --incremental 플래그가 필요하지 않습니다.

--start_app

설치 후 깨 a한 상태에서 앱을 시작합니다. --start=COLD과 같습니다.

--debug_app

디버거가 연결될 때까지 기다린 후 설치 후 정리 상태로 앱을 시작합니다. --start=DEBUG과 같습니다.

--start=_start_type_

앱 설치 후 시작 방식 지원되는 _start_type_s는 다음과 같습니다.

  • NO 앱이 시작되지 않습니다. 기본 옵션으로,
  • COLD 설치 후 정리 상태에서 앱을 시작합니다.
  • WARM 증분 설치 시 애플리케이션 상태를 보존하고 복원합니다.
  • DEBUG디버거를 기다렸다가 설치 후 앱을 깨 state한 상태로 시작합니다.

--adb=path

사용할 adb 바이너리를 나타냅니다.

기본값은 --android_sdk에서 지정된 Android SDK의 adb를 사용하는 것입니다.

--adb_arg=serial

adb의 추가 인수입니다. 이는 명령줄에서 하위 명령어 앞에 오며 일반적으로 설치할 기기를 지정하는 데 사용됩니다. 예를 들어 사용할 Android 기기나 에뮬레이터를 선택하려면 다음 단계를 따르세요.

% bazel mobile-install --adb_arg=-s --adb_arg=deadbeef

다음과 같이 adb를 호출합니다.

adb -s deadbeef install ...

--incremental_install_verbosity=number

증분 설치의 상세 출력입니다. 디버그 로깅을 콘솔에 출력하려면 1로 설정합니다.

dump

dump 명령어는 Bazel 서버의 내부 상태의 덤프를 stdout하여 출력합니다. 이 명령어는 주로 Bazel 개발자가 사용하도록 작성되었으므로 이 명령어의 출력은 지정되지 않으며 변경될 수 있습니다.

기본적으로 명령어는 Bazel 상태의 특정 영역을 덤프할 수 있는 옵션이 표시된 도움말 메시지를 출력합니다. 내부 상태를 덤프하려면 옵션 중 하나 이상을 지정해야 합니다.

지원되는 옵션은 다음과 같습니다.

  • --action_cache는 작업 캐시 콘텐츠를 덤프합니다.
  • --packages는 패키지 캐시 콘텐츠를 덤프합니다.
  • --skyframe는 내부 Bazel 종속 항목 그래프의 상태를 덤프합니다.
  • --rules는 개수 및 작업 수를 포함하여 각 규칙 및 특성 클래스에 관한 규칙 요약을 덤프합니다. 여기에는 네이티브 및 Starlark 규칙이 모두 포함됩니다. 메모리 추적을 사용 설정하면 규칙의 메모리 사용도 출력됩니다.
  • --skylark_memorypprop 호환 .gz 파일을 지정된 경로로 덤프합니다. 이 작업을 하려면 메모리 추적을 사용 설정해야 합니다.

메모리 추적

일부 dump 명령어에는 메모리 추적이 필요합니다. 이 기능을 사용 설정하려면 시작 플래그를 Bazel에 전달해야 합니다.

  • --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar
  • --host_jvm_args=-DRULE_MEMORY_TRACKER=1

java-agent는 third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar에서 Bazel에 체크인되므로 Bazel 저장소를 유지할 위치에 맞게 $BAZEL을 조정해야 합니다.

모든 명령어에 이 옵션을 Bazel에 계속 전달해야 합니다. 그러지 않으면 서버가 다시 시작됩니다.

예:

    % bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar \
    --host_jvm_args=-DRULE_MEMORY_TRACKER=1 \
    build --nobuild <targets>

    # Dump rules
    % bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar \
    --host_jvm_args=-DRULE_MEMORY_TRACKER=1 \
    dump --rules

    # Dump Starlark heap and analyze it with pprof
    % bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar \
    --host_jvm_args=-DRULE_MEMORY_TRACKER=1 \
    dump --skylark_memory=$HOME/prof.gz
    % pprof -flame $HOME/prof.gz

analyze-profile

analyze-profile 명령어는 --profile 옵션을 사용하여 빌드 중에 이전에 수집된 데이터를 분석합니다. 빌드 실행 분석을 수행하거나 지정된 형식으로 데이터를 내보낼 수 있는 여러 옵션을 제공합니다.

다음과 같은 옵션이 지원됩니다.

  • --dump는 수집된 모든 데이터를 사람이 읽을 수 있는 형식으로 표시합니다. 하지만 이는 다른 형식을 아직 지원하지 않습니다.

형식 세부정보 및 사용 도움말은 프로파일링으로 성능 문제 해결을 참조하세요.

canonicalize-flags

Bazel 명령어의 옵션 목록을 가져와 동일한 효과를 가진 옵션 목록을 반환하는 canonicalize-flags 명령어 새 옵션 목록은 표준입니다. 예를 들어 효과가 동일한 두 개의 옵션 목록은 같은 새 목록으로 표준화됩니다.

--for_command 옵션을 사용하여 여러 명령어 중에서 선택할 수 있습니다. 현재 buildtest만 지원됩니다. 지정된 명령어가 지원하지 않는 옵션으로 인해 오류가 발생합니다.

예를 들면 다음과 같습니다.

  % bazel canonicalize-flags -- --config=any_name --test_tag_filters="-lint"
  --config=any_name
  --test_tag_filters=-lint

시작 옵션

이 섹션에 설명된 옵션은 Bazel 서버 프로세스에서 사용하는 자바 가상 머신의 시작에 영향을 미치며 해당 서버에서 처리되는 모든 후속 명령어에 적용됩니다. 이미 실행 중인 Bazel 서버가 있고 시작 옵션이 일치하지 않으면 서버가 다시 시작됩니다.

이 섹션에 설명된 모든 옵션은 --key=value 또는 --key value 구문을 사용하여 지정해야 합니다. 또한 이러한 옵션은 Bazel 명령어 이름 앞에 표시되어야 합니다. startup --key=value를 사용하여 .bazelrc 파일에 나열합니다.

--output_base=dir

이 옵션에는 쓰기 가능한 디렉터리를 지정해야 하는 경로 인수가 필요합니다. Bazel이 이 위치를 사용하여 모든 출력을 씁니다. 또한 출력 베이스는 클라이언트가 Bazel 서버를 찾는 데 사용하는 키입니다. 출력 베이스를 변경하면 명령어를 처리할 서버를 변경합니다.

기본적으로 출력 베이스는 사용자의 로그인 이름과 작업공간 디렉터리의 이름 (실제로 MD5 다이제스트)에서 파생되므로 일반적인 값은 /var/tmp/google/_bazel_johndoe/d41d8cd98f00b204e9800998ecf8427e입니다.

예:

 OUTPUT_BASE=/var/tmp/google/_bazel_johndoe/custom_output_base
% bazel --output_base ${OUTPUT_BASE}1 build //foo  &  bazel --output_base ${OUTPUT_BASE}2 build //bar

이 명령어에서 두 Bazel 명령어는 동시에 실행됩니다 (셸로 인해).&amp; 연산자) 각각 다른 Bazel 서버 인스턴스를 사용합니다 (출력 베이스가 다르기 때문). 반대로 기본 출력 베이스가 두 명령어에서 모두 사용된 경우 두 요청은 동일한 서버로 전송되어 순차적으로 처리됩니다. 즉, 먼저 //foo를 빌드한 다음 //bar의 증분 빌드입니다.

--output_user_root=dir

출력 및 설치 기반이 생성되는 루트 디렉터리를 가리킵니다. 디렉터리는 존재하지 않거나 호출 사용자가 소유해야 합니다. 이전에는 여러 사용자가 공유한 디렉터리를 가리키는 것이 허용되었지만 더 이상 허용되지 않습니다. 문제 #11100이 해결되면 허용될 수 있습니다.

--output_base 옵션을 지정하면 --output_user_root를 사용하여 출력 베이스를 계산합니다.

설치 기반 위치는 --output_user_root 및 Bazel 내장 바이너리의 MD5 ID를 기준으로 계산됩니다.

파일 시스템 레이아웃에 더 나은 위치가 있다면 --output_user_root 옵션을 사용하여 모든 Bazel 출력 (설치 베이스 및 출력 베이스)의 대체 기본 위치를 선택할 수 있습니다.

--server_javabase=dir

Bazel 자체가 실행되는 자바 가상 머신을 지정합니다. 이 값은 JDK 또는 JRE가 포함된 디렉터리의 경로여야 합니다. 라벨은 허용되지 않습니다. 이 옵션은 Bazel 명령어 앞에 표시됩니다. 예를 들면 다음과 같습니다.

  % bazel --server_javabase=/usr/local/buildtools/java/jdk11 build //foo

이 플래그는 애플리케이션, 테스트, 도구 등과 같은 Bazel 하위 프로세스에서 사용하는 JVM에는 영향을 미치지 않습니다. 대신 빌드 옵션 --javabase 또는 --host_javabase를 사용합니다.

이 플래그의 이름은 이전에 명명되었습니다.--host_javabase ('왼쪽'이라고도 함)--host_javabase )이지만 빌드 플래그와 혼동되지 않도록 이름이 변경되었습니다.--host_javabase '오른쪽'이라고도 합니다.--host_javabase 참고).

--host_jvm_args=string

Bazel 자체가 실행되는 자바 가상 머신에 전달할 시작 옵션을 지정합니다. 스택 크기를 설정하는 데 사용할 수 있습니다. 예를 들면 다음과 같습니다.

  % bazel --host_jvm_args="-Xss256K" build //foo

이 옵션은 개별 인수로 여러 번 사용할 수 있습니다. 이 플래그를 설정할 필요는 거의 없습니다. 또한 공백으로 구분된 문자열 목록을 전달할 수 있으며 각 목록은 별도의 JVM 인수로 해석되지만 이 기능은 곧 지원 중단됩니다.

이는 Bazel의 하위 프로세스(애플리케이션, 테스트, 도구 등)에서 사용되는 JVM에는 영향을 미치지 않습니다. JVM 옵션을 실행 가능한 자바 프로그램에 전달하려면bazel run 또는 명령줄에서--jvm_flags 모두java_binaryjava_test 있습니다. 테스트에는 bazel test --test_arg=--jvm_flags=foo ...를 사용하세요.

--host_jvm_debug

이 옵션을 선택하면 자바 가상 머신이 Bazel 자체의 기본 메서드를 호출하기 전에 JDWP 호환 디버거의 연결을 기다립니다. 주로 Bazel 개발자가 사용합니다.

--autodetect_server_javabase

이 옵션을 사용하면 Bazel이 시작 시 설치된 JDK를 자동으로 검색하고 삽입된 JRE를 사용할 수 없는 경우 설치된 JRE로 대체합니다. --explicit_server_javabase를 사용하면 Bazel을 실행할 명시적 JRE를 선택할 수 있습니다.

--batch

일괄 모드는 Bazel이 표준 클라이언트/서버 모드를 사용하지 않고 대신 더 예측 가능한 시맨틱스를 위해 사용된 단일 명령어에 대한 Bazel 자바 프로세스를 실행합니다. 신호 처리, 작업 제어 및 환경 변수 상속과 관련하여 chroot 감옥에서 bazel을 실행하는 데 필요합니다.

배치 모드는 동일한 output_base 내에 적절한 큐 시맨틱스를 유지합니다. 즉, 동시 호출이 중복 없이 순서대로 처리됩니다. 일괄 모드 Bazel이 실행 중인 서버가 있는 클라이언트에서 실행되는 경우 명령어를 처리하기 전에 먼저 서버를 종료합니다.

Bazel이 배치 모드 또는 위에서 설명한 대체 모드를 사용하여 느리게 실행됩니다. 이는 빌드 파일 캐시가 메모리에 상주하므로 순차 일괄 호출 사이에 보존되지 않기 때문입니다. 따라서 연속 빌드와 같이 성능이 덜 중요한 경우에는 배치 모드를 사용하는 것이 더 합리적입니다.

--max_idle_secs=n

이 옵션은 Bazel 서버 프로세스가 마지막 클라이언트 요청 후 종료되기 전에 대기해야 하는 시간(초)을 지정합니다. 기본값은 10,800 (3시간)입니다. --max_idle_secs=0은 Bazel 서버 프로세스를 무기한으로 유지합니다.

이 옵션은 그렇지 않은 경우 Bazel을 호출하여 사용자의 머신에서 Bazel 서버 프로세스를 벗어나지 않도록 하는 스크립트에 사용할 수 있습니다. 예를 들어 사전 제출 스크립트는 사용자의 대기 중인 변경사항으로 인해 원치 않는 종속 항목이 유입되지 않도록 bazel query를 호출할 수 있습니다. 하지만 사용자가 해당 작업공간에서 최근 빌드를 완료하지 않은 경우 사전 제출 스크립트에서 하루 중 남은 시간 동안 유휴 상태로 유지되는 Bazel 서버를 시작하는 것이 바람직하지 않을 수 있습니다. 쿼리 요청에서 작은 --max_idle_secs 값을 지정하면 스크립트는 이 스크립트를 통해 새 서버가 시작된 경우 해당 서버가 즉시 종료되지만 서버가 이미 실행 중이었다면 일반적인 시간 동안 유휴 상태가 될 때까지 서버가 계속 실행됩니다. 물론 기존 서버의 유휴 타이머는 재설정됩니다.

--[no]shutdown_on_low_sys_mem

빌드 서버가 일정 시간 동안 유휴 상태였으면 이후 --max_idle_secs가 양수로 설정된 경우에는 시스템 메모리가 부족할 때 서버를 종료합니다. Linux만 해당됩니다.

빌드 서버는 max_idle_secs에 해당하는 유휴 검사를 실행하는 것 외에 서버가 일정 시간 동안 유휴 상태였던 이후 사용 가능한 시스템 메모리 모니터링을 시작합니다. 사용 가능한 시스템 메모리가 심각하게 부족해지면 서버가 종료됩니다.

--[no]block_for_lock

사용 설정하면 Bazel이 서버 잠금을 보유한 다른 Bazel 명령어가 완료될 때까지 기다린 후에 진행합니다. 사용 중지된 경우 Bazel이 잠금을 즉시 가져올 수 없는 경우 오류로 종료합니다.

개발자는 동일한 클라이언트의 다른 Bazel 명령어로 인한 긴 대기를 방지하기 위해 사전 제출 검사에서 이 속성을 사용할 수 있습니다.

--io_nice_level=n

최상의 IO 예약을 위해 0~7 사이의 수준을 설정합니다. 0이 가장 높고 7이 가장 낮습니다. 예상 스케줄러는 우선순위 4까지만 지정할 수 있습니다. 음수 값은 무시됩니다.

--batch_cpu_scheduling

Bazel에 batch CPU 예약을 사용합니다. 이 정책은 비대화형이지만 비슷한 값을 낮추고 싶지 않은 워크로드에 유용합니다. 'man 2 sched_setscheduler'를 참조하세요. 이 정책은 Bazel 처리량을 떨어뜨리는 대신 더 나은 시스템 상호작용을 제공할 수 있습니다.

기타 옵션

--[no]announce_rc

Bazel이 시작될 때 bazelrc 파일에서 읽은 명령어 옵션을 알릴지 여부를 제어합니다. (시작 옵션은 무조건 발표됩니다.)

--color (yes|no|auto)

이 옵션은 Bazel에서 색상을 사용하여 화면에서 출력을 강조표시할지 여부를 결정합니다.

이 옵션을 yes로 설정하면 색상 출력이 사용 설정됩니다. 이 옵션을 auto로 설정하면 Bazel은 출력이 터미널로 전송되고 TERM 환경 변수가 dumb, emacs 또는 xterm-mono입니다. 이 옵션을 no로 설정하면 출력이 단말기로 전달되는지와 TERM 환경 변수의 설정에 관계없이 색상 출력이 사용 중지됩니다.

--config=name

rc 파일에서 추가 구성 섹션을 선택합니다. 현재 command의 경우 이러한 섹션이 있다면 command:name에서도 옵션을 가져옵니다. 여러 구성 섹션에서 플래그를 추가하기 위해 여러 번 지정할 수 있습니다. 확장은 다른 정의를 참조할 수 있습니다 (예: 확장을 연결할 수 있음).

--curses (yes|no|auto)

이 옵션은 Bazel이 화면 출력에서 커서 컨트롤을 사용할지 결정합니다. 그러면 Bazel의 스크롤 데이터가 줄어들고 더 읽기 쉬운 출력 스트림이 생성됩니다. 이는 --color에서 원활하게 작동합니다.

이 옵션이 yes로 설정되면 커서 컨트롤 사용이 사용 설정됩니다. 이 옵션을 no로 설정하면 커서 컨트롤 사용이 중지됩니다. 이 옵션이 auto로 설정되면 --color=auto와 동일한 조건에서 커서 컨트롤 사용이 사용 설정됩니다.

--[no]show_timestamps

지정된 경우 Bazel에서 생성된 각 메시지에 타임스탬프가 추가되어 메시지가 표시된 시간이 지정됩니다.