이 페이지에서는 다양한 Bazel 명령어와 함께 사용할 수 있는 옵션을 설명합니다.
bazel build
, bazel run
, bazel test
등입니다. 이 페이지는 컴패니언입니다.
Build with Bazel의 Bazel 명령어 목록에 추가합니다.
대상 문법
build
또는 test
와 같은 일부 명령어는 타겟 목록에서 작동할 수 있습니다. 그들은
라벨보다 더 유연한 구문을 사용합니다. 이 내용은
빌드할 대상 지정.
옵션
다음 섹션에서는
있습니다. --long
가 도움말 명령어에 사용되면
도움말 메시지는 해당 문장의 의미, 유형 및
기본값을 설정할 수 있습니다.
대부분의 옵션은 한 번만 지정할 수 있습니다. 여러 번 지정하면 마지막 인스턴스가 적용됩니다 여러 번 지정할 수 있는 옵션은 다음과 같습니다. '여러 번 사용할 수 있습니다'라는 문구가 온라인 도움말에 명시되어 있습니다.
패키지 위치
--package_path
이 옵션은 지정된 패키지의 BUILD 파일을 찾습니다.
Bazel은 패키지 경로를 검색하여 패키지를 찾습니다. 콜론입니다. 각각이 루트인 bazel 디렉토리로 구성된 순서가 지정된 부분 소스 트리입니다.
--package_path
옵션을 사용하여 커스텀 패키지 경로를 지정하려면 다음 안내를 따르세요.
% bazel build --package_path %workspace%:/some/other/root
패키지 경로 요소는 다음 세 가지 형식으로 지정할 수 있습니다.
- 첫 번째 문자가
/
이면 경로는 절대 경로입니다. - 경로가
%workspace%
로 시작하면 상대 경로입니다. 가장 가까운 bazel 디렉터리로 복사하겠습니다. 예를 들어 작업 디렉터리가/home/bob/clients/bob_client/bazel/foo
이면 package-path의%workspace%
문자열이 펼쳐집니다./home/bob/clients/bob_client/bazel
에게 전송합니다. - 다른 항목은 작업 디렉터리를 기준으로 가져옵니다.
이런 일은 일반적으로 당신이 하려는 일이 아닙니다.
bazel 작업공간 아래의 디렉터리에서 Bazel을 사용하면 예기치 않게 동작할 수 있습니다.
예를 들어 package-path 요소
.
를 사용하는 경우 cd 명령어로/home/bob/clients/bob_client/bazel/foo
, 패키지 에서 해결됩니다./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='^//(first/project|second/project):'` | 지정된 패키지의 출력을 표시합니다. |
`--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++ 컴파일이나 링크가 아닙니다. 따라서 C 관련 옵션을 전달할 수 있습니다.
(예: -Wno-pointer-sign
)(--conlyopt
사용)
--cxxopt=cc-option
이 옵션은 C++ 소스 파일 컴파일
--copt
와 유사하지만 C++ 컴파일에만 적용됩니다.
C 컴파일이나 링크가 아닙니다. 따라서 C++ 관련 옵션을 전달할 수 있습니다.
(예: -fpermissive
또는 -fno-implicit-templates
) --cxxopt
사용.
예를 들면 다음과 같습니다.
% bazel build --cxxopt="-fpermissive" --cxxopt="-Wno-error" //foo/cruddy_code
--linkopt=linker-option
이 옵션은 연결 시 컴파일러에 전달할 인수를 사용합니다.
--copt
와 유사하지만 연결에만 적용됩니다.
컴파일하는 것이 아니라 따라서 특정 언어만 사용하는 컴파일러 옵션을
연결 시 (예: -lssp
또는 -Wl,--wrap,abort
)
--linkopt
사용 예를 들면 다음과 같습니다.
% 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_mode
가
fastbuild
입니다.
% 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
생성 시 strip
명령어에 전달하는 추가 옵션입니다.
*.stripped
바이너리 기본값은 -S -p
입니다. 이 옵션은 여러 번 사용할 수 있습니다.
--fdo_instrument=profile-output-dir
--fdo_instrument
옵션을 사용하면
FDO (의견 지향 최적화) 프로필 출력은
자동으로 실행됩니다 GCC의 경우, 제공된 인수는
.gcda 파일의 객체별 파일 디렉터리 트리의 디렉터리 프리픽스
각 .o 파일의 프로필 정보가 포함됩니다.
프로필 데이터 트리가 생성되면 프로필 트리
압축되어 있어야 하며,
--fdo_optimize=profile-zip
FDO 최적화 컴파일을 사용 설정하는 Bazel 옵션
LLVM 컴파일러의 경우 인수는 원시 LLVM 프로필이 있는 디렉터리이기도 합니다.
데이터 파일이 덤프됩니다. 예를 들면 --fdo_instrument=/path/to/rawprof/dir/
입니다.
--fdo_instrument
및 --fdo_optimize
옵션은 동시에 사용할 수 없습니다.
--fdo_optimize=profile-zip
--fdo_optimize
옵션을 사용하면
FDO (피드백)를 수행하기 위한 객체별 파일 프로필 정보
방향성 최적화) 최적화를 사용해야 합니다. GCC의 경우 인수는
이전에 생성된 파일 트리가 포함된 ZIP 파일이
각 .o 파일의 프로필 정보가 포함된 .gcda 파일의 역할을 합니다.
또는 제공된 인수가 자동 프로필을 가리킬 수 있습니다. .afdo로 식별됩니다.
LLVM 컴파일러의 경우 제공된 인수가 색인이 생성된 LLVM을 가리켜야 합니다. llvm-profdata 도구에서 준비한 프로필 출력 파일이며 .profdata가 있어야 합니다. 확장자가 포함됩니다.
--fdo_instrument
및 --fdo_optimize
옵션은 동시에 사용할 수 없습니다.
--[no]output_symbol_counts
활성화하면 C++ 실행 바이너리의 골드 호출 링크가 각각
기호 카운트 파일 (--print-symbol-counts
골드를 통해)
옵션). 파일은 각 링커 입력에 대해
바이너리에서 사용된 기호의 수를 나타냅니다.
이 정보는 불필요한 링크 종속성을 추적하는 데 사용할 수 있습니다.
기호 카운트 파일이 다음 이름과 함께 바이너리의 출력 경로에 기록됩니다.
[targetname].sc
이 옵션은 기본적으로 사용하지 않도록 설정되어 있습니다.
--java_language_version=version
이 옵션은 Java 소스의 버전을 지정합니다. 예를 들면 다음과 같습니다.
% bazel build --java_language_version=8 java/com/example/common/foo:all
컴파일하고 Java 8 사양과 호환되는 구조체만 허용합니다.
기본값은 11입니다. -->
가능한 값은 8, 9, 10, 11, 14, 15이며
default_java_toolchain
를 사용하여 커스텀 Java 도구 모음 등록
--tool_java_language_version=version
빌드 중에 실행되는 도구를 빌드하는 데 사용되는 Java 언어 버전입니다. 기본값은 11입니다.
--java_runtime_version=version
이 옵션은 코드를 실행하고 테스트를 실행하는 데 사용할 JVM의 버전을 지정합니다. 예를 들면 다음과 같습니다.
% bazel run --java_runtime_version=remotejdk_11 java/com/example/common/foo:java_application
원격 저장소에서 JDK 11을 다운로드하고 이를 사용하여 Java 애플리케이션을 실행합니다.
기본값은 localjdk
입니다.
가능한 값은 localjdk
, localjdk_version
,
remotejdk_11
, remote_jdk17
다음 중 하나를 사용하여 커스텀 JVM을 등록하여 값을 확장할 수 있습니다.
local_java_repository
또는 remote_java_repostory
저장소 규칙
--tool_java_runtime_version=version
빌드 중에 필요한 도구를 실행하는 데 사용되는 JVM 버전입니다.
기본값은 remotejdk_11
입니다.
--jvmopt=jvm-option
이 옵션을 사용하면 옵션 인수를 Java VM에 전달할 수 있습니다. 또한 하나의 큰 논쟁으로 논쟁하거나 개별 논쟁으로 여러 번 논의할 수 있습니다. 예를 들면 다음과 같습니다.
% bazel build --jvmopt="-server -Xms256m" java/com/example/common/foo:all
는 서버 VM을 사용하여 모든 Java 바이너리를 실행하고 VM의 시작 힙 크기를 256MB로 설정합니다.
--javacopt=javac-option
이 옵션을 사용하면 옵션 인수를 javac에 전달할 수 있습니다. 또한 하나의 큰 논쟁으로 논쟁하거나 개별 논쟁으로 여러 번 논의할 수 있습니다. 예를 들면 다음과 같습니다.
% bazel build --javacopt="-g:source,lines" //myprojects:prog
javac 기본 디버그 정보로 java_binary를 다시 빌드합니다. (bazel 기본값 대신)
이 옵션은 Bazel 내장 기본 옵션 다음에 javac로 전달됩니다. javac, 규칙별 옵션 앞에 오는 문자와 숫자를 입력합니다. 마지막 사양은 javac에 대한 모든 옵션이 적용됩니다. javac의 기본 옵션은 다음과 같습니다.
-source 8 -target 8 -encoding UTF-8
--strict_java_deps (default|strict|off|warn|error)
이 옵션은 javac가 누락된 직접 종속 항목을 검사하는지 여부를 제어합니다. Java 대상은 직접 사용되는 모든 대상을 명시적으로 다음과 같이 선언해야 합니다. 종속 항목이 포함됩니다 이 플래그는 javac에 실제로 사용된 jar을 결정하도록 지시합니다. 각 Java 파일의 유형을 확인하고 출력이 아닌 경우 경고/오류 표시 종속 항목을 반환합니다.
off
는 검사가 사용 중지되었음을 의미합니다.warn
는 javac가 다음의 표준 자바 경고를 생성한다는 의미입니다. 누락된 각 직접 종속 항목에[strict]
유형default
,strict
및error
모두 javac가 경고 대신 오류를 생성하여 현재 빌드에 실패할 수 있습니다. 플래그가 지정되지 않은 경우의 기본 동작이기도 합니다.
시맨틱 빌드
이러한 옵션은 빌드 명령어 및/또는 출력 파일 콘텐츠에 영향을 미칩니다.
--compilation_mode (fastbuild|opt|dbg)
(-c)
--compilation_mode
옵션 (종종 -c
으로 단축됨)
특히 -c opt
)는 fastbuild
, dbg
의 인수를 사용합니다.
또는 opt
이며, 다양한 C/C++ 코드 생성에 영향을 미칩니다.
최적화 수준과 완전성 등의
디버그 테이블만 지원합니다 Bazel은 각각에 서로 다른 출력 디렉터리를 사용합니다.
다른 컴파일 모드로 변환하므로, 코드 실행 없이 모드 간에
매번 완전히 다시 빌드해야 하기 때문입니다.
fastbuild
는 최대한 빠르게 빌드하는 것을 의미합니다. 최소한의 디버깅 정보 (-gmlt -Wl,-S
)를 생성하고 최적화하지 않습니다. 이는 기본값입니다. 참고:-DNDEBUG
는 설정되지 않습니다.dbg
는 디버깅이 사용 설정된 상태에서 빌드를 의미합니다 (-g
). gdb 또는 다른 디버거를 사용할 수 있습니다.opt
는 최적화가 사용 설정된 상태로 빌드하고assert()
통화 사용 중지 (-O2 -DNDEBUG
)opt
모드에서는 디버깅 정보가 생성되지 않습니다.--copt -g
도 전달하지 않는 한
--cpu=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
플래그
기본적으로extra_actions
요청된 대상의 실행이 예약됩니다.
--experimental_extra_action_filter
에서 다음 일정으로 예약 제한:
소유자의 라벨이 지정된 라벨과 일치하는 extra_actions
사용할 수 있습니다.
다음 예시에서는 extra_actions
의 예약을 제한합니다.
소유자의 라벨에 '/bar/'가 포함된 작업에만 적용됩니다.
% bazel build --experimental_action_listener=//test:al //foo/... \ --experimental_extra_action_filter=.*/bar/.*
--host_cpu=cpu
이 옵션은 CPU 아키텍처의 이름을 지정합니다. 호스트 도구를 빌드하는 데 사용됩니다.
--fat_apk_cpu=cpu[,cpu]*
전이 deps
의 C/C++ 라이브러리를 빌드할 CPU는
android_binary
개의 규칙이 있습니다. 다른 C/C++ 규칙은 영향을 받지 않습니다. 예를 들어
cc_library
이(가) android_binary
규칙의 전이 deps
에 표시되고
cc_binary
규칙은 다음과 같이 cc_library
가 두 번 이상 빌드됩니다.
--fat_apk_cpu
로 지정된 각 CPU에 대해 한 번씩
android_binary
규칙에서 실행되고, 한 번은 실행되어야 하며, 한 번은
cc_binary
규칙의 경우 --cpu
기본값은 armeabi-v7a
입니다.
하나의 .so
파일이 생성되고 APK에 패키징됩니다.
--fat_apk_cpu
로 지정된 각 CPU입니다 .so
파일의 이름
android_binary
규칙의 이름 앞에 'lib'를 접두사로 추가합니다. 예를 들어
android_binary
가 'foo'이면 파일은 libfoo.so
입니다.
--per_file_copt=[+-]regex[,[+-]regex]...@option[,option]...
포함 정규식 중 하나와 일치하는 라벨 또는 실행 경로가 있는 C++ 파일(있는 경우)
표현식 중 어떤 것과도 일치하지 않는 표현식이 작성됩니다.
선택할 수 있습니다. 라벨 일치에는 라벨의 표준 형식이 사용됩니다.
(즉, //package
:label_name
)입니다.
실행 경로는 기본 이름을 포함한 작업공간 디렉터리의 상대 경로입니다. (확장자 포함)을 사용합니다. 또한 플랫폼에 종속된 접두사도 모두 포함됩니다.
생성된 파일 (예: genrule 출력) 일치
Bazel은 실행 경로만 사용할 수 있습니다. 정규 표현식이 '//'로 시작하면 안 됩니다.
어떤 실행 경로와도 일치하지 않기 때문입니다 패키지 이름은 다음과 같이 사용할 수 있습니다.
--per_file_copt=base/.*\.pb\.cc@-g0
이 은(는) 다음과 같이 매치됩니다.
.pb.cc
파일을 base
라는 디렉터리에 저장합니다.
이 옵션은 여러 번 사용할 수 있습니다.
이 옵션은 사용된 컴파일 모드와 관계없이 적용됩니다. 예를 들어
--compilation_mode=opt
로 컴파일하고 일부를 선택적으로 컴파일합니다.
더 강력한 최적화가 사용 설정된 파일 또는 최적화가 사용 중지된 파일.
주의사항: 일부 파일이 디버그 기호로 선택적으로 컴파일되는 경우 기호는
연결 중에 삭제될 수 있습니다. 이를 방지하려면
--strip=never
구문: [+-]regex[,[+-]regex]...@option[,option]...
여기서
regex
는 접두사로
포함 패턴을 식별하는 +
및 식별하는 -
사용
제외할 수 있는 패턴을 찾습니다. option
는 전달되는 임의 옵션을 나타냅니다.
C++ 컴파일러에 추가하는 것입니다. 옵션에 ,
가 포함된 경우 이와 같이 따옴표로 묶어야 합니다.
\,
옵션에는 @
도 포함될 수 있습니다. 첫 번째만
@
는 정규 표현식을 옵션과 구분하는 데 사용됩니다.
예:
<ph type="x-smartling-placeholder">--per_file_copt=//foo:.*\.cc,-//foo:file\.cc@-O0,-fprofile-arcs
</ph>
명령어에 -O0
및 -fprofile-arcs
옵션을 추가합니다.
file.cc
를 제외한 //foo/
의 모든 .cc
파일에 관한 C++ 컴파일러의 행입니다.
--dynamic_mode=mode
C++ 바이너리를 동적으로 링크하여 linkstatic 속성을 생성합니다.
모드:
auto
: 플랫폼 종속 모드로 변환됩니다. Linux의 경우default
, cygwin의 경우off
입니다.default
: bazel에서 동적 연결 여부를 선택할 수 있습니다. 자세한 내용은 linkstatic을 참고하세요. 확인할 수 있습니다fully
: 모든 타겟을 동적으로 연결합니다. 이렇게 하면 연결 시간을 줄이고 결과 바이너리의 크기를 줄입니다.off
: 다음의 모든 타겟 연결 대부분 정적 모드입니다. linkopt에서-static
가 설정된 경우 타겟이 완전히 정적으로 변경됩니다.
--fission (yes|no|[dbg][,opt][,fastbuild])
Fission을 사용 설정합니다. 이렇게 하면 C++ 디버그 정보를 .o 파일이 아닌 전용 .dwo 파일에 쓸 수 있습니다. 그렇지 않으면 이동합니다. 이렇게 하면 링크에 대한 입력 크기가 크게 줄어들고 링크 시간이 단축됩니다.
[dbg][,opt][,fastbuild]
로 설정된 경우 (예:
--fission=dbg,fastbuild
), 분할이 사용 설정됨
할 수 있습니다. 이는 bazelrc에 유용합니다.
설정을 변경할 수 있습니다. yes
로 설정하면 Fission이 사용 설정됩니다.
하고 있습니다. no
로 설정하면 Fission이 사용 중지됩니다.
하고 있습니다. 기본값은 no
입니다.
--force_ignore_dash_static
이 플래그가 설정된 경우 linkopt의 모든 -static
옵션
cc_*
규칙 BUILD 파일은 무시됩니다. 이 기능은
C++ 강화 빌드의 해결 방법을 참조하세요.
--[no]force_pic
이를 활성화하면 모든 C++ 컴파일이 위치에 독립적인 코드("-fPIC")를 생성합니다. 링크는 비 PIC 라이브러리보다 PIC 사전 빌드된 라이브러리를 선호하며 다른 실행 파일("-pie") 기본값은 사용 중지됨입니다.
--android_resource_shrinking
android_binary 규칙에 대해 리소스 축소를 수행할지 선택합니다. 이 Reduce_resources 속성을 android_binary 규칙 자세한 내용은 해당 규칙에 대한 문서를 참조하세요. 기본값은 사용 중지입니다.
--custom_malloc=malloc-library-target
지정된 경우 항상 지정된 malloc 구현을 사용하여 모든
malloc="target"
속성(
기본값 (malloc
를 지정하지 않음)
--crosstool_top=label
이 옵션은 Crosstool 컴파일러 도구 모음의 위치를 지정합니다.
빌드 중 모든 C++ 컴파일에 사용됩니다. Bazel이 살펴볼 겁니다
CROSSTOOL 파일의 위치를 찾고 이를 사용하여 자동으로
--compiler
에 대한 설정입니다.
--host_crosstool_top=label
지정하지 않으면 Bazel이 --crosstool_top
값을 사용하여 컴파일합니다.
호스트 구성의 모든 코드에 적용됩니다(예: 빌드 중에 실행되는 도구). 이 플래그의 주요 목적은
크로스 컴파일을 사용 설정하는 것입니다.
--apple_crosstool_top=label
전이 deps
의 C/C++ 규칙을 컴파일하는 데 사용할 크로스툴입니다.
objc*, ios*, apple* 규칙 이러한 대상의 경우 이 플래그는
--crosstool_top
--android_crosstool_top=label
전이 deps
의 C/C++ 규칙을 컴파일하는 데 사용할 크로스툴입니다.
android_binary
개의 규칙이 있습니다. 이는
다른 크로스툴이 필요합니다. 기본적으로 크로스툴(crosstool)을 사용하여
WORKSPACE 파일에 있는 android_ndk_repository
규칙에 의해 생성됩니다.
--fat_apk_cpu
도 참조하세요.
--compiler=version
이 옵션은 C/C++ 컴파일러 버전을 지정합니다 (예: gcc-4.1.0
).
빌드 중 바이너리 컴파일에 사용됩니다. 원하는 경우
CROSSTOOL 파일을 사용해야 합니다.
지정할 수 있습니다.
--android_sdk=label
이 옵션은 Android SDK/플랫폼 도구 모음을 지정합니다. Android 런타임 라이브러리를 빌드하는 데 사용되는 있습니다.
android_sdk_repository
WORKSPACE 파일에 정의되어 있습니다.
--java_toolchain=label
이 옵션은 Java를 컴파일하는 데 사용되는 java_툴체인의 라벨을 지정합니다. 소스 파일
--host_java_toolchain=label
지정하지 않으면 bazel이 --java_toolchain
값을 사용하여 컴파일합니다.
호스트 구성에 있는 코드(예: 빌드 중에 실행되는 도구의 경우) 이 플래그의 주요 목적은
크로스 컴파일을 사용 설정하는 것입니다.
--javabase=(label)
이 옵션은 bazel 실행에 사용할 기본 Java 설치의 label을 설정합니다.
bazel 테스트 및 java_binary
및 java_binary
에 의해 빌드된 Java 바이너리의 경우
규칙 java_test
개. JAVABASE
및 JAVA
'만들기' 변수는 이 옵션에서 파생됩니다.
--host_javabase=label
이 옵션은 호스트 구성에서 사용할 기본 자바 설치의 라벨을 설정합니다. JavaBuilder 및 Singlejar를 비롯한 호스트 빌드 도구를 예로 들 수 있습니다.
이 옵션은 Java를 컴파일하는 데 사용되는 Java 컴파일러를 선택하지 않습니다.
소스 파일 컴파일러는
--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 Genrule)을 정의합니다. 자세한 내용은 --spawn_strategy: 지원되는 경우 그 효과에 대해 알아보겠습니다.
--strategy_regexp=<filter,filter,...>=<strategy>
이 옵션은 설명이 있는 명령어를 실행하는 데 사용해야 하는 전략을 지정합니다.
regex_filter
와 일치해야 합니다. 자세한 내용은
--per_file_copt:
regex_filter 일치 자세한 내용은
--spawn_strategy: 지원되는 경우
그 효과에 대해 알아보겠습니다.
설명과 일치하는 마지막 regex_filter
가 사용됩니다. 이 옵션은
전략을 지정하는 데 사용되는 다른 플래그입니다.
- 예:
--strategy_regexp=//foo.*\\.cc,-//foo/bar=local
는 다음을 사용하여 작업을 실행한다는 의미입니다. 설명이 //foo.*.cc와 일치하지만 //foo/bar가 아닌 경우local
전략입니다. - 예:
--strategy_regexp='Compiling.*/bar=local' --strategy_regexp=Compiling=sandboxed
'Compiling //foo/bar/baz'를 실행합니다.sandboxed
전략 사용, 그러나 반전 주문이local
로 실행됩니다. - 예:
--strategy_regexp='Compiling.*/bar=local,sandboxed'
실행 '//foo/bar/baz 컴파일'local
전략으로 대체하며 실패 시sandboxed
입니다.
--genrule_strategy=strategy
지원 중단된 --strategy=Genrule=strategy
약어입니다.
--jobs=n
(-j)
이 옵션은 정수 인수를 취하며 프로세스 중에 동시에 실행되어야 하는 작업 수를 빌드의 실행 단계입니다
--progress_report_interval=n
Bazel은 정기적으로 실행되지 않는 작업에 대한 진행 상황 보고서를
종료되지 않은 경우에 발생합니다 (예: 장기 실행 테스트). 이 옵션은
보고 빈도, 진행률은 n
마다 인쇄됩니다.
초입니다.
기본값은 0이며, 이는 증분 알고리즘을 의미합니다. 첫 번째는 보고서는 10초 후에 인쇄되고, 그 이후에는 30초 후에 진행률은 1분마다 한 번씩 보고됩니다.
bazel이
--curses
: 진행률이 1초마다 보고됩니다.
--local_{ram,cpu}_resources resources or resource expression
이 옵션은 로컬 리소스의 양 (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 코어 수를 로컬 시스템 구성에서 직접 가져옵니다.
--[no]build_runfile_links
기본적으로 사용 설정되는 이 옵션은 실행 파일이
테스트 및 바이너리의 심볼릭 링크를 출력 디렉터리에 빌드해야 합니다.
--nobuild_runfile_links
를 사용하면 유용할 수 있습니다
오버헤드 발생 없이 모든 타겟이 컴파일되는지 검증하기
살펴보겠습니다
테스트 (또는 애플리케이션)가 실행될 때 테스트의 런타임 데이터는
한곳에 함께 모이게 됩니다 Bazel의
출력 트리, 이 'runfiles' 트리는 일반적으로
테스트를 실행합니다.
테스트 실행 중에
$TEST_SRCDIR/workspace/packagename/filename
테스트에서 모든 파일에 액세스할 수 있도록 보장하는 실행 파일 트리
종속 항목이 선언되어 있고 그 이상의 것은 없습니다. 작성자:
기본적으로 실행 파일 트리는
필수 파일에 대한 심볼릭 링크를 제공합니다. 링크 집합이 증가하면
일부 대규모 빌드의 경우
전체 빌드 시간에 크게 기여합니다. 특히
각 개별 테스트 (또는 애플리케이션)에는 자체 실행 파일 트리가 필요합니다.
--[no]build_runfile_manifests
기본적으로 사용 설정되는 이 옵션은 실행 파일 매니페스트가
출력 트리에 작성되어야 합니다.
사용 중지하면 --nobuild_runfile_links
가 적용됩니다.
원격으로 테스트를 실행할 때 사용 중지할 수 있습니다. 실행 파일 트리가 메모리 내 매니페스트에서 원격으로 생성할 수 있습니다.
--[no]discard_analysis_cache
이 옵션을 사용 설정하면 Bazel에서 분석 캐시를 삭제합니다. 실행 시작 직전에 추가 메모리를 확보하여 실행 단계에서 약 10%로 계산됩니다. 단점은 추가 증분 빌드가 느려진다는 것입니다. 참고 항목 메모리 절약 모드를 사용합니다.
--[no]keep_going
(-k)
GNU Make에서와 같이 빌드의 실행 단계는 오류가 발생했습니다. 때로는 최대한 많은 노력을 기울일 수 있습니다 이 옵션을 사용하면 지정된 경우 빌드가 자동으로 기본 요건을 성공적으로 빌드한 모든 대상을 빌드할 수 있지만 오류가 무시됩니다.
이 옵션은 일반적으로
분석 단계에도 영향을 줍니다.
지정되지만 그중 일부만
분석이 완료되면 오류가 발생하면서 빌드가 중지됩니다.
--keep_going
가 지정되지 않는 한, 이 경우에는
타겟에 대해서만 실행 단계로 진행됩니다.
확인할 수 있습니다
--[no]use_ijars
이 옵션을 사용하면 java_library
타겟의 방식이 변경됩니다.
Bazel이 컴파일했습니다 각 포드의 출력과
java_library
: 종속 항목을 컴파일하는 경우
대상 java_library
개, Bazel이 인터페이스 jar 만들기
비공개 구성원 (공개,
기본 (패키지) 메서드 및 필드 액세스)을 사용하며
인터페이스 jar을 사용하여 종속 타겟을 컴파일할 수 있습니다. 이렇게 하면
변경 시에만 변경 사항이 있을 때 재컴파일하지 않아도 됨
메서드 본문 또는 클래스의 비공개 멤버입니다.
--[no]interface_shared_objects
이 옵션은 인터페이스 공유 객체를 사용 설정하여 바이너리 및 다른 공유 라이브러리는 공유 객체의 인터페이스에 종속됩니다. 책임감 있는 AI를 구현할 수 있습니다. 구현만 변경되면 Bazel은 변경된 공유 라이브러리에 종속되는 타겟을 다시 빌드하는 것을 피할 수 있습니다. 있습니다.
출력 선택
이러한 옵션은 빌드 또는 테스트할 항목을 결정합니다.
--[no]build
이 옵션을 사용하면 빌드의 실행 단계가 발생합니다. 입니다 기본적으로 사용 설정되어 있습니다. 스위치가 꺼지면 실행 단계는 첫 번째 두 단계인 로딩과 분석만 발생하게 됩니다.
이 옵션은 BUILD 파일의 유효성을 검사하고 실제로 아무것도 빌드하지 않아도 됩니다.
--[no]build_tests_only
지정하면 Bazel은 *_test
를 실행하는 데 필요한 항목만 빌드합니다.
및 필터링되지 않은 규칙 test_suite
개가
크기,
timeout,
태그 또는
언어.
지정하면 Bazel이 명령줄에 지정된 다른 대상을 무시합니다.
기본적으로 이 옵션은 사용 중지되어 있으며 Bazel이 모든 항목을 빌드합니다.
요청된 항목(*_test
및 test_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++ 및 Java 동일한 언어 공간에 있는 규칙이 우선적으로 선택됩니다. 대상 환경설정이 같은 여러 규칙을 만들 수 있는데, 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
태그로 태그가 지정되지 않았습니다.
기본적으로 테스트 태그 필터링은 적용되지 않습니다. 또한
테스트의 size
및 local
태그
있습니다.
--test_lang_filters=lang[,lang]*
공식 *_test
규칙이 있는 언어의 테스트 언어 목록을 쉼표로 구분하여 지정합니다.
전체 목록은 빌드 백과사전을 참고하세요. 각
언어 앞에 '-'를 추가할 수도 있습니다. 제외하도록 지정하고
있습니다. 각 언어에 사용되는 이름은
*_test
규칙의 언어 접두사. 예를 들면 다음과 같습니다.
cc
, java
또는 sh
입니다.
지정하면 Bazel이 테스트 (또는 --build_tests_only
인 경우 빌드)
도 지정) 지정된 언어의 테스트 타겟만 가능합니다.
예를 들면 다음과 같습니다.
% bazel test --test_lang_filters=cc,java foo/...
는 C/C++ 및 Java 테스트(
각각 cc_test
및 java_test
규칙)
foo/...
동안,
% bazel test --test_lang_filters=-sh,-java foo/...
foo/...
에서 다음을 제외한 모든 테스트를 실행합니다.
sh_test
및 java_test
테스트
기본적으로 테스트 언어 필터링은 적용되지 않습니다.
--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
초당 최대 1개의 진행률 메시지를 표시합니다.
여기서 n는 실수입니다.
이 옵션의 기본값은 0.02입니다. 즉, bazel이 진행률을 제한합니다.
0.02초마다 1개로 변환합니다
--show_result=n
이 옵션은 마지막에 결과 정보의 인쇄를 제어합니다.
bazel build
명령어의 출력 결과입니다. 기본적으로 단일
빌드 타겟이 지정되면 Bazel은
타겟이 성공적으로 최신으로 업데이트되었는지 여부를 확인할 수 있으며,
타겟이 만든 출력 파일의 목록입니다. 여러 개의
타겟이 지정되면 결과 정보가 표시되지 않습니다.
결과 정보는 단일
대상 또는 몇 개의 대상(대규모 빌드의 경우)(예: 전체 최상위 수준)
이 정보가 부담스럽고 산만해질 수 있습니다.
이 옵션을 통해 이를 제어할 수 있습니다. --show_result
최대 타겟 수인 정수 인수를 사용합니다.
전체 결과 정보를 출력해야 합니다. 기본적으로
값은 1입니다. 이 임계값 이상의 결과 정보는
표시됩니다. 따라서 0은 결과를
항상 표시되지 않으며 값이 매우 크면
항상 출력됩니다.
사용자가 정기적으로 다음 값을 선택할 경우 중간 정도의 값을 선택할 수 있습니다.
소규모의 대상 (예:
(컴파일-편집-테스트 주기 동안) 및 대규모 타겟 그룹이
(예를 들어 새 작업공간을 만들거나 기존 워크로드를
회귀 테스트). 전자의 경우 결과 정보는
후자의 경우에는 덜 유용하죠 Google의
옵션을 통해 전달될 수 있으며 이는
.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 셸과 호환되는 구문으로 인쇄됩니다.
쉽게 복사하여 셸 명령 프롬프트에 붙여넣을 수 있습니다.
(둘러싸는 괄호는 셸을
cd
및 exec
호출 잊지 말고 복사하세요.
그러나 다음과 같은 일부 명령어는 Bazel 내에서 내부적으로 구현됩니다.
심볼릭 링크 트리를 만들 수 있습니다. 이 경우 표시할 명령줄이 없습니다.
출력에 --subcommands=pretty_print
가 전달될 수 있습니다.
명령어 인수를 한 줄이 아닌 목록으로 표시합니다. 이로 인해
긴 명령줄을 더 쉽게 읽을 수 있습니다
아래의 --verbose_failures도 참조하세요.
도구 친화적인 형식으로 파일에 하위 명령어를 로깅하는 방법은 다음을 참고하세요. --execution_log_json_file 및 --execution_log_binary_file.
--verbose_failures
이 옵션을 사용하면 Bazel의 실행 단계에서 전체 명령줄이 출력됩니다. 확인할 수 있습니다 이는 인코더-디코더 아키텍처를 확인할 수 있습니다
실패한 명령어는 Bourne 셸 호환 구문에 출력됩니다. 복사하여 붙여넣기용 Cloud Run이 있습니다
작업공간 상태
이 옵션을 사용하여 '스탬프' Bazel 빌드 바이너리:
바이너리(예: 소스 제어 버전 또는 기타 작업공간 관련 정보) 이때
stamp
속성을 지원하는 규칙(예:
genrule
, cc_binary
등
--workspace_status_command=program
이 플래그를 사용하면 Bazel이 각 빌드 전에 실행하는 바이너리를 지정할 수 있습니다. 이 프로그램은 현재 소스 제어 버전과 같은 작업공간의 상태에 대한 정보
플래그 값은 네이티브 프로그램의 경로여야 합니다. Linux/macOS에서는 모든 실행 파일이 될 수 있습니다. Windows에서는 네이티브 바이너리(일반적으로 '.exe', '.bat', '.cmd')여야 합니다. 파일에서 참조됩니다.
프로그램은 0개 이상의 키-값 쌍을 표준 출력에 출력해야 합니다. 각 줄에 하나씩 항목이 하나씩 표시됩니다. 0으로 종료됩니다 (그렇지 않으면 빌드가 실패합니다). 키 이름은 무엇이든 될 수 있지만 대문자와 밑줄을 사용해야 합니다. 키 이름 뒤의 첫 번째 공백은 키 이름 뒤에 오는 값으로 사용됩니다. 값은 줄의 나머지 부분입니다 (추가 공백 포함). 키도 값은 여러 줄에 걸쳐 있을 수 있습니다. 키가 중복되면 안 됩니다.
Bazel은 키를 'stable' 버킷 두 개로 분할합니다. 'volatile'을 사용할 수 있습니다. (이름 '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 에포크 이후 빌드 시간(초)입니다(값System.currentTimeMillis()
를 천으로 나눈 값)FORMATTED_DATE
: 형식이 지정된 빌드 시간입니다.yyyy MMM d HH mm ss EEE
(예: 2023년 6월 2일 01 44 29 금요일)(UTC 기준)
Linux/macOS에서는 --workspace_status_command=/bin/true
을
true
가 아무 작업도 하지 않으므로 작업공간 상태 가져오기를 사용 중지합니다 (종료).
출력되지 않습니다. 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
작업을 실행하기 위한 실행 플랫폼으로 사용할 수 있는 플랫폼입니다. 플랫폼은 정확한 타겟 또는 대상 패턴으로 지정할 수 있습니다. 이러한 WORKSPACE 파일에 선언된 플랫폼보다 먼저 register_execution_platforms()를 사용하세요.
--extra_toolchains=labels
도구 모음 확인 중에 고려해야 할 도구 모음 규칙입니다. 도구 모음 정확한 타겟이나 대상 패턴으로 지정할 수 있습니다. 이러한 도구 모음은 WORKSPACE 파일에 선언된 것보다 먼저 register_toolchains()를 사용하세요.
--toolchain_resolution_debug=regex
도구 모음 유형이 일치하는 경우 도구 모음을 찾는 동안 디버그 정보를 출력합니다.
정규식을 사용하면 됩니다. 여러 정규식은 쉼표로 구분할 수 있습니다. 정규식은 다음과 같습니다.
처음에 -
를 사용하여 무효화됩니다. 이는 개발자가
도구 모음 누락으로 인한 디버깅 실패가 발생한 Bazel 또는 Starlark 규칙의 50%를 지원합니다.
기타
--flag_alias=alias_name=target_path
긴 Starlark 빌드 설정을 더 짧은 이름으로 결합하는 데 사용되는 편의 플래그입니다. 자세한 내용은 자세한 내용은 Starlark 구성
--symlink_prefix=string
생성된 편의 심볼릭 링크의 접두사를 변경합니다. 이
심볼릭 링크 접두사의 기본값은 bazel-
이며
심볼릭 링크 bazel-bin
, bazel-testlogs
및
bazel-genfiles
입니다.
어떤 이유로든 심볼릭 링크를 생성할 수 없는 경우 경고가 빌드는 여전히 성공한 것으로 간주됩니다. 특히 이렇게 하면 읽기 전용 디렉토리나 쓸 수 있는 권한을 가집니다. 정보 제공을 위해 인쇄된 경로 메시지는 심볼릭 링크가 예상 위치 다시 말해, 입력 데이터의 정확성에 생성 중인 심볼릭 링크에 의존할 수 없는 경우에도 마찬가지입니다.
이 옵션의 일반적인 값은 다음과 같습니다.
심볼릭 링크 생성 억제:
--symlink_prefix=/
를 사용하면 Bazel이bazel-out
및bazel-<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 사용량에 대한 통계 pprof 형식으로 프로필을 작성합니다. 이름이 지정된 파일에 추가합니다.
이 옵션을 사용하면 과도한 계산으로 인해 로드 및 분석 속도가 느려집니다. 예를 들면 다음과 같습니다.
$ 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을 사용하면 다른 스크립트에서와 동일한 문제가 발생합니다. kube-APIserver입니다 자세한 내용은 스크립트에서 Bazel 호출하기 특히 다음 옵션은 를 사용하는 것이 좋습니다.
이러한 옵션도 중요합니다.
--package_path
--symlink_prefix
: 여러 구성의 빌드를 관리하고 각 빌드를 구별하는 것이 고유한 식별자가 있는 경우(예: '64비트') '32비트'). 이 옵션은bazel-bin
등의 심볼릭 링크를 구분합니다.
테스트 실행
bazel을 사용하여 테스트를 빌드하고 실행하려면 bazel test
를 입력한 후
테스트 대상의 이름입니다.
기본적으로 이 명령어는 빌드와 테스트를 동시에 실행합니다.
활동, 지정된 모든 타겟 (비 테스트 포함)을 빌드합니다.
대상) 및 테스트
가능한 한 빨리 *_test
및 test_suite
타겟
전제조건이 구축되어 있습니다. 즉, 테스트 실행이
건물과 인터리브 처리되어 있습니다. 이렇게 하면 일반적으로
빨라집니다.
bazel test
옵션
--cache_test_results=(yes|no|auto)
(-t
)
이 옵션이 '자동'으로 설정된 경우 기본값인 경우 Bazel은 다음 조건이 적용됩니다.
- Bazel이 테스트 또는 종속 항목의 변경사항을 감지함
- 테스트가
external
로 표시됩니다. --runs_per_test
로 여러 번의 테스트 실행이 요청됨- 테스트에 실패했습니다
'아니요'인 경우 모든 테스트가 무조건 실행됩니다.
'예'인 경우 캐싱 동작은 자동과 동일합니다.
예외적으로 테스트 실패와 테스트 실행을
--runs_per_test
에서 이 옵션을 기본적으로 사용 설정한 사용자
.bazelrc
파일은
약어 -t
(사용) 또는 -t-
(사용 중지)
특정 실행에서 기본값을
재정의하는 데 편리합니다
--check_tests_up_to_date
이 옵션은 Bazel에 테스트를 실행하지 않고 확인 및 보고만 하도록 지시합니다. 확인할 수 있습니다 확인되지 않은 테스트가 있는 경우 또는 테스트 결과가 오래된 경우 (예: 소스 코드나 빌드 옵션이 변경된 경우 Bazel이 오류 메시지('테스트 결과가 최신이 아님')가 표시되면 상태가 'NO STATUS'로 표시됨 (색상 출력이 활성화된 경우 빨간색)으로 표시되고 0이 아닌 종료 코드를 반환합니다.
또한 이 옵션은
[--check_up_to_date](#check-up-to-date)
동작
이 옵션은 사전 제출 검토에 유용할 수 있습니다.
--test_verbose_timeout_warnings
이 옵션은 테스트 제한 시간이 초과되면 사용자에게 명시적으로 경고하도록 Bazel에 지시합니다. 훨씬 더 오래 걸릴 수 있습니다. 테스트에서 제한 시간은 불안정하지 않도록 설정해야 하며, 테스트 시간이 시간 제한을 너무 관대하게 설정하면 예기치 않게 발생하는 실제 문제를 숨길 수 있습니다.
예를 들어 일반적으로 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
플래그:
- 없으면 실행이 실패하면 전체 테스트가 실패합니다.
- 있는 경우 동일한 샤드에서 두 번 실행되면 통과와 실패가 반환되고, 테스트에서는 다른 실행 실패로 인해 있습니다.
숫자를 하나만 지정하면 모든 테스트가 해당 횟수만큼 실행됩니다.
또는 다음 구문을 사용하여 정규 표현식을 지정할 수 있습니다.
regex@number 이렇게 하면 --runs_per_test
의 효과가 대상에 제한됩니다.
정규식과 일치하는 항목 (--runs_per_test=^//pizza:.*@4
에서 모든 테스트 실행)
//pizza/
회 미만).
이 --runs_per_test
형식은 두 번 이상 지정할 수 있습니다.
--[no]runs_per_test_detects_flakes
이 옵션을 지정하면 (기본적으로 지정되지 않음) Bazel은 불안정한 감지를 감지합니다.
--runs_per_test
을 통해 샤드를 테스트합니다. 단일 샤드에 대해 하나 이상이 실행되는 경우
동일한 샤드 패스에 대해 하나 이상의 실행이 실패할 경우 대상은
깃발의 불안정한 것으로 간주됩니다. 지정하지 않으면 대상은
확인할 수 있습니다
--test_summary=output_style
테스트 결과 요약을 표시하는 방법을 지정합니다.
short
는 각 테스트의 결과를 다음의 이름과 함께 출력합니다. 테스트에 실패하면 테스트 출력이 포함된 파일을 반환합니다. 이 설정이 기본 설정입니다.terse
(short
과 유사하지만 더 짧은 버전): 인쇄 전용 통과하지 못한 테스트에 관한 정보detailed
는 실패한 각 테스트 사례를 출력합니다. 확인할 수 있습니다 테스트 출력 파일의 이름은 생략됩니다.none
는 테스트 요약을 출력하지 않습니다.
--test_output=output_style
테스트 출력이 표시되는 방식을 지정합니다.
summary
는 각 테스트의 통과 또는 실패했습니다. 또한 실패한 테스트의 출력 로그 파일 이름을 표시합니다. 요약 빌드가 끝날 때 출력됩니다 (빌드 중에는 간단한 진행 상황 메시지만 표시). 이것이 기본 동작입니다.errors
는 실패한 테스트에서 결합된 stdout/stderr 출력을 전송합니다. 테스트가 완료된 직후에 stdout으로만 푸시하여 동시 테스트의 테스트 출력은 서로 인터리브 처리되지 않습니다. 위의 요약 출력에 따라 빌드에서 요약을 출력합니다.all
는errors
와 비슷하지만 테스트를 통과한 테스트를 포함한 모든 테스트가 포함됩니다.streamed
는 각 테스트의 stdout/stderr 출력을 스트리밍합니다. 있습니다.
--java_debug
이 옵션을 사용하면 Java 테스트의 Java Virtual Machine이
테스트를 시작하기 전 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
지정된 수의 테스트를 사용하여 모든 테스트의 제한 시간 값을 재정의합니다. 초를 새 제한 시간 값으로 사용할 수 있습니다. 값이 하나만 제공된 경우 모든 테스트 제한 시간 카테고리에 사용됩니다.
또는 쉼표로 구분된 4개의 값을 제공할 수 있습니다. 짧은 테스트, 중간 테스트, 긴 테스트, 영구 테스트에 대한 개별 시간 제한( 주문). 어떤 형식이든 테스트 크기에 대해 0 또는 음수 값이면 지정된 제한 시간 카테고리에 대한 기본 제한 시간으로 테스트 작성 페이지에 정의되어 있습니다. 기본적으로 Bazel은 모든 테스트에 이러한 제한 시간을 테스트 크기에서 시간 제한 제한을 추론하고 명시적으로 설정됩니다
제한 시간 카테고리가 크기 는 해당 제한 시간이 크기 태그입니다. 따라서 '작은' 크기에 대한 테스트는 'long'을 선언하는 제한 시간이 지나면 '대규모' 명시적 테스트에는 시간 초과
--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'
테스트 선택
출력 선택 옵션에 설명된 대로, 크기별로 테스트를 필터링할 수 있으며 timeout, 태그 또는 언어. 편의성 일반 이름 필터가 특정 필터 인수를 테스트 실행기에 추가합니다.
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
이는 다음의 --run_under
옵션과 효과가 같습니다.
bazel test
(위 참고)
bazel test
로 실행되는 테스트가 아닌 bazel
run
에서 실행되는 명령어에 적용된다는 점을 제외하면
라벨 아래에서 실행할 수 없습니다.
Bazel의 로깅 출력 필터링
bazel run
로 바이너리를 호출할 때 Bazel은 Bazel의 로깅 출력을 출력합니다.
바이너리라는 것을 배웠습니다 로그의 노이즈를 줄이려면
--ui_event_filters
를 사용하여 Bazel 자체의 출력을 억제하고
--noshow_progress
플래그.
예:
bazel run --ui_event_filters=-info,-stdout,-stderr --noshow_progress //java/myapp:myapp
테스트 실행
bazel run
는 또한 테스트 바이너리를 실행할 수 있으며, 이는 다음과 같은 효과가 있습니다.
에 설명된 환경과 근접하게 테스트를 실행하여
테스트 작성. 다음
--test_*
인수는 이러한 방식으로 테스트를 실행할 때 다음과 같은 효과가 있습니다.
--test_arg
빌드 출력 정리
clean
명령어
Bazel에는 Make 명령어와 유사한 clean
명령어가 있습니다.
수행된 모든 빌드 구성의 출력 디렉터리를 삭제합니다.
이 Bazel 인스턴스, 또는 이 Bazel 인스턴스에 의해 생성된 전체 작업 트리에
Bazel 인스턴스에 액세스하고 내부 캐시를 재설정합니다.
명령줄 옵션, 모든 구성의 출력 디렉터리
정리됩니다.
각 Bazel 인스턴스는 단일 작업공간과 연결되어 있으므로
clean
명령어는 실행한 모든 빌드의 모든 출력을 삭제합니다.
해당 작업공간에서 Bazel 인스턴스로
연결할 수 있습니다
Bazel에서 만든 전체 작업 트리를 완전히 삭제하기 위해
--expunge
옵션을 지정할 수 있습니다. 날짜
--expunge
로 실행되면 클린 명령어는
전체 출력 기본 트리를 삭제합니다. 이는 빌드와 더불어
출력에는 Bazel이 만든 모든 임시 파일이 포함됩니다. 또한
클린 후 Bazel 서버를 중지합니다. 이는 shutdown
명령어와 같습니다. 예를 들어
Bazel 인스턴스의 모든 디스크 및 메모리 트레이스를 정리하는 경우
지정합니다.
% bazel clean --expunge
또는 다음을 사용하여 백그라운드에서 영구 삭제할 수 있습니다.
--expunge_async
Bazel 명령어를 호출하는 것이 안전함
비동기 영구 삭제가 계속 실행되는 동안
동일한 클라이언트가 될 수 있습니다
clean
명령어는 주로 다음과 같은 수단으로 제공됩니다.
더 이상 필요하지 않은 작업공간을 위한 디스크 공간 회수
Bazel의 증분 재빌드는
완벽하므로 clean
를 사용하여 일관된 데이터를 복구할 수 있습니다.
상태 정보를 제공합니다
Bazel의 설계는 이러한 문제를 해결할 수 있고
이러한 버그는 수정해야 하는 우선순위가 높습니다. 만약
도구에서 잘못된 증분 빌드를 찾고, 버그 신고를 제출하고, 버그를 신고한 적이 있음
clean
를 사용하는 것보다 좋습니다.
종속 항목 그래프 쿼리
Bazel에는 종속 항목 그래프를 확인합니다. 쿼리 언어는 쿼리와 cquery라는 두 명령어를 사용합니다. 배포와 테스트의 로드 단계 후에 쿼리가 실행된다는 분석 단계 후에 cquery가 실행됩니다. 이러한 도구는 많은 소프트웨어 엔지니어링 작업에 귀중한 도움이 됩니다.
쿼리 언어는 그래프에 대한 대수 연산 이 프로세스에 대해서는
Bazel 쿼리 참조 자세한 내용은 해당 문서를 참조하세요. 쿼리별 명령줄 옵션에 관한 쿼리가 포함됩니다
쿼리 도구는 여러 개의 명령줄을
옵션을 선택합니다. --output
는 출력 형식을 선택합니다.
--[no]keep_going
(기본적으로 사용 중지되어 있음)로 인해 쿼리가
오류가 발생해도 계속 진행하기 위한 도구 이 동작은
오류 발생 시 불완전한 결과가 허용되지 않으면 사용 중지됩니다.
--[no]tool_deps
옵션
기본적으로 사용 설정되어 있지 않으면 비대상 구성의 종속 항목이
종속 항목 그래프를 보여줍니다.
--[no]implicit_deps
옵션이 기본적으로 사용 설정되어 있으면
쿼리가 작동하는 종속 항목 그래프에 포함될 암시적 종속 항목
암시적 종속 항목은 BUILD 파일에 명시적으로 지정되지 않은 종속 항목임
bazel이 추가한 것입니다
예: "다음의 정의 (BUILD 파일에) 위치 표시 PEBL 트리의 모든 테스트를 빌드하는 데 필요한 모든 genrule을 정의합니다."
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을 사용하여 빌드
인수를 지정하면 특정 항목에 대한 자세한 도움말이 표시됩니다.
주제에 대해 살펴보겠습니다. 대부분의 주제는 build
와 같은 Bazel 명령어입니다.
또는 query
를 지원하지만, 몇 가지 추가 도움말 주제가 있습니다.
일어납니다.
--[no]long
(-l
)
기본적으로 bazel help [topic]
는
주제와 관련된 옵션 요약입니다. 만약
--long
옵션 지정됨, 유형, 기본값
각 옵션에 대한 자세한 설명도 출력됩니다
shutdown
shutdown
를 사용하여 Bazel 서버 프로세스를 중지할 수 있습니다.
명령어와 함께 사용하면 됩니다 이 명령어를 사용하면 Bazel 서버가 종료되자마자
(예: 빌드 또는 기타 작업이 완료된 후)
명령어를 실행할 수 있습니다. 자세한 내용은
클라이언트/서버 구현.
Bazel 서버는 유휴 시간 제한 후 자체적으로 중지되므로 이 명령어는 거의 필요하지 않습니다. 하지만 스크립트에서 더 이상 빌드되지 않음을 알 수 있습니다.
shutdown
에서 결제 수단 1개를 허용합니다.
옵션(--iff_heap_size_greater_than _n_
)을 정의하며
에는 정수 인수 (MB)가 필요합니다. 지정하면
메모리의 양에 따라 달라집니다. 이것은
많은 빌드를 시작하는 스크립트에 유용합니다.
Bazel 서버의 누수가 발생하면
행사: 조건부 재시작을 수행하면 이 조건이 선점됩니다.
info
info
명령어는
Bazel 서버 인스턴스 또는 특정 빌드 구성을 사용할 수도 있습니다
이는 빌드를 구동하는 스크립트에서 사용할 수 있습니다.
info
명령어는 또한 단일 (선택사항)
인수로 사용됩니다. 이는 아래 목록에 있는 키 중 하나의 이름입니다.
이 경우 bazel info key
는 다음을 인쇄합니다.
해당 키 값을 반환합니다. 이 기능은
결과를 파이핑할 필요가 없으므로 Bazel을 스크립팅할 수 있습니다.
sed -ne /key:/s/key://p
를 통해 다음을 실행합니다.
구성과 무관한 데이터
release
: 이 Bazel의 출시 라벨 인스턴스 또는 '개발 버전' 출시되지 않은 경우 바이너리입니다.workspace
: 기본 작업공간의 절대 경로입니다. 를 참조하세요.install_base
: 설치의 절대 경로입니다. Bazel 인스턴스에서 현재 사용자를 위해 사용하는 디렉터리입니다. 바젤 이 디렉터리 아래에 내부적으로 필요한 실행 파일을 설치합니다.output_base
: 기본 출력의 절대 경로입니다. 현재 사용자를 위해 이 Bazel 인스턴스에서 사용하는 디렉터리와 작업공간이 조합됩니다. Bazel은 모든 스크래치를 써서 빌드해 봅니다. 이 디렉터리 아래에 출력됩니다.execution_root
: 실행의 절대 경로입니다. 루트 디렉터리를 입력합니다. 이 디렉터리는 모든 파일의 루트입니다. 명령에 액세스할 수 있으며 작동 중인 애플리케이션이 해당 명령어에 대한 것입니다 작업공간 디렉터리에 쓰기 가능한 경우 이름이bazel-<workspace>
인 심볼릭 링크 이 디렉터리를 가리키는 디렉터리에 배치됩니다output_path
: 출력의 절대 경로입니다. 모든 파일에 사용되는 실행 루트 아래에 있는 생성됩니다 작업공간 디렉터리가 쓰기 가능한 경우bazel-out
라는 심볼릭 링크가 해당 위치에 배치됩니다. 이 디렉터리로 이동합니다server_pid
: Bazel 서버의 프로세스 ID입니다. 프로세스입니다server_log
: Bazel 서버의 디버그 로그 파일의 절대 경로입니다. 이 파일에는 Bazel 서버로, Bazel 개발자와 고급 사용자가 수동으로 소비하도록 고안되었습니다.command_log
: 명령어 로그 파일의 절대 경로입니다. 여기에는 Bazel 명령어입니다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
에서 보고된 값을 반환합니다. 더 강력할 것입니다.- 전체
'만들기' 환경을 참조하세요.
--show_make_env
플래그가 다음과 같은 경우 현재 구성의 'Make'에 있는 모든 변수가 환경 표시됩니다 (예:CC
,GLIBC_VERSION
). 다음은$(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
version 명령어는 빌드된 Bazel에 관한 버전 세부정보를 출력합니다. 빌드한 변경 목록과 날짜를 포함하여 바이너리를 표시합니다. 이 측정항목은 애플리케이션이 최신 버전인지 여부를 판단하는 데 버그를 신고하려는 경우에 사용할 수 있습니다. 몇 가지 흥미로운 값은 다음과 같습니다.
changelist
: 이 버전의 Bazel이 출시되었습니다.label
: 이 Bazel의 출시 라벨 인스턴스 또는 '개발 버전' 출시되지 않은 경우 바이너리입니다. 버그를 신고할 때 매우 유용합니다.
bazel --version
는 다른 인수 없이 다음과 동일한 출력을 내보냅니다.
bazel version --gnu_format
(시작할 수 있는 부작용이 없는 경우 제외)
Bazel 서버 또는 서버 아카이브의 압축을 해제할 수 있습니다 bazel --version
는 다음에서 실행할 수 있습니다.
작업공간 디렉터리가 필요하지 않습니다.
mobile-install
mobile-install
명령어는 휴대기기에 앱을 설치합니다.
현재 ART를 실행하는 Android 기기만 지원됩니다.
자세한 내용은 bazel mobile-install을 참고하세요.
다음과 같은 옵션이 지원됩니다.
--incremental
이 옵션을 설정하면 Bazel은 점진적으로 앱을 설치하려 합니다.
개괄적으로 보여줍니다. 리소스를 업데이트할 수 없습니다.
AndroidManifest.xml
, 네이티브 코드 또는 Java에서 참조됨
리소스 (예: Class.getResource()
에서 참조하는 리소스) 만약
이 옵션은 생략해야 합니다. Bazel의 정신과 반대되는 행위
Android 플랫폼의 한계로 인해
이 명령어가 언제인지 알 수 있도록 사용자의 책임을
전체 설치가 필요할 때.
Marshmallow 이상이 탑재된 기기를 사용하는 경우
--split_apks
플래그
--split_apks
기기에 애플리케이션을 설치하고 업데이트하기 위해 분할 APK를 사용할지 여부입니다.
Marshmallow 이상을 실행하는 기기에서만 작동합니다. Note that the
--incremental
플래그
--split_apks
를 사용할 때는 필요하지 않습니다.
--start_app
설치 후 정상적인 상태에서 앱을 시작합니다. --start=COLD
와 같습니다.
--debug_app
설치 후 정리된 상태로 앱을 시작하기 전에 디버거가 연결될 때까지 대기합니다.
--start=DEBUG
와 같습니다.
--start=_start_type_
앱 설치 후 앱이 시작되는 방법입니다. 지원되는 _start_type_s는 다음과 같습니다.
NO
앱이 시작되지 않습니다. 이는 기본값입니다.COLD
설치 후 정리된 상태에서 앱을 시작합니다.WARM
증분 설치 시 애플리케이션 상태를 보존 및 복원합니다.DEBUG
다음 이후에 정리된 상태에서 앱을 시작하기 전에 디버거를 기다립니다. 설치해야 합니다
--adb=path
사용할 adb
바이너리를 나타냅니다.
기본값은 다음과 같이 지정된 Android SDK에서 adb를 사용하는 것입니다.
--android_sdk
--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 개발자가 사용하기 때문에 이 명령어의 출력은
는 지정되지 않으며 변경될 수 있습니다.
기본적으로 명령어는 가능한 요약 도움말 메시지를 출력합니다. Bazel 상태의 특정 영역을 덤프하는 옵션 덤프하기 위해 내부 상태가 아닌 경우 옵션 중 하나 이상을 지정해야 합니다.
다음과 같은 옵션이 지원됩니다.
--action_cache
는 작업 캐시 콘텐츠를 덤프합니다.--packages
는 패키지 캐시 콘텐츠를 덤프합니다.--skyframe
는 내부 Bazel 종속 항목 그래프의 상태를 덤프합니다.--rules
는 각 규칙 및 관점 클래스의 규칙 요약을 덤프합니다. 확인할 수 있습니다. 여기에는 네이티브 및 Starlark 규칙이 모두 포함됩니다. 메모리 추적을 사용 설정하면 규칙의 메모리 사용량도 출력됩니다--skylark_memory
는 pprof 호환 .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가 다음 위치에서 Bazel에 체크인됩니다.
third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar
이므로
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
canonicalize-flags
명령어 - Bazel 명령어의 옵션 목록을 가져와서
사용할 수 있습니다. 새로운 옵션 목록은 표준입니다. 예를 들어
효과가 동일한 두 개의 옵션 목록은 동일한 새 목록으로 정규화됩니다.
--for_command
옵션을 사용하면 다양한
명령어와 함께 사용하면 됩니다 현재 build
및 test
만
지원됩니다. 지정된 명령어에서 지원하지 않는 옵션으로 인해 오류가 발생합니다.
예를 들면 다음과 같습니다.
% bazel canonicalize-flags -- --config=any_name --test_tag_filters="-lint" --config=any_name --test_tag_filters=-lint
시작 옵션
이 섹션에 설명된 옵션은 Java 시작에 영향을 미칩니다. 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 명령어가 동시에 실행됩니다.
셸 &
연산자), 각각 다른 Bazel 사용
다른 출력 베이스를 기반으로 합니다.
반대로 기본 출력 베이스가 두 명령에 모두 사용된 경우에는
그러면 두 요청이 동일한 서버로 전송되어
순차적으로 처리: 먼저 //foo
를 빌드하고
//bar
의 증분 빌드로 인해 발생합니다.
--output_user_root=dir
출력 및 설치 기반이 생성되는 루트 디렉터리를 가리킵니다. 디렉터리 은(는) 존재하지 않거나 호출하는 사용자가 소유하고 있어야 합니다. 이전에는 이것은 다양한 사용자 간에 공유하는 디렉토리를 가리킬 수 있게 됨 더 이상 허용되지 않습니다. 이는 한 번만 허용될 수 있습니다. 문제 #11100이 해결되었습니다.
--output_base
옵션을 지정하면 이 옵션이
--output_user_root
를 사용하여 출력 기반을 계산합니다.
설치한 사용자 기반 위치는 다음을 기반으로 계산됩니다.
--output_user_root
및 삽입된 Bazel의 MD5 ID
바이너리를 제공합니다
--output_user_root
옵션을 사용하여
Bazel의 모든 출력 (설치한 사용자 수 및 출력)의 대체 기본 위치입니다.
base)를 사용할 수 있습니다.
--server_javabase=dir
Bazel 자체가 실행되는 Java 가상 머신을 지정합니다. 값은 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 자체가 있는 Java 가상 머신에 전달할 시작 옵션을 지정합니다. 실행할 수도 있습니다 다음과 같이 스택 크기를 설정하는 데 사용할 수 있습니다.
% bazel --host_jvm_args="-Xss256K" build //foo
이 옵션은 개별 인수로 여러 번 사용할 수 있습니다. 참고: 이 플래그를 설정할 필요가 거의 없습니다 공백으로 구분된 문자열 목록을 전달할 수도 있습니다. 각각 별도의 JVM 인수로 해석되지만 이 기능은 곧 지원 중단되었습니다.
이것이 Kubernetes에서 사용하는 JVM에는 영향을 미치지 않지만
Bazel의 하위 프로세스입니다. 통과하다
실행 자바 프로그램에 대한 JVM 옵션(bazel
run
로 실행하든 명령줄에서 실행하든 상관없이)
--jvm_flags
인수
모든 java_binary
및 java_test
프로그램
도움이 될 수 있습니다 또는 테스트의 경우 bazel test --test_arg=--jvm_flags=foo ...
를 사용합니다.
--host_jvm_debug
이 옵션을 사용하면 Java 가상 머신이 연결을 기다립니다. JDWP 호환 디버거에서 Bazel 자체의 기본 메서드를 호출합니다. 이 기능은 주로 Bazel 개발자용입니다
--autodetect_server_javabase
이 옵션을 사용하면 Bazel이 시작 시 설치된 JDK를 자동으로 검색합니다.
삽입된 JRE를 사용할 수 없는 경우 설치된 JRE로 대체합니다.
--explicit_server_javabase
는 다음 작업을 실행할 명시적 JRE를 선택하는 데 사용할 수 있습니다.
Bazel을 실행합니다
--batch
배치 모드를 사용하면 Bazel에서 표준 클라이언트/서버 모드를 지원하지만 대신 bazel을 실행합니다. 단일 명령어를 위한 Java 프로세스로, 좀 더 예측 가능한 방식으로 신호 처리, 작업 제어, 환경과 관련된 시맨틱스 변수 상속이 필요하며 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 명령어로 액세스할 수 없습니다
--io_nice_level=n
최적 I/O 예약을 위해 수준을 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