Trang này được dịch bởi Cloud Translation API.

Lệnh và tuỳ chọn

Trang này trình bày các tuỳ chọn có sẵn với nhiều lệnh Bazel, chẳng hạn như bazel build, bazel run và bazel test. Trang này đồng hành với danh sách các lệnh của Bazel trong Xây dựng bằng Bazel.

Cú pháp mục tiêu

Một số lệnh, chẳng hạn như build hoặc test, có thể hoạt động trên một danh sách mục tiêu. Các đối tượng này sử dụng cú pháp linh hoạt hơn so với nhãn, như đã nêu trong phần Chỉ định mục tiêu để tạo.

Tùy chọn

Các phần sau đây mô tả các tuỳ chọn có sẵn trong quá trình tạo bản dựng. Khi sử dụng --long trên một lệnh trợ giúp, thông báo trợ giúp trực tuyến sẽ cung cấp thông tin tóm tắt về ý nghĩa, loại và giá trị mặc định cho mỗi tuỳ chọn.

Hầu hết các tuỳ chọn chỉ có thể được chỉ định một lần. Khi được chỉ định nhiều lần, thực thể cuối cùng sẽ chiến thắng. Các tuỳ chọn có thể được chỉ định nhiều lần sẽ được xác định trong phần trợ giúp trực tuyến với nội dung "có thể được dùng nhiều lần".

Vị trí gói hàng

`--package_path`

Tuỳ chọn này chỉ định tập hợp các thư mục được tìm kiếm để tìm tệp BUILD cho một gói nhất định.

Bazel tìm thấy các gói bằng cách tìm kiếm đường dẫn gói. Đây là một danh sách có thứ tự được phân tách bằng dấu hai chấm, mỗi thư mục bazel là gốc của một phần cây nguồn.

Cách chỉ định đường dẫn gói tuỳ chỉnh bằng cách sử dụng tuỳ chọn --package_path:

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

Các phần tử đường dẫn gói có thể được chỉ định ở 3 định dạng:

Nếu ký tự đầu tiên là /, đường dẫn là tuyệt đối.
Nếu đường dẫn bắt đầu bằng %workspace%, thì đường dẫn đó sẽ được lấy tương ứng với thư mục bazel đóng gần nhất. Ví dụ: nếu thư mục đang hoạt động của bạn là /home/bob/clients/bob_client/bazel/foo, thì chuỗi %workspace% trong đường dẫn gói sẽ được mở rộng thành /home/bob/clients/bob_client/bazel.
Mọi hoạt động khác sẽ được thực hiện tương ứng với thư mục đang hoạt động. Thông thường, thao tác này không đúng ý bạn và có thể hoạt động không như mong muốn nếu bạn sử dụng Bazel từ các thư mục bên dưới không gian làm việc của bazel. Ví dụ: nếu bạn sử dụng phần tử đường dẫn gói ., sau đó được chuyển vào thư mục /home/bob/clients/bob_client/bazel/foo, thì các gói sẽ được phân giải từ thư mục /home/bob/clients/bob_client/bazel/foo.

Nếu bạn sử dụng đường dẫn gói không mặc định, hãy chỉ định đường dẫn đó trong tệp cấu hình Bazel để thuận tiện.

Bazel không yêu cầu bất kỳ gói nào nằm trong thư mục hiện tại, vì vậy, bạn có thể tạo bản dựng từ một không gian làm việc trống (bazel) nếu có thể tìm thấy tất cả các gói cần thiết ở nơi khác trên đường dẫn gói.

Ví dụ: Tạo bản dựng từ một ứng dụng trống

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

`--deleted_packages`

Tuỳ chọn này chỉ định một danh sách được phân tách bằng dấu phẩy các gói mà Bazel nên xem là đã xoá và không tìm cách tải từ bất kỳ thư mục nào trên đường dẫn gói. Bạn có thể dùng tính năng này để mô phỏng quá trình xoá các gói mà không thực sự xoá chúng.

Kiểm tra lỗi

Các tuỳ chọn này kiểm soát việc kiểm tra lỗi và/hoặc cảnh báo của Bazel.

`--[no]check_visibility`

Nếu bạn đặt tuỳ chọn này thành false, thì hệ thống sẽ giảm hạng chế độ kiểm tra chế độ hiển thị xuống còn cảnh báo. Giá trị mặc định của tuỳ chọn này là true (đúng) do đó, việc kiểm tra chế độ hiển thị được thực hiện theo mặc định.

`--output_filter=regex`

Tuỳ chọn --output_filter sẽ chỉ hiển thị cảnh báo bản dựng và cảnh báo biên dịch cho các mục tiêu khớp với biểu thức chính quy. Nếu một mục tiêu không khớp với biểu thức chính quy nhất định và quá trình thực thi thành công, thì đầu ra chuẩn và lỗi chuẩn của mục tiêu đó sẽ bị loại bỏ.

Dưới đây là một số giá trị điển hình cho lựa chọn này:

`--output_filter='^//(first/project\|second/project):'`	Cho thấy kết quả của các gói đã chỉ định.
`--output_filter='^//((?!(first/bad_project\|second/bad_project):).)*$'`	Không hiện kết quả cho các gói được chỉ định.
`--output_filter=`	Hiển thị mọi thứ.
`--output_filter=DONT_MATCH_ANYTHING`	Không hiển thị gì.

Cờ công cụ

Các tuỳ chọn này kiểm soát những tuỳ chọn mà Bazel sẽ chuyển sang các công cụ khác.

`--copt=cc-option`

Tuỳ chọn này nhận một đối số sẽ được truyền đến trình biên dịch. Đối số sẽ được chuyển đến trình biên dịch mỗi khi được gọi để xử lý trước, biên dịch và/hoặc tập hợp mã C, C++ hoặc trình kết hợp. Giá trị này sẽ không được chuyển khi liên kết.

Bạn có thể sử dụng tuỳ chọn này nhiều lần. Ví dụ:

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

sẽ biên dịch thư viện foo mà không cần bảng gỡ lỗi, tạo ra mã không phụ thuộc vào vị trí.

`--host_copt=cc-option`

Tuỳ chọn này lấy một đối số sẽ được truyền đến trình biên dịch cho các tệp nguồn được biên dịch trong cấu hình máy chủ lưu trữ. Tuỳ chọn này tương tự như tuỳ chọn --copt, nhưng chỉ áp dụng cho cấu hình máy chủ.

`--host_conlyopt=cc-option`

Tuỳ chọn này lấy một đối số sẽ được truyền đến trình biên dịch cho các tệp nguồn C được biên dịch trong cấu hình máy chủ lưu trữ. Tuỳ chọn này tương tự như tuỳ chọn --conlyopt, nhưng chỉ áp dụng cho cấu hình máy chủ lưu trữ.

`--host_cxxopt=cc-option`

Tuỳ chọn này lấy một đối số sẽ được truyền đến trình biên dịch cho các tệp nguồn C++ được biên dịch trong cấu hình máy chủ lưu trữ. Tuỳ chọn này tương tự như tuỳ chọn --cxxopt, nhưng chỉ áp dụng cho cấu hình máy chủ.

`--host_linkopt=linker-option`

Tuỳ chọn này lấy một đối số sẽ được chuyển đến trình liên kết cho các tệp nguồn được biên dịch trong cấu hình máy chủ lưu trữ. Tuỳ chọn này tương tự như tuỳ chọn --linkopt, nhưng chỉ áp dụng cho cấu hình máy chủ lưu trữ.

`--conlyopt=cc-option`

Tuỳ chọn này lấy một đối số sẽ được truyền đến trình biên dịch khi biên dịch tệp nguồn C.

Phương thức này tương tự như --copt, nhưng chỉ áp dụng cho quá trình biên dịch C, không áp dụng cho việc biên dịch hoặc liên kết C++. Vì vậy, bạn có thể chuyển các tuỳ chọn dành riêng cho C (chẳng hạn như -Wno-pointer-sign) bằng cách sử dụng --conlyopt.

`--cxxopt=cc-option`

Tuỳ chọn này lấy một đối số sẽ được truyền đến trình biên dịch khi biên dịch tệp nguồn C++.

Phương thức này tương tự như --copt, nhưng chỉ áp dụng cho quá trình biên dịch C++, không áp dụng cho quá trình biên dịch C hoặc liên kết. Vì vậy, bạn có thể truyền các tuỳ chọn dành riêng cho C++ (chẳng hạn như -fpermissive hoặc -fno-implicit-templates) bằng cách sử dụng --cxxopt.

Ví dụ:

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

`--linkopt=linker-option`

Tuỳ chọn này lấy một đối số sẽ được truyền đến trình biên dịch khi liên kết.

Phương thức này tương tự như --copt, nhưng chỉ áp dụng cho việc liên kết chứ không áp dụng cho quá trình biên dịch. Vì vậy, bạn có thể chuyển các tuỳ chọn trình biên dịch chỉ có ý nghĩa tại thời điểm liên kết (chẳng hạn như -lssp hoặc -Wl,--wrap,abort) bằng cách sử dụng --linkopt. Ví dụ:

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

Quy tắc tạo bản dựng cũng có thể chỉ định tuỳ chọn liên kết trong các thuộc tính tương ứng. Các chế độ cài đặt của tuỳ chọn này luôn được ưu tiên. Ngoài ra, hãy xem cc_library.linkopts.

`--strip (always|never|sometimes)`

Tuỳ chọn này xác định xem Bazel có xoá thông tin gỡ lỗi khỏi mọi tệp nhị phân và thư viện chia sẻ hay không bằng cách gọi trình liên kết với tuỳ chọn -Wl,--strip-debug. --strip=always có nghĩa là luôn xoá thông tin gỡ lỗi. --strip=never có nghĩa là tuyệt đối không xoá thông tin gỡ lỗi. Giá trị mặc định của --strip=sometimes có nghĩa là xoá nếu --compilation_mode là fastbuild.

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

sẽ biên dịch mục tiêu trong khi loại bỏ thông tin gỡ lỗi khỏi tất cả tệp nhị phân được tạo.

Tuỳ chọn --strip của Bazel tương ứng với tuỳ chọn --strip-debug của ld: tuỳ chọn này chỉ xoá thông tin gỡ lỗi. Nếu muốn loại bỏ tất cả biểu tượng, chứ không chỉ biểu tượng gỡ lỗi vì lý do nào đó, bạn cần sử dụng tuỳ chọn --strip-all của ld (bạn có thể thực hiện việc này bằng cách truyền --linkopt=-Wl,--strip-all đến Bazel). Ngoài ra, xin lưu ý rằng việc đặt cờ --strip của Bazel sẽ ghi đè --linkopt=-Wl,--strip-all. Vì vậy, bạn chỉ nên đặt một trong hai cờ này.

Nếu chỉ tạo một tệp nhị phân duy nhất và muốn xoá tất cả các biểu tượng, thì bạn cũng có thể truyền --stripopt=--strip-all và tạo phiên bản //foo:bar.stripped của mục tiêu một cách rõ ràng. Như đã mô tả trong phần về --stripopt, thao tác này áp dụng thao tác xoá sau khi tệp nhị phân cuối cùng được liên kết, thay vì đưa thao tác xoá vào mọi thao tác liên kết của bản dựng.

`--stripopt=strip-option`

Đây là một tuỳ chọn bổ sung để chuyển đến lệnh strip khi tạo tệp nhị phân *.stripped. Giá trị mặc định là -S -p. Bạn có thể sử dụng tuỳ chọn này nhiều lần.

`--fdo_instrument=profile-output-dir`

Tuỳ chọn --fdo_instrument cho phép tạo đầu ra hồ sơ FDO (tối ưu hoá theo hướng phản hồi) khi tệp nhị phân C/C++ tạo được thực thi. Đối với GCC, đối số đã cung cấp được dùng làm tiền tố thư mục cho cây thư mục tệp cho mỗi đối tượng của các tệp .gcda chứa thông tin hồ sơ cho mỗi tệp .o.

Sau khi tạo cây dữ liệu hồ sơ, cây hồ sơ sẽ được nén và cung cấp cho tuỳ chọn --fdo_optimize=profile-zip Bazel để bật tính năng biên dịch được tối ưu hoá cho FDO.

Đối với trình biên dịch LLVM, đối số cũng là thư mục mà trong đó(các) tệp dữ liệu hồ sơ LLVM thô được kết xuất. Ví dụ: --fdo_instrument=/path/to/rawprof/dir/.

Bạn không thể sử dụng các tuỳ chọn --fdo_instrument và --fdo_optimize cùng lúc.

`--fdo_optimize=profile-zip`

Tuỳ chọn --fdo_optimize cho phép sử dụng thông tin hồ sơ tệp trên mỗi đối tượng để tối ưu hoá FDO (tối ưu hoá theo hướng phản hồi) khi biên dịch. Đối với GCC, đối số được cung cấp là tệp zip chứa cây tệp được tạo trước đó của các tệp .gcda chứa thông tin hồ sơ cho mỗi tệp .o.

Ngoài ra, đối số được cung cấp có thể trỏ đến một hồ sơ tự động được phần mở rộng .afdo xác định.

Đối với trình biên dịch LLVM, đối số được cung cấp phải trỏ đến tệp đầu ra hồ sơ LLVM được lập chỉ mục do công cụ llvm-profdata chuẩn bị và phải có phần mở rộng .profdata.

Bạn không thể sử dụng các tuỳ chọn --fdo_instrument và --fdo_optimize cùng lúc.

`--[no]output_symbol_counts`

Nếu được bật, mỗi đường liên kết được gọi bằng vàng của một tệp nhị phân có thể thực thi C++ sẽ xuất ra một tệp số lượng biểu tượng (thông qua tuỳ chọn vàng --print-symbol-counts). Đối với mỗi đầu vào của trình liên kết, tệp này sẽ ghi lại số lượng ký hiệu đã được xác định và số lượng ký hiệu được sử dụng trong tệp nhị phân. Thông tin này có thể được dùng để theo dõi các phần phụ thuộc của đường liên kết không cần thiết. Tệp số lượng biểu tượng được ghi vào đường dẫn đầu ra của tệp nhị phân có tên là [targetname].sc.

Tuỳ chọn này bị tắt theo mặc định.

`--java_language_version=version`

Tuỳ chọn này chỉ định phiên bản của nguồn Java. Ví dụ:

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

biên dịch và chỉ cho phép các cấu trúc tương thích với thông số kỹ thuật Java 8. Giá trị mặc định là 11. --> Các giá trị có thể là: 8, 9, 10, 11, 14 và 15 và có thể được mở rộng bằng cách đăng ký chuỗi công cụ Java tuỳ chỉnh bằng default_java_toolchain.

`--tool_java_language_version=version`

Phiên bản ngôn ngữ Java dùng để xây dựng các công cụ được thực thi trong quá trình xây dựng. Giá trị mặc định là 11.

`--java_runtime_version=version`

Tuỳ chọn này chỉ định phiên bản JVM cần sử dụng để thực thi mã và chạy các kiểm thử. Ví dụ:

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

tải JDK 11 xuống qua kho lưu trữ từ xa rồi chạy ứng dụng Java bằng kho lưu trữ đó.

Giá trị mặc định là localjdk. Các giá trị có thể là: localjdk, localjdk_version, remotejdk_11 và remote_jdk17. Bạn có thể mở rộng các giá trị bằng cách đăng ký JVM tuỳ chỉnh thông qua quy tắc lưu trữ local_java_repository hoặc remote_java_repostory.

`--tool_java_runtime_version=version`

Phiên bản của JVM dùng để thực thi các công cụ cần thiết trong quá trình xây dựng. Giá trị mặc định là remotejdk_11.

`--jvmopt=jvm-option`

Tuỳ chọn này cho phép truyền các đối số tuỳ chọn đến máy ảo Java. Bạn có thể sử dụng đối số này với một đối số lớn hoặc nhiều lần với các đối số riêng lẻ. Ví dụ:

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

sẽ sử dụng máy chủ máy ảo để chạy tất cả các tệp nhị phân Java và đặt kích thước vùng nhớ khối xếp khởi động cho máy ảo thành 256 MB.

`--javacopt=javac-option`

Tuỳ chọn này cho phép chuyển các đối số tuỳ chọn đến javac. Bạn có thể sử dụng đối số này với một đối số lớn hoặc nhiều lần với các đối số riêng lẻ. Ví dụ:

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

sẽ tạo lại một java_binary với thông tin gỡ lỗi mặc định javac (thay vì giá trị mặc định bazel).

Tuỳ chọn này được chuyển đến javac sau các tuỳ chọn mặc định tích hợp sẵn Bazel cho javac và trước các tuỳ chọn cho mỗi quy tắc. Thông số kỹ thuật cuối cùng của bất kỳ tuỳ chọn nào để giành chiến thắng trong javac. Các tuỳ chọn mặc định cho javac là:

  -source 8 -target 8 -encoding UTF-8

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

Tuỳ chọn này kiểm soát việc javac có kiểm tra các phần phụ thuộc trực tiếp bị thiếu hay không. Mục tiêu Java phải khai báo rõ ràng tất cả các mục tiêu được sử dụng trực tiếp dưới dạng phần phụ thuộc. Cờ này hướng dẫn javac xác định các tệp jar thực sự được dùng để kiểm tra loại từng tệp java và cảnh báo/lỗi nếu chúng không phải là kết quả của phần phụ thuộc trực tiếp của mục tiêu hiện tại.

off có nghĩa là yêu cầu kiểm tra đã bị tắt.
warn có nghĩa là javac sẽ tạo các cảnh báo java tiêu chuẩn thuộc loại [strict] cho từng phần phụ thuộc trực tiếp bị thiếu.
default, strict và error đều có nghĩa là javac sẽ tạo lỗi thay vì cảnh báo, khiến mục tiêu hiện tại không tạo được nếu tìm thấy bất kỳ phần phụ thuộc trực tiếp nào bị thiếu. Đây cũng là hành vi mặc định khi cờ không được chỉ định.

Xây dựng ngữ nghĩa

Những tuỳ chọn này ảnh hưởng đến các lệnh tạo bản dựng và/hoặc nội dung tệp đầu ra.

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

Tuỳ chọn --compilation_mode (thường được rút ngắn thành -c, đặc biệt là -c opt) lấy đối số fastbuild, dbg hoặc opt và ảnh hưởng đến nhiều tuỳ chọn tạo mã C/C++, chẳng hạn như mức độ tối ưu hoá và tính hoàn chỉnh của bảng gỡ lỗi. Bazel sử dụng một thư mục đầu ra riêng cho từng chế độ biên dịch để bạn có thể chuyển đổi giữa các chế độ mà không cần xây dựng lại toàn bộ mỗi lần.

fastbuild có nghĩa là xây dựng nhanh nhất có thể: tạo thông tin gỡ lỗi tối thiểu (-gmlt -Wl,-S) và không tối ưu hoá. Đây là lựa chọn mặc định. Lưu ý: -DNDEBUG sẽ không được đặt.
dbg có nghĩa là bản dựng đã bật tính năng gỡ lỗi (-g), để bạn có thể sử dụng gdb (hoặc một trình gỡ lỗi khác).
opt có nghĩa là bản dựng được bật tính năng tối ưu hoá và có lệnh gọi assert() bị tắt (-O2 -DNDEBUG). Thông tin gỡ lỗi sẽ không được tạo ở chế độ opt trừ phi bạn cũng chuyển --copt -g.

`--cpu=cpu`

Tuỳ chọn này chỉ định cấu trúc CPU mục tiêu sẽ được dùng để biên dịch tệp nhị phân trong quá trình tạo bản dựng.

`--action_env=VAR=VALUE`

Chỉ định tập hợp các biến môi trường có sẵn trong quá trình thực thi tất cả các hành động. Bạn có thể chỉ định các biến theo tên, trong trường hợp đó, giá trị sẽ được lấy từ môi trường gọi hoặc bằng cặp name=value giúp đặt giá trị độc lập với môi trường gọi.

Bạn có thể chỉ định cờ --action_env này nhiều lần. Nếu một giá trị được gán cho cùng một biến trên nhiều cờ --action_env, thì lượt gán gần đây nhất sẽ chiến thắng.

`--experimental_action_listener=label`

Tuỳ chọn experimental_action_listener hướng dẫn Bazel sử dụng thông tin chi tiết từ quy tắc action_listener do label chỉ định để chèn extra_actions vào biểu đồ bản dựng.

`--[no]experimental_extra_action_top_level_only`

Nếu bạn đặt tuỳ chọn này thành true, thì các thao tác bổ sung do tuỳ chọn dòng lệnh --experimental_action_listener chỉ định sẽ chỉ được lên lịch cho các mục tiêu cấp cao nhất.

`--experimental_extra_action_filter=regex`

Tuỳ chọn experimental_extra_action_filter hướng dẫn Bazel lọc tập hợp mục tiêu để lên lịch extra_actions.

Cờ này chỉ có thể áp dụng kết hợp với cờ --experimental_action_listener.

Theo mặc định, tất cả extra_actions trong quá trình đóng bắc cầu của các mục tiêu tạo bản dựng được yêu cầu sẽ được lên lịch để thực thi. --experimental_extra_action_filter sẽ hạn chế việc lên lịch ở extra_actions, trong đó nhãn của chủ sở hữu khớp với biểu thức chính quy đã chỉ định.

Ví dụ sau đây sẽ giới hạn việc lên lịch biểu của extra_actions để chỉ áp dụng cho những hành động có nhãn của chủ sở hữu chứa "/bar/":

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

`--host_cpu=cpu`

Tuỳ chọn này chỉ định tên của cấu trúc CPU sẽ được dùng để tạo công cụ lưu trữ.

`--fat_apk_cpu=cpu[,cpu]*`

Các CPU để xây dựng thư viện C/C++ trong deps bắc cầu của các quy tắc android_binary. Các quy tắc C/C++ khác không bị ảnh hưởng. Ví dụ: nếu cc_library xuất hiện trong deps bắc cầu của quy tắc android_binary và quy tắc cc_binary, thì cc_library sẽ được tạo ít nhất 2 lần: một lần cho mỗi CPU được chỉ định bằng --fat_apk_cpu cho quy tắc android_binary và một lần cho CPU được chỉ định bằng --cpu cho quy tắc cc_binary.

Mặc định là armeabi-v7a.

Một tệp .so được tạo và đóng gói trong APK cho từng CPU được chỉ định bằng --fat_apk_cpu. Tên của tệp .so sẽ thêm "lib" vào trước tên của quy tắc android_binary. Ví dụ: nếu tên của android_binary là "foo", thì tệp sẽ là libfoo.so.

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

Khi có, mọi tệp C++ có nhãn hoặc đường dẫn thực thi khớp với một trong các biểu thức biểu thức chính quy đưa vào và không khớp với bất kỳ biểu thức loại trừ nào sẽ được tạo với các tuỳ chọn cho sẵn. Tính năng so khớp nhãn sẽ sử dụng dạng chuẩn của nhãn (tức là //package:label_name).

Đường dẫn thực thi là đường dẫn tương đối đến thư mục không gian làm việc, bao gồm tên cơ sở (bao gồm cả đuôi) của tệp C++. Nguồn cấp dữ liệu này cũng bao gồm mọi tiền tố phụ thuộc vào nền tảng.

Để khớp với các tệp đã tạo (chẳng hạn như kết quả đầu ra của quy tắc gen), Bazel chỉ có thể sử dụng đường dẫn thực thi. Trong trường hợp này, biểu thức chính quy không nên bắt đầu bằng "//" vì điều đó không khớp với bất kỳ đường dẫn thực thi nào. Bạn có thể sử dụng tên gói như sau: --per_file_copt=base/.*\.pb\.cc@-g0. Thao tác này sẽ khớp mọi tệp .pb.cc trong thư mục có tên base.

Bạn có thể sử dụng tuỳ chọn này nhiều lần.

Tuỳ chọn này được áp dụng bất kể bạn đang sử dụng chế độ biên dịch nào. Ví dụ: bạn có thể biên dịch bằng --compilation_mode=opt và biên dịch chọn lọc một số tệp khi đã bật tính năng tối ưu hoá mạnh hơn hoặc tắt tính năng tối ưu hoá.

Caveat: Nếu một số tệp được biên dịch chọn lọc với các biểu tượng gỡ lỗi, thì các biểu tượng có thể bị xoá trong quá trình liên kết. Bạn có thể ngăn chặn điều này bằng cách đặt --strip=never.

Cú pháp: [+-]regex[,[+-]regex]...@option[,option]... Trong đó regex là viết tắt của một biểu thức chính quy có thể thêm tiền tố + để xác định các mẫu bao gồm và - để xác định các mẫu loại trừ. option là viết tắt của một tuỳ chọn tuỳ ý được truyền đến trình biên dịch C++. Nếu một tuỳ chọn chứa ,, thì nó phải được trích dẫn như vậy \,. Các tuỳ chọn cũng có thể chứa @, vì chỉ @ đầu tiên được dùng để phân tách biểu thức chính quy khỏi tuỳ chọn.

Ví dụ: --per_file_copt=//foo:.*\.cc,-//foo:file\.cc@-O0,-fprofile-arcs thêm các tuỳ chọn -O0 và -fprofile-arcs vào dòng lệnh của trình biên dịch C++ cho tất cả các tệp .cc trong //foo/, ngoại trừ file.cc.

`--dynamic_mode=mode`

Xác định xem các tệp nhị phân C++ có được liên kết động hay không, tương tác với thuộc tính đường liên kết tĩnh trên các quy tắc xây dựng.

Chế độ:

auto: Chuyển sang chế độ phụ thuộc vào nền tảng; default đối với linux và off đối với cygwin.
default: Cho phép bazel chọn có liên kết linh hoạt hay không. Hãy xem đường liên kết linkstatic để biết thêm thông tin.
fully: Liên kết tất cả mục tiêu một cách linh động. Điều này sẽ đẩy nhanh thời gian liên kết và giảm kích thước của các tệp nhị phân thu được.
off: Liên kết mọi mục tiêu ở chế độ chủ yếu là tĩnh. Nếu bạn đặt -static trong linkopts, các mục tiêu sẽ thay đổi thành hoàn toàn tĩnh.

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

Bật tính năng Fission (Phân chia) để ghi thông tin gỡ lỗi C++ vào các tệp .dwo chuyên dụng thay vì các tệp .o, nếu không sẽ được dùng. Điều này giúp giảm đáng kể kích thước dữ liệu đầu vào cho các đường liên kết và có thể giảm thời gian liên kết.

Khi được đặt thành [dbg][,opt][,fastbuild] (ví dụ: --fission=dbg,fastbuild), Fission chỉ được bật cho nhóm chế độ biên dịch đã chỉ định. Điều này rất hữu ích cho các chế độ cài đặt bazelrc. Khi bạn đặt thành yes, tính năng Fission (Phân chia) sẽ được bật trên toàn cầu. Khi bạn đặt thành no, tính năng Phân chia sẽ bị tắt trên toàn cầu. Mặc định là no.

`--force_ignore_dash_static`

Nếu bạn đặt cờ này, thì mọi tuỳ chọn -static trong linkopts của quy tắc cc_* cho tệp BUILD sẽ bị bỏ qua. Đây chỉ nhằm mục đích giải quyết các bản dựng tăng cường C++.

`--[no]force_pic`

Nếu được bật, mọi nội dung biên dịch C++ đều tạo mã độc lập về vị trí ("-fPIC"), các đường liên kết ưu tiên thư viện tạo sẵn PIC hơn so với thư viện không phải PIC và đường liên kết sẽ tạo ra các tệp thực thi độc lập về vị trí ("-pie"). Mặc định bị tắt.

`--android_resource_shrinking`

Chọn xem có rút gọn tài nguyên cho các quy tắc android_binary hay không. Đặt giá trị mặc định cho thuộc tính thu gọn trên quy tắc android_binary; xem tài liệu về quy tắc đó để biết thêm thông tin chi tiết. Giá trị mặc định là tắt.

`--custom_malloc=malloc-library-target`

Khi được chỉ định, hãy luôn sử dụng phương thức triển khai Malloc nhất định, ghi đè tất cả các thuộc tính malloc="target", kể cả trong các mục tiêu sử dụng giá trị mặc định (bằng cách không chỉ định bất kỳ malloc nào).

`--crosstool_top=label`

Tuỳ chọn này chỉ định vị trí của bộ trình biên dịch công cụ chéo sẽ được sử dụng cho tất cả quá trình biên dịch C++ trong một bản dựng. Bazel sẽ tìm tệp CROSSTOOL tại vị trí đó và sử dụng tệp đó để tự động xác định các chế độ cài đặt cho --compiler.

`--host_crosstool_top=label`

Nếu không được chỉ định, Bazel sẽ sử dụng giá trị --crosstool_top để biên dịch mã trong cấu hình máy chủ lưu trữ, chẳng hạn như các công cụ chạy trong quá trình tạo bản dựng. Mục đích chính của cờ này là cho phép biên dịch chéo.

`--apple_crosstool_top=label`

Công cụ chéo dùng để biên dịch các quy tắc C/C++ trong deps bắc cầu của các quy tắc objc*, ios* và apple*. Đối với những mục tiêu đó, cờ này sẽ ghi đè --crosstool_top.

`--android_crosstool_top=label`

Công cụ chéo dùng để biên dịch các quy tắc C/C++ trong deps bắc cầu của các quy tắc android_binary. Điều này sẽ hữu ích nếu các mục tiêu khác trong bản dựng yêu cầu một công cụ chéo khác. Tuỳ chọn mặc định là sử dụng công cụ chéo được tạo bằng quy tắc android_ndk_repository trong tệp WORKSPACE. Xem thêm --fat_apk_cpu.

`--compiler=version`

Tuỳ chọn này chỉ định phiên bản trình biên dịch C/C++ (chẳng hạn như gcc-4.1.0) sẽ dùng để biên dịch tệp nhị phân trong quá trình tạo bản dựng. Nếu muốn xây dựng bằng một công cụ chéo tuỳ chỉnh, bạn nên sử dụng tệp CROSSTOOL thay vì chỉ định cờ này.

`--android_sdk=label`

Tuỳ chọn này chỉ định SDK/chuỗi công cụ nền tảng Android và thư viện thời gian chạy Android sẽ dùng để xây dựng mọi quy tắc liên quan đến Android.

SDK Android sẽ tự động được chọn nếu quy tắc android_sdk_repository được xác định trong tệp WORKSPACE.

`--java_toolchain=label`

Tuỳ chọn này chỉ định nhãn của java_toolchain dùng để biên dịch tệp nguồn Java.

`--host_java_toolchain=label`

Nếu không được chỉ định, bazel sẽ sử dụng giá trị --java_toolchain để biên dịch mã trong cấu hình máy chủ lưu trữ, chẳng hạn như đối với các công cụ chạy trong quá trình tạo bản dựng. Mục đích chính của cờ này là cho phép biên dịch chéo.

`--javabase=(label)`

Tuỳ chọn này sẽ đặt nhãn bản cài đặt Java cơ sở để sử dụng cho bazel run (chạy bazel), bazel test (kiểm thử bazel) và cho các tệp nhị phân Java do các quy tắc java_binary và java_test tạo. Biến"Make" JAVABASE và JAVA bắt nguồn từ tuỳ chọn này.

`--host_javabase=label`

Tuỳ chọn này sẽ đặt nhãn bản cài đặt Java cơ sở để dùng trong cấu hình máy chủ lưu trữ, ví dụ: các công cụ xây dựng máy chủ lưu trữ bao gồm JavaBuilder và Singlejar.

Thao tác này không chọn trình biên dịch Java được dùng để biên dịch tệp nguồn Java. Bạn có thể chọn trình biên dịch bằng cách cài đặt tuỳ chọn --java_toolchain.

Chiến lược thực thi

Các tuỳ chọn này ảnh hưởng đến cách Bazel thực thi bản dựng. Các tệp này sẽ không có ảnh hưởng đáng kể nào đến các tệp đầu ra do bản dựng tạo ra. Thông thường, tác động chính của chúng là tốc độ của bản dựng.

`--spawn_strategy=strategy`

Tuỳ chọn này kiểm soát vị trí và cách thực thi các lệnh.

standalone khiến các lệnh được thực thi dưới dạng quy trình phụ cục bộ. Giá trị này không còn được dùng nữa. Thay vào đó, hãy sử dụng local.
sandboxed khiến các lệnh được thực thi bên trong hộp cát trên máy cục bộ. Điều này yêu cầu tất cả các tệp đầu vào, phần phụ thuộc dữ liệu và công cụ phải được liệt kê dưới dạng phần phụ thuộc trực tiếp trong các thuộc tính srcs, data và tools. Theo mặc định, Bazel bật hộp cát cục bộ trên các hệ thống hỗ trợ thực thi hộp cát.
local khiến các lệnh được thực thi dưới dạng quy trình phụ cục bộ.
worker khiến các lệnh được thực thi bằng một trình thực thi liên tục (nếu có).
docker khiến các lệnh được thực thi bên trong hộp cát Docker trên máy cục bộ. Để thực hiện việc này, bạn phải cài đặt Docker.
remote khiến các lệnh được thực thi từ xa; tuỳ chọn này chỉ có sẵn nếu trình thực thi từ xa đã được định cấu hình riêng.

`--strategy mnemonic=strategy`

Tuỳ chọn này kiểm soát vị trí và cách thực thi các lệnh, ghi đè --spawn_strategy (và --genrule_strategy bằng GenRules ghi nhớ) trên cơ sở mỗi ghi nhớ. Hãy xem --spawn_strategy để biết các chiến lược được hỗ trợ và tác động của những chiến lược đó.

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

Tuỳ chọn này chỉ định chiến lược nào sẽ được dùng để thực thi các lệnh có nội dung mô tả khớp với một regex_filter nhất định. Vui lòng xem --per_file_copt để biết thông tin chi tiết về cách so khớp biểu thức chính quy. Hãy xem --spawn_strategy để biết các chiến lược được hỗ trợ và tác động của những chiến lược đó.

regex_filter gần đây nhất khớp với nội dung mô tả sẽ được sử dụng. Tuỳ chọn này sẽ ghi đè các cờ khác để chỉ định chiến lược.

Ví dụ: --strategy_regexp=//foo.*\\.cc,-//foo/bar=local có nghĩa là chạy các hành động bằng chiến lược local nếu nội dung mô tả của chiến lược đó khớp với //foo.*.cc nhưng không khớp với //foo/bar.
Ví dụ: --strategy_regexp='Compiling.*/bar=local' --strategy_regexp=Compiling=sandboxed chạy chiến lược "Compiling //foo/bar/baz" bằng chiến lược sandboxed, nhưng đảo ngược thứ tự sẽ chạy chiến lược đó với local.
Ví dụ: --strategy_regexp='Compiling.*/bar=local,sandboxed' chạy "Compiling //foo/bar/baz" với chiến lược local và quay lại sandboxed nếu không thành công.

`--genrule_strategy=strategy`

Đây là cách viết tắt của --strategy=Genrule=strategy, không dùng nữa.

`--jobs=n` (-j)

Tuỳ chọn này, lấy một đối số số nguyên, chỉ định giới hạn về số lượng công việc cần được thực thi đồng thời trong giai đoạn thực thi của bản dựng.

`--progress_report_interval=n`

Bazel định kỳ in báo cáo tiến trình cho các công việc chưa hoàn tất (chẳng hạn như các kiểm thử chạy trong thời gian dài). Tuỳ chọn này đặt tần suất báo cáo, tiến trình sẽ được in n giây một lần.

Giá trị mặc định là 0, điều đó có nghĩa là thuật toán tăng dần: báo cáo đầu tiên sẽ được in sau 10 giây, sau đó 30 giây và sau đó, tiến trình đó được báo cáo mỗi phút một lần.

Khi bazel đang sử dụng chức năng điều khiển con trỏ, như được chỉ định bởi --curses, tiến trình sẽ được báo cáo mỗi giây.

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

Các tuỳ chọn này chỉ định lượng tài nguyên cục bộ (RAM tính bằng MB và số lượng lõi logic CPU) mà Bazel có thể cân nhắc khi lên lịch cho các hoạt động tạo và kiểm thử để chạy cục bộ. Các cờ này lấy một số nguyên hoặc từ khoá (HOST_RAM hoặc HOST_CPUS) (không bắt buộc) theo sau là [-|*số thực có độ chính xác đơn] (ví dụ: --local_cpu_resources=2, --local_ram_resources=HOST_RAM*.5, --local_cpu_resources=HOST_CPUS-1). Các cờ là độc lập; có thể đặt một hoặc cả hai cờ. Theo mặc định, Bazel ước tính trực tiếp dung lượng RAM và số lõi CPU qua cấu hình của hệ thống cục bộ.

`--[no]build_runfile_links`

Tuỳ chọn này (được bật theo mặc định) chỉ định xem có nên tạo các đường liên kết tượng trưng của tệp runfile cho hoạt động kiểm thử và tệp nhị phân trong thư mục đầu ra hay không. Việc sử dụng --nobuild_runfile_links có thể hữu ích để xác thực xem tất cả các mục tiêu đều biên dịch mà không làm phát sinh chi phí xây dựng cây runfile.

Khi kiểm thử (hoặc ứng dụng) được thực thi, các phần phụ thuộc dữ liệu thời gian chạy của chúng sẽ được tập hợp ở cùng một nơi. Trong cây đầu ra của Bazel, cây "runfiles" này thường bị can thiệp vào hệ thống từ các tệp nhị phân hoặc kiểm thử tương ứng. Trong phiên chạy thử nghiệm, các tệp chạy có thể được truy cập bằng cách sử dụng các đường dẫn có dạng $TEST_SRCDIR/workspace/packagename/filename. Cây chạy tệp đảm bảo rằng các bài kiểm thử có quyền truy cập vào tất cả các tệp mà chúng có phần phụ thuộc đã khai báo và không có gì khác. Theo mặc định, cây runfile được triển khai bằng cách tạo một tập hợp các đường liên kết tượng trưng đến các tệp bắt buộc. Khi tập hợp các đường liên kết tăng lên, chi phí cho hoạt động này cũng tăng theo. Đối với một số bản dựng lớn, thời gian xây dựng có thể đóng góp đáng kể vào tổng thời gian xây dựng, đặc biệt là vì mỗi bài kiểm thử (hoặc ứng dụng) riêng lẻ yêu cầu cây chạy tệp riêng.

`--[no]build_runfile_manifests`

Tuỳ chọn này (được bật theo mặc định) chỉ định xem tệp kê khai runfile có được ghi vào cây đầu ra hay không. Việc tắt hàm này ngụ ý rằng --nobuild_runfile_links.

Bạn có thể tắt tính năng này khi thực thi kiểm thử từ xa, vì cây runfile sẽ được tạo từ xa từ các tệp kê khai trong bộ nhớ.

`--[no]discard_analysis_cache`

Khi tuỳ chọn này được bật, Bazel sẽ loại bỏ bộ nhớ đệm phân tích ngay trước khi quá trình thực thi bắt đầu, nhờ đó giải phóng thêm bộ nhớ (khoảng 10%) cho giai đoạn thực thi. Hạn chế là các bản dựng gia tăng tiếp theo sẽ chậm hơn. Hãy xem thêm về chế độ tiết kiệm bộ nhớ.

`--[no]keep_going` (-k)

Như trong GNU Make, giai đoạn thực thi của một bản dựng sẽ dừng khi gặp lỗi đầu tiên. Đôi khi, bạn nên cố gắng xây dựng nhiều nhất có thể, ngay cả khi có lỗi. Tuỳ chọn này cho phép hành vi đó và khi được chỉ định, bản dựng sẽ cố gắng tạo mọi mục tiêu có điều kiện tiên quyết đã được tạo thành công, nhưng sẽ bỏ qua lỗi.

Mặc dù tuỳ chọn này thường liên kết với giai đoạn thực thi của một bản dựng, nhưng nó cũng ảnh hưởng đến giai đoạn phân tích: nếu nhiều mục tiêu được chỉ định trong một lệnh bản dựng, nhưng chỉ một số mục tiêu trong số đó có thể được phân tích thành công, thì quá trình tạo sẽ dừng lại do lỗi trừ phi --keep_going được chỉ định. Trong trường hợp đó, bản dựng sẽ chuyển sang giai đoạn thực thi, nhưng chỉ đối với các mục tiêu đã được phân tích thành công.

`--[no]use_ijars`

Tuỳ chọn này thay đổi cách Bazel biên dịch các mục tiêu java_library. Thay vì sử dụng dữ liệu đầu ra của java_library để biên dịch các mục tiêu java_library phụ thuộc, Bazel sẽ tạo các tệp jar giao diện chỉ chứa chữ ký của các thành viên không riêng tư (phương thức và trường truy cập công khai, được bảo vệ và mặc định) đồng thời sử dụng jars giao diện để biên dịch các mục tiêu phụ thuộc. Điều này giúp bạn có thể tránh việc biên dịch lại khi chỉ thực hiện các thay đổi đối với phần nội dung phương thức hoặc các thành phần riêng tư của một lớp.

`--[no]interface_shared_objects`

Tuỳ chọn này sẽ bật đối tượng dùng chung giao diện, khiến tệp nhị phân và các thư viện dùng chung khác phụ thuộc vào giao diện của đối tượng dùng chung, thay vì triển khai. Khi chỉ thay đổi phương thức triển khai, Bazel có thể tránh tạo lại các mục tiêu phụ thuộc vào thư viện chia sẻ đã thay đổi một cách không cần thiết.

Chọn dữ liệu đầu ra

Những tuỳ chọn này xác định nội dung cần tạo hoặc thử nghiệm.

`--[no]build`

Tuỳ chọn này khiến giai đoạn thực thi của bản dựng xảy ra; tuỳ chọn này ở trạng thái bật theo mặc định. Khi bạn tắt nút này, giai đoạn thực thi sẽ bị bỏ qua và chỉ có hai giai đoạn đầu tiên là tải và phân tích xảy ra.

Tuỳ chọn này có thể hữu ích cho việc xác thực tệp BUILD và phát hiện lỗi trong dữ liệu đầu vào mà không thực sự tạo bất kỳ thứ gì.

`--[no]build_tests_only`

Nếu được chỉ định, Bazel sẽ chỉ tạo những nội dung cần thiết để chạy các quy tắc *_test và test_suite chưa được lọc do kích thước, thời gian chờ, thẻ hoặc ngôn ngữ. Nếu được chỉ định, Bazel sẽ bỏ qua các mục tiêu khác được chỉ định trên dòng lệnh. Theo mặc định, tuỳ chọn này bị tắt và Bazel sẽ tạo mọi thứ được yêu cầu, bao gồm cả các quy tắc *_test và test_suite được lọc ra khỏi quá trình kiểm thử. Điều này rất hữu ích vì việc chạy bazel test --build_tests_only foo/... có thể không phát hiện được mọi lỗi bản dựng trong cây foo.

`--[no]check_up_to_date`

Tuỳ chọn này khiến Bazel không tạo bản dựng mà chỉ đơn thuần kiểm tra xem tất cả các mục tiêu được chỉ định có được cập nhật hay không. Nếu có, quá trình tạo sẽ hoàn tất thành công như bình thường. Tuy nhiên, nếu có bất kỳ tệp nào đã cũ thay vì được tạo, hệ thống sẽ báo cáo lỗi và bản dựng sẽ không hoạt động. Tuỳ chọn này có thể hữu ích khi xác định xem một bản dựng được thực hiện gần đây hơn lần chỉnh sửa nguồn hay chưa (ví dụ: để kiểm tra trước khi gửi) mà không làm phát sinh chi phí bản dựng.

Xem thêm --check_tests_up_to_date.

`--[no]compile_one_dependency`

Biên dịch một phần phụ thuộc duy nhất của các tệp đối số. Điều này rất hữu ích cho các tệp nguồn kiểm tra cú pháp trong IDE, chẳng hạn như bằng cách tạo lại một mục tiêu duy nhất phụ thuộc vào tệp nguồn để phát hiện lỗi sớm nhất có thể trong chu trình chỉnh sửa/xây dựng/kiểm thử. Đối số này ảnh hưởng đến cách diễn giải tất cả các đối số không gắn cờ: mỗi đối số phải là một nhãn mục tiêu của tệp hoặc một tên tệp thuần tuý tương ứng với thư mục đang hoạt động và một quy tắc phụ thuộc vào từng tên tệp nguồn được tạo. Cho

Các nguồn C++ và Java, các quy tắc trong cùng một không gian ngôn ngữ được ưu tiên chọn. Đối với nhiều quy tắc có cùng lựa chọn ưu tiên, quy tắc xuất hiện đầu tiên trong tệp XÂY DỰNG sẽ được chọn. Mẫu mục tiêu được đặt tên rõ ràng mà không tham chiếu đến tệp nguồn sẽ dẫn đến lỗi.

`--save_temps`

Tuỳ chọn --save_temps khiến các kết quả tạm thời từ trình biên dịch được lưu. Các tệp này bao gồm các tệp .s (mã tập hợp), .i (C đã xử lý trước) và các tệp .ii (C++ được xử lý trước). Các kết quả này thường hữu ích khi gỡ lỗi. Tạm thời sẽ chỉ được tạo cho tập hợp mục tiêu đã chỉ định trên dòng lệnh.

Cờ --save_temps hiện chỉ hoạt động với các quy tắc cc_*.

Để đảm bảo Bazel in vị trí của các tệp đầu ra bổ sung, hãy kiểm tra để chắc chắn rằng chế độ cài đặt --show_result n của bạn đủ cao.

`--build_tag_filters=tag[,tag]*`

Nếu được chỉ định, Bazel sẽ chỉ tạo các mục tiêu có ít nhất một thẻ bắt buộc (nếu có chỉ định thẻ) và không có bất kỳ thẻ bị loại trừ nào. Bộ lọc thẻ bản dựng được chỉ định dưới dạng danh sách các từ khoá thẻ được phân tách bằng dấu phẩy, tuỳ ý đứng trước bằng dấu "-" dùng để biểu thị các thẻ bị loại trừ. Thẻ bắt buộc cũng có thể có dấu '+' ở phía trước.

Khi chạy kiểm thử, Bazel bỏ qua --build_tag_filters cho các mục tiêu kiểm thử. Các mục tiêu này được tạo và chạy ngay cả khi chúng không khớp với bộ lọc này. Để tránh tạo các mục tiêu này, hãy lọc các mục tiêu kiểm thử bằng cách sử dụng --test_tag_filters hoặc loại trừ các mục tiêu đó một cách rõ ràng.

`--test_size_filters=size[,size]*`

Nếu được chỉ định, Bazel sẽ chỉ kiểm thử (hoặc tạo bản dựng nếu --build_tests_only cũng được chỉ định) chỉ kiểm thử các mục tiêu có kích thước đã cho. Bộ lọc kích thước thử nghiệm được chỉ định dưới dạng danh sách các giá trị kích thước thử nghiệm được phân tách bằng dấu phẩy (nhỏ, trung bình, lớn hoặc rất lớn), có thể đứng sau dấu "-" dùng để biểu thị các kích thước thử nghiệm bị loại trừ. Ví dụ:

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

và

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

sẽ chỉ thử nghiệm các thử nghiệm vừa và nhỏ bên trong //foo.

Theo mặc định, tính năng lọc kích thước thử nghiệm sẽ không được áp dụng.

`--test_timeout_filters=timeout[,timeout]*`

Nếu được chỉ định, Bazel sẽ chỉ kiểm thử (hoặc xây dựng nếu --build_tests_only cũng được chỉ định) chỉ kiểm thử các mục tiêu với thời gian chờ nhất định. Bộ lọc thời gian chờ kiểm thử được chỉ định dưới dạng danh sách các giá trị thời gian chờ kiểm thử được phân tách bằng dấu phẩy (ngắn, trung bình, dài hoặc vĩnh viễn), có thể đứng sau ký hiệu '-' dùng để biểu thị thời gian chờ kiểm thử bị loại trừ. Hãy xem --test_size_filters để biết cú pháp mẫu.

Theo mặc định, tính năng lọc thời gian chờ kiểm thử sẽ không được áp dụng.

`--test_tag_filters=tag[,tag]*`

Nếu được chỉ định, Bazel sẽ chỉ kiểm thử (hoặc tạo nếu bạn cũng chỉ định --build_tests_only) chỉ kiểm thử các mục tiêu có ít nhất một thẻ bắt buộc (nếu có trong số đó được chỉ định) và không có bất kỳ thẻ bị loại trừ nào. Bộ lọc thẻ kiểm thử được chỉ định dưới dạng danh sách các từ khoá thẻ được phân tách bằng dấu phẩy, tuỳ ý đứng trước bằng dấu '-' dùng để biểu thị các thẻ bị loại trừ. Thẻ bắt buộc cũng có thể có dấu '+' ở phía trước.

Ví dụ:

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

sẽ thử nghiệm các mục tiêu được gắn thẻ bằng thẻ performance hoặc stress nhưng không được gắn thẻ bằng thẻ flaky.

Theo mặc định, tính năng lọc thẻ thử nghiệm không được áp dụng. Xin lưu ý rằng bạn cũng có thể lọc trên các thẻ size và local của kiểm thử theo cách này.

`--test_lang_filters=lang[,lang]*`

Chỉ định danh sách ngôn ngữ kiểm thử được phân tách bằng dấu phẩy cho các ngôn ngữ có quy tắc *_test chính thức (xem danh sách bách khoa toàn thư về bản dựng để biết danh sách đầy đủ các ngôn ngữ này). Mỗi ngôn ngữ có thể được bắt đầu bằng dấu "-" để chỉ định các ngôn ngữ bị loại trừ (không bắt buộc). Tên dùng cho mỗi ngôn ngữ phải giống với tiền tố ngôn ngữ trong quy tắc *_test, ví dụ: cc, java hoặc sh.

Nếu được chỉ định, Bazel sẽ chỉ kiểm thử (hoặc tạo nếu --build_tests_only cũng được chỉ định) chỉ kiểm thử các mục tiêu của(các) ngôn ngữ đã chỉ định.

Ví dụ:

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

sẽ chỉ kiểm thử các bài kiểm thử C/C++ và Java (được xác định bằng các quy tắc cc_test và java_test tương ứng) trong foo/..., trong khi

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

sẽ chạy mọi kiểm thử trong foo/..., ngoại trừ kiểm thử sh_test và java_test.

Theo mặc định, tính năng lọc ngôn ngữ kiểm thử không được áp dụng.

`--test_filter=filter-expression`

Chỉ định một bộ lọc mà trình chạy kiểm thử có thể sử dụng để chọn một tập hợp con các hoạt động kiểm thử cần chạy. Tất cả các mục tiêu chỉ định trong lệnh gọi đều được tạo, nhưng tuỳ thuộc vào biểu thức, hệ thống chỉ có thể thực thi một số mục tiêu trong số đó. Trong một số trường hợp, chỉ một số phương thức kiểm thử nhất định được chạy.

Việc diễn giải cụ thể của filter-expression phụ thuộc vào khung kiểm thử chịu trách nhiệm chạy kiểm thử. Đó có thể là chuỗi con, chuỗi con hoặc biểu thức chính quy. --test_filter rất thuận tiện khi bạn chuyển các đối số bộ lọc --test_arg khác nhau, nhưng không phải khung nào cũng hỗ trợ đối số này.

Độ chi tiết

Các tuỳ chọn này kiểm soát độ chi tiết của đầu ra của Bazel, đến thiết bị đầu cuối hoặc đến các tệp nhật ký bổ sung.

`--explain=logfile`

Tuỳ chọn này (yêu cầu đối số tên tệp), khiến trình kiểm tra phần phụ thuộc trong giai đoạn thực thi của bazel build giải thích cho mỗi bước bản dựng, lý do tại sao yêu cầu này được thực thi hoặc yêu cầu đó được cập nhật. Nội dung giải thích được ghi vào logfile.

Nếu bạn đang gặp phải các bản dựng lại không mong muốn, tuỳ chọn này có thể giúp bạn hiểu lý do. Hãy thêm vào .bazelrc để quá trình ghi nhật ký xảy ra cho tất cả các bản dựng tiếp theo, sau đó kiểm tra nhật ký khi bạn thấy một bước thực thi được thực thi không mong muốn. Tuỳ chọn này có thể gây ra một chút hao tổn về hiệu suất, vì vậy, bạn nên xoá tuỳ chọn này khi không cần dùng nữa.

`--verbose_explanations`

Tuỳ chọn này giúp tăng độ chi tiết của nội dung giải thích được tạo khi bật tuỳ chọn --Explain.

Cụ thể, nếu tính năng giải thích chi tiết được bật và tệp đầu ra được tạo lại vì lệnh dùng để tạo lệnh đó đã thay đổi, thì kết quả trong tệp giải thích sẽ bao gồm toàn bộ thông tin chi tiết về lệnh mới (ít nhất là đối với hầu hết các lệnh).

Việc sử dụng tuỳ chọn này có thể làm tăng đáng kể độ dài của tệp giải thích đã tạo và mức phạt về hiệu suất khi sử dụng --explain.

Nếu bạn không bật --explain, thì --verbose_explanations sẽ không có hiệu lực.

`--profile=file`

Tuỳ chọn này lấy đối số tên tệp, khiến Bazel ghi dữ liệu phân tích tài nguyên vào một tệp. Sau đó, dữ liệu có thể được phân tích hoặc phân tích cú pháp bằng lệnh bazel analyze-profile. Hồ sơ bản dựng có thể hữu ích trong việc biết được lệnh build của Bazel đang sử dụng thời gian ở đâu.

`--[no]show_loading_progress`

Tuỳ chọn này khiến Bazel xuất ra các thông báo về tiến trình tải gói. Nếu bạn tắt chế độ cài đặt này, các thông báo sẽ không xuất hiện.

`--[no]show_progress`

Tuỳ chọn này giúp hiển thị thông báo tiến trình; tuỳ chọn này được bật theo mặc định. Khi bạn tắt chế độ này, thông báo tiến trình sẽ bị chặn.

`--show_progress_rate_limit=n`

Tuỳ chọn này khiến bazel hiển thị tối đa một thông báo tiến trình mỗi n giây, trong đó n là một số thực. Giá trị mặc định cho tuỳ chọn này là 0,02, nghĩa là bazel sẽ giới hạn các thông báo tiến trình ở mức 1 thông báo cứ 0,02 giây.

`--show_result=n`

Tuỳ chọn này kiểm soát việc in thông tin kết quả ở cuối lệnh bazel build. Theo mặc định, nếu mục tiêu bản dựng duy nhất được chỉ định, Bazel sẽ in thông báo cho biết mục tiêu đã được cập nhật thành công hay chưa và nếu có, danh sách các tệp đầu ra mà mục tiêu đã tạo. Nếu bạn chỉ định nhiều mục tiêu, thì thông tin kết quả sẽ không xuất hiện.

Mặc dù thông tin kết quả có thể hữu ích cho các bản dựng của một hoặc một vài mục tiêu, nhưng đối với các bản dựng lớn (chẳng hạn như toàn bộ cây dự án cấp cao nhất), thông tin này có thể gây choáng ngợp và mất tập trung; tuỳ chọn này cho phép kiểm soát các bản dựng. --show_result lấy một đối số số nguyên, là số lượng mục tiêu tối đa cần in thông tin kết quả đầy đủ. Theo mặc định, giá trị là 1. Trên ngưỡng này, không có thông tin kết quả nào được hiển thị cho các mục tiêu riêng lẻ. Do đó, bằng 0, thông tin kết quả luôn bị chặn và giá trị rất lớn khiến kết quả luôn được in.

Người dùng có thể muốn chọn một giá trị ở giữa nếu họ thường xuyên thay đổi giữa việc tạo một nhóm nhỏ các mục tiêu (ví dụ: trong chu kỳ biên dịch-chỉnh sửa) và một nhóm lớn các mục tiêu (ví dụ: khi thiết lập không gian làm việc mới hoặc chạy kiểm thử hồi quy). Trong trường hợp trước, thông tin kết quả rất hữu ích còn trong trường hợp sau thì thông tin ít hữu ích hơn. Giống như mọi tuỳ chọn khác, bạn có thể chỉ định thông tin kết quả một cách ngầm ẩn thông qua tệp .bazelrc.

Các tệp này được in để giúp bạn dễ dàng sao chép và dán tên tệp vào shell, để chạy các tệp thực thi đã tạo. Bạn có thể dễ dàng phân tích cú pháp thông báo "đã cập nhật" hoặc "không thành công" cho từng mục tiêu bằng các tập lệnh thúc đẩy bản dựng.

`--sandbox_debug`

Tuỳ chọn này khiến Bazel in thêm thông tin gỡ lỗi khi sử dụng hộp cát để thực thi hành động. Tuỳ chọn này cũng lưu giữ các thư mục hộp cát để có thể kiểm tra các tệp hiển thị đối với các thao tác trong quá trình thực thi.

`--subcommands` (`-s`)

Tuỳ chọn này khiến giai đoạn thực thi của Bazel in toàn bộ dòng lệnh cho mỗi lệnh trước khi thực thi.

  >>>>> # //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)

Nếu có thể, các lệnh sẽ được in theo cú pháp tương thích với shell Bourne để có thể dễ dàng sao chép và dán vào dấu nhắc lệnh shell. (Các dấu ngoặc đơn xung quanh được cung cấp để bảo vệ shell của bạn khỏi các lệnh gọi cd và exec; hãy nhớ sao chép các dấu ngoặc đơn này!) Tuy nhiên, một số lệnh được triển khai nội bộ trong Bazel, chẳng hạn như tạo cây liên kết tượng trưng. Không có dòng lệnh nào để hiển thị đối với những nội dung này.

--subcommands=pretty_print có thể được truyền để in các đối số của lệnh dưới dạng danh sách thay vì một dòng đơn. Điều này có thể giúp các dòng lệnh dài dễ đọc hơn.

Xem thêm phần --verbose_failures ở bên dưới.

Để ghi nhật ký các lệnh con vào một tệp ở định dạng thân thiện với công cụ, hãy xem --execution_log_json_file và --execution_log_binary_file.

`--verbose_failures`

Tuỳ chọn này khiến giai đoạn thực thi của Bazel in toàn bộ dòng lệnh cho các lệnh không thực hiện được. Đây có thể là công cụ vô giá khi gỡ lỗi bản dựng bị lỗi.

Các lệnh không đạt được được in theo cú pháp tương thích với Bourne shell, phù hợp để sao chép và dán vào lời nhắc shell.

Trạng thái không gian làm việc

Sử dụng các tuỳ chọn sau để "đóng dấu" tệp nhị phân do Bazel tạo: để nhúng thông tin bổ sung vào tệp nhị phân, chẳng hạn như bản sửa đổi điều khiển nguồn hoặc thông tin khác liên quan đến không gian làm việc. Bạn có thể sử dụng cơ chế này với các quy tắc hỗ trợ thuộc tính stamp, chẳng hạn như genrule, cc_binary và các quy tắc khác.

`--workspace_status_command=program`

Cờ này cho phép bạn chỉ định một tệp nhị phân mà Bazel chạy trước mỗi bản dựng. Chương trình này có thể báo cáo thông tin về trạng thái của không gian làm việc, chẳng hạn như bản sửa đổi chế độ kiểm soát nguồn hiện tại.

Giá trị của cờ phải là một đường dẫn đến một chương trình gốc. Trên Linux/macOS, tệp này có thể thực thi được. Trên Windows, đây phải là một tệp nhị phân gốc, thường là tệp ".exe", ".bat" hoặc ".cmd".

Chương trình nên in số 0 hoặc nhiều cặp giá trị/khoá thành đầu ra tiêu chuẩn, một mục nhập trên mỗi dòng, sau đó thoát bằng 0 (nếu không, bản dựng sẽ không hoạt động được). Tên khoá có thể là bất kỳ tên nào nhưng chỉ có thể sử dụng chữ hoa và dấu gạch dưới. Dấu cách đầu tiên sau tên khoá giúp phân tách mã đó với giá trị. Giá trị là phần còn lại của dòng (bao gồm cả khoảng trắng bổ sung). Cả khoá và giá trị đều không được nằm trên nhiều dòng. Các khoá không được trùng lặp.

Bazel phân chia các khoá này thành hai nhóm: "ổn định" và "dễ thay đổi". (Tên "ổn định" và "dễ biến động" hơi khác thường, vì vậy đừng suy nghĩ nhiều về chúng.)

Sau đó, Bazel ghi các cặp khoá-giá trị vào hai tệp:

bazel-out/stable-status.txt chứa tất cả khoá và giá trị trong đó tên khoá bắt đầu bằng STABLE_
bazel-out/volatile-status.txt chứa phần còn lại của khoá và giá trị của chúng

Hợp đồng là:

Giá trị của khoá "ổn định" nên hiếm khi thay đổi, nếu có thể. Nếu nội dung của bazel-out/stable-status.txt thay đổi, Bazel sẽ vô hiệu hoá các thao tác phụ thuộc vào nội dung đó. Nói cách khác, nếu giá trị của một khoá ổn định thay đổi, Bazel sẽ chạy lại các hành động có đóng dấu. Do đó, trạng thái ổn định không nên chứa những thông tin như dấu thời gian vì chúng luôn thay đổi và sẽ khiến Bazel chạy lại các hành động có đóng dấu trong mỗi bản dựng.

Bazel luôn cho ra các khoá ổn định sau đây:
- BUILD_EMBED_LABEL: giá trị của --embed_label
- BUILD_HOST: tên của máy chủ lưu trữ mà Bazel đang chạy
- BUILD_USER: tên của người dùng mà Bazel đang sử dụng
Giá trị của khoá "volatile" (thay đổi được) có thể thay đổi thường xuyên. Bazel muốn các thuộc tính này luôn thay đổi, chẳng hạn như dấu thời gian, và cập nhật hợp lệ tệp bazel-out/volatile-status.txt. Tuy nhiên, để tránh tình trạng luôn chạy lại các hành động có dấu, Bazel sẽ giả định rằng tệp volatile không bao giờ thay đổi. Nói cách khác, nếu tệp trạng thái biến động là tệp duy nhất có nội dung thay đổi, thì Bazel sẽ không vô hiệu hoá các hành động phụ thuộc vào tệp đó. Nếu các đầu vào khác của hành động thay đổi, thì Bazel sẽ chạy lại hành động đó và hành động sẽ thấy trạng thái biến động được cập nhật, nhưng chỉ riêng trạng thái biến động sẽ không làm vô hiệu hoá hành động đó.

Bazel luôn xuất các khoá biến động sau đây:
- BUILD_TIMESTAMP: thời gian tạo bản dựng tính bằng giây kể từ Epoch (giá trị System.currentTimeMillis() chia cho một nghìn)

Trên Linux/macOS, bạn có thể truyền --workspace_status_command=/bin/true để vô hiệu hoá tính năng truy xuất trạng thái không gian làm việc, vì true không làm gì thành công (thoát bằng 0) và không in ra kết quả nào. Trên Windows, bạn có thể truyền đường dẫn của true.exe của MSYS để có hiệu ứng tương tự.

Nếu lệnh trạng thái không gian làm việc không thành công (thoát khác 0) vì bất kỳ lý do nào, thì quá trình tạo sẽ không thành công.

Chương trình mẫu trên Linux sử dụng Git:

#!/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"

Truyền đường dẫn của chương trình này bằng --workspace_status_command, tệp trạng thái ổn định sẽ bao gồm các dòng STABLE và tệp trạng thái biến động sẽ bao gồm các dòng còn lại.

`--[no]stamp`

Tuỳ chọn này cùng với thuộc tính quy tắc stamp kiểm soát việc có nhúng thông tin bản dựng vào tệp nhị phân hay không.

Bạn có thể bật hoặc tắt tính năng đóng dấu một cách rõ ràng trên cơ sở mỗi quy tắc bằng thuộc tính stamp. Vui lòng tham khảo Bách khoa toàn thư về xây dựng để biết chi tiết. Khi một quy tắc đặt stamp = -1 (mặc định cho các quy tắc *_binary), tuỳ chọn này sẽ xác định xem tính năng đóng dấu có được bật hay không.

Bazel không bao giờ đóng dấu các tệp nhị phân được tạo cho cấu hình máy chủ lưu trữ, bất kể tuỳ chọn này hay thuộc tính stamp. Đối với các quy tắc đặt stamp = 0 (mặc định cho các quy tắc *_test), tính năng đóng dấu bị tắt bất kể --[no]stamp là gì. Việc chỉ định --stamp không buộc phải tạo lại mục tiêu nếu các phần phụ thuộc không thay đổi.

Thường thì bạn nên thiết lập --nostamp cho hiệu suất bản dựng, vì điều này giúp giảm sự biến động đầu vào và tối đa hoá việc lưu bản dựng vào bộ nhớ đệm.

Nền tảng

Hãy sử dụng các tuỳ chọn này để kiểm soát các nền tảng lưu trữ và nền tảng đích giúp định cấu hình cách hoạt động của các bản dựng, cũng như để kiểm soát những nền tảng thực thi và chuỗi công cụ có sẵn cho các quy tắc Bazel.

Vui lòng xem thông tin cơ bản về các Nền tảng và Chuỗi công cụ.

`--platforms=labels`

Nhãn của các quy tắc nền tảng mô tả nền tảng đích cho lệnh hiện tại.

`--host_platform=label`

Nhãn của quy tắc nền tảng mô tả hệ thống lưu trữ.

`--extra_execution_platforms=labels`

Các nền tảng có sẵn dưới dạng nền tảng thực thi để chạy hành động. Các nền tảng có thể được chỉ định theo mục tiêu chính xác hoặc làm mẫu mục tiêu. Các nền tảng này sẽ được xem xét trước các nền tảng được khai báo trong tệp WORKSPACE bằng register_execution_platforms().

`--extra_toolchains=labels`

Các quy tắc chuỗi công cụ cần được xem xét trong quá trình phân giải chuỗi công cụ. Chuỗi công cụ có thể được chỉ định theo mục tiêu chính xác hoặc dưới dạng mẫu mục tiêu. Các chuỗi công cụ này sẽ được xem xét trước những chuỗi công cụ được khai báo trong tệp WORKSPACE bằng register_toolchains().

`--toolchain_resolution_debug=regex`

In thông tin gỡ lỗi trong khi tìm chuỗi công cụ nếu loại chuỗi công cụ khớp với biểu thức chính quy. Bạn có thể phân tách nhiều biểu thức chính quy bằng dấu phẩy. Bạn có thể bỏ qua biểu thức chính quy bằng cách sử dụng - ở đầu. Việc này có thể giúp các nhà phát triển các quy tắc Bazel hoặc Starlark gặp lỗi gỡ lỗi do thiếu chuỗi công cụ.

Khác

`--flag_alias=alias_name=target_path`

Một cờ tiện lợi dùng để liên kết các chế độ cài đặt bản dựng Starlark dài hơn với một tên ngắn hơn. Để biết thêm thông tin chi tiết, hãy xem phần Cấu hình Starlark.

`--symlink_prefix=string`

Thay đổi tiền tố của các đường liên kết tượng trưng tiện lợi đã tạo. Giá trị mặc định cho tiền tố đường liên kết tượng trưng là bazel-. Giá trị này sẽ tạo các đường liên kết tượng trưng bazel-bin, bazel-testlogs và bazel-genfiles.

Nếu hệ thống không thể tạo đường liên kết tượng trưng vì bất kỳ lý do gì, hệ thống sẽ đưa ra cảnh báo nhưng bản dựng vẫn được coi là thành công. Cụ thể, việc này cho phép bạn tạo trong một thư mục chỉ có thể đọc hoặc thư mục mà bạn không có quyền ghi. Mọi đường dẫn được in trong thông báo cung cấp thông tin tại thời điểm kết thúc quá trình tạo bản dựng sẽ chỉ sử dụng dạng ngắn tương đối của đường liên kết tượng trưng nếu các đường liên kết tượng trưng trỏ đến vị trí dự kiến; nói cách khác, bạn có thể dựa vào tính chính xác của các đường dẫn đó, ngay cả khi không thể dựa vào các đường liên kết tượng trưng đang được tạo.

Một số giá trị phổ biến của tuỳ chọn này:

Chặn việc tạo đường liên kết tượng trưng: --symlink_prefix=/ sẽ khiến Bazel không tạo hoặc cập nhật bất kỳ đường liên kết tượng trưng nào, bao gồm cả các đường liên kết tượng trưng bazel-out và bazel-<workspace>. Hãy sử dụng tuỳ chọn này để ngăn hoàn toàn việc tạo đường liên kết tượng trưng.
Giảm sự lộn xộn: --symlink_prefix=.bazel/ sẽ khiến Bazel tạo các đường liên kết tượng trưng có tên bin (v.v.) bên trong một thư mục ẩn .bazel.

`--platform_suffix=string`

Thêm hậu tố vào tên ngắn của cấu hình, dùng để xác định thư mục đầu ra. Khi bạn đặt tuỳ chọn này thành các giá trị khác nhau, các tệp sẽ được đưa vào các thư mục khác nhau (ví dụ: để cải thiện tỷ lệ truy cập vào bộ nhớ đệm đối với những bản dựng mà nếu không, hãy sao chép các tệp đầu ra khác hoặc giữ lại các tệp đầu ra để so sánh).

`--default_visibility=(private|public)`

Cờ tạm thời để kiểm thử các thay đổi về chế độ hiển thị mặc định của bazel. Không nhằm mục đích sử dụng chung, nhưng được ghi lại để đảm bảo tính đầy đủ.

`--[no]use_action_cache`

Tuỳ chọn này được bật theo mặc định. Nếu bạn tắt tuỳ chọn này, Bazel sẽ không dùng bộ nhớ đệm hành động cục bộ. Việc tắt bộ nhớ đệm thao tác cục bộ sẽ giúp tiết kiệm bộ nhớ và dung lượng ổ đĩa cho các bản dựng sạch, nhưng sẽ làm cho các bản dựng tăng dần chậm hơn.

`--starlark_cpu_profile=_file_`

Cờ này (có giá trị là tên của một tệp) khiến Bazel thu thập số liệu thống kê về mức sử dụng CPU theo tất cả các luồng Starlark và ghi hồ sơ ở định dạng pprof vào tệp được đặt tên.

Sử dụng tuỳ chọn này để giúp xác định các hàm Starlark khiến việc tải và phân tích bị chậm do tính toán quá mức. Ví dụ:

$ 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

Đối với nhiều khung hiển thị của cùng một dữ liệu, hãy thử các lệnh pprof svg, web và list.

Sử dụng Bazel để phát hành

Bazel được cả kỹ sư phần mềm và kỹ sư phát hành sử dụng khi chuẩn bị tệp nhị phân để triển khai cho đến sản xuất. Phần này cung cấp danh sách các mẹo giúp các kỹ sư phát hành sử dụng Bazel.

Lựa chọn quan trọng

Khi sử dụng Bazel cho các bản phát hành, các vấn đề tương tự cũng phát sinh như đối với các tập lệnh khác thực hiện bản dựng. Để biết thêm thông tin, hãy xem phần Gọi cho Bazel qua tập lệnh. Cụ thể, bạn nên sử dụng các tuỳ chọn sau:

Những tuỳ chọn sau cũng quan trọng:

--package_path
--symlink_prefix: để quản lý các bản dựng cho nhiều cấu hình, bạn có thể phân biệt từng bản dựng bằng một giá trị nhận dạng riêng biệt, chẳng hạn như "64 bit" và "32 bit". Tuỳ chọn này sẽ phân biệt các liên kết tượng trưng bazel-bin (v.v.).

Chạy kiểm thử

Để tạo và chạy kiểm thử bằng bazel, hãy nhập bazel test theo sau là tên của mục tiêu kiểm thử.

Theo mặc định, lệnh này thực hiện đồng thời hoạt động tạo và kiểm thử, tạo tất cả các mục tiêu được chỉ định (bao gồm cả mọi mục tiêu không phải mục tiêu kiểm thử được chỉ định trên dòng lệnh) và kiểm thử các mục tiêu *_test và test_suite ngay khi các điều kiện tiên quyết được tạo, nghĩa là quá trình thực thi kiểm thử được xen kẽ với bản dựng. Việc này thường giúp tốc độ tăng đáng kể.

Tuỳ chọn cho `bazel test`

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

Nếu bạn đặt tuỳ chọn này thành "auto" (tự động) (mặc định), thì Bazel sẽ chỉ chạy lại quy trình kiểm thử nếu có bất kỳ điều kiện nào sau đây:

Bazel phát hiện các thay đổi trong quy trình kiểm thử hoặc các phần phụ thuộc của quy trình kiểm thử
thử nghiệm được đánh dấu là external
đã yêu cầu nhiều lần chạy kiểm thử bằng --runs_per_test
kiểm thử không thành công.

Nếu khách hàng "không", mọi lượt kiểm thử sẽ được thực thi vô điều kiện.

Nếu "có", hoạt động lưu vào bộ nhớ đệm sẽ giống như tự động, ngoại trừ việc có thể lưu các lỗi kiểm thử vào bộ nhớ đệm và kiểm thử sẽ chạy bằng --runs_per_test.

Người dùng đã bật tuỳ chọn này theo mặc định trong tệp .bazelrc có thể thấy các chữ viết tắt -t (bật) hoặc -t- (tắt) thuận tiện cho việc ghi đè giá trị mặc định trong một lần chạy cụ thể.

`--check_tests_up_to_date`

Tuỳ chọn này yêu cầu Bazel không chạy kiểm thử mà chỉ kiểm tra và báo cáo kết quả kiểm thử đã lưu vào bộ nhớ đệm. Nếu có bất kỳ quy trình kiểm thử nào chưa được tạo và chạy trước đó hoặc kết quả kiểm thử có kết quả lỗi thời (ví dụ: vì mã nguồn hoặc tuỳ chọn bản dựng đã thay đổi), thì Bazel sẽ báo cáo thông báo lỗi ("kết quả kiểm thử không cập nhật"), ghi lại trạng thái kiểm thử là "NO STATUS" (KHÔNG TRẠNG THÁI màu đỏ, nếu đầu ra màu được bật) và sẽ trả về mã thoát khác 0.

Tuỳ chọn này cũng ngụ ý hành vi của [--check_up_to_date](#check-up-to-date).

Tuỳ chọn này có thể hữu ích cho việc kiểm tra trước khi gửi.

`--test_verbose_timeout_warnings`

Tuỳ chọn này yêu cầu Bazel cảnh báo rõ ràng người dùng nếu thời gian chờ của bài kiểm thử dài hơn đáng kể so với thời gian thực thi thực tế của bài kiểm thử. Mặc dù thời gian chờ của bài kiểm thử phải được thiết lập sao cho thời gian chờ không bị ổn định, nhưng bài kiểm thử có thời gian chờ quá rộng có thể ẩn các vấn đề thực xuất hiện ngoài dự kiến.

Ví dụ: một kiểm thử thường thực hiện trong một hoặc hai phút không nên có thời gian chờ là ETERNAL hoặc LONG vì các kiểm thử này quá rộng.

Tuỳ chọn này rất hữu ích trong việc giúp người dùng quyết định một giá trị thời gian chờ phù hợp hoặc kiểm tra tính hợp lý hiện có.

`--[no]test_keep_going`

Theo mặc định, tất cả các kiểm thử đều được chạy đến khi hoàn tất. Tuy nhiên, nếu cờ này bị tắt, bản dựng sẽ bị huỷ trong mọi lượt kiểm thử không đạt. Các bước tạo bản dựng và lệnh gọi kiểm thử tiếp theo sẽ không chạy được và các lệnh gọi đang diễn ra sẽ bị huỷ. Đừng chỉ định cả --notest_keep_going và --keep_going.

`--flaky_test_attempts=attempts`

Tuỳ chọn này chỉ định số lần kiểm thử tối đa cần thử nếu không thành công vì bất kỳ lý do gì. Một kiểm thử ban đầu không thành công nhưng cuối cùng thành công được báo cáo là FLAKY trên phần tóm tắt kiểm thử. Tuy nhiên, nó được xem là đã đạt khi xác định mã thoát Bazel hoặc tổng số lượt kiểm thử đã vượt qua. Những lượt kiểm thử không vượt qua tất cả các lần thử cho phép sẽ được coi là không thành công.

Theo mặc định (khi tuỳ chọn này không được chỉ định hoặc khi được đặt thành mặc định), hệ thống chỉ cho phép một lần thử duy nhất đối với quy tắc kiểm thử thông thường và 3 lần đối với các quy tắc kiểm thử có đặt thuộc tính flaky. Bạn có thể chỉ định một giá trị số nguyên để ghi đè giới hạn tối đa về số lần thử kiểm thử. Bazel cho phép tối đa 10 lần thử nghiệm để ngăn chặn hành vi lạm dụng hệ thống.

`--runs_per_test=[regex@]number`

Tuỳ chọn này chỉ định số lần thực thi mỗi bài kiểm thử. Tất cả các phiên chạy kiểm thử được coi là các bài kiểm thử riêng biệt (chức năng dự phòng sẽ áp dụng độc lập cho từng phiên bản kiểm thử đó).

Trạng thái của mục tiêu có lần chạy không thành công phụ thuộc vào giá trị của cờ --runs_per_test_detects_flakes:

Nếu không có, thì bất kỳ lần chạy nào không thành công đều khiến toàn bộ quy trình kiểm thử không đạt.
Nếu có và hai lần chạy từ cùng một phân đoạn sẽ trả về PASS và FAIL, thì quá trình kiểm thử sẽ nhận được trạng thái không ổn định (trừ khi các lần chạy không thành công khác khiến kiểm thử không thành công).

Nếu bạn chỉ định một số duy nhất, thì tất cả thử nghiệm sẽ chạy nhiều lần như vậy. Ngoài ra, bạn có thể chỉ định một biểu thức chính quy bằng cú pháp regex@number. Điều này ràng buộc hiệu ứng của --runs_per_test với các mục tiêu khớp với biểu thức chính quy (--runs_per_test=^//pizza:.*@4 chạy tất cả các phép kiểm thử dưới //pizza/ 4 lần). Bạn có thể chỉ định biểu mẫu --runs_per_test này nhiều lần.

`--[no]runs_per_test_detects_flakes`

Nếu tuỳ chọn này được chỉ định (theo mặc định không phải), Bazel sẽ phát hiện phân đoạn kiểm thử không ổn định thông qua --runs_per_test. Nếu một hoặc nhiều lần chạy cho một phân đoạn không thành công và một hoặc nhiều lần chạy cho cùng một lần truyền phân đoạn, thì mục tiêu sẽ được coi là không ổn định với cờ. Nếu không chỉ định, mục tiêu sẽ báo cáo trạng thái không đạt.

`--test_summary=output_style`

Chỉ định cách hiển thị bản tóm tắt kết quả thử nghiệm.

short in kết quả của mỗi lượt kiểm thử cùng với tên của tệp chứa kết quả kiểm thử nếu kiểm thử không thành công. Đây là giá trị mặc định.
terse như short, nhưng thậm chí ngắn hơn: chỉ in thông tin về các lượt kiểm thử không đạt.
detailed in từng trường hợp kiểm thử riêng lẻ không thành công, chứ không chỉ mỗi lần kiểm thử. Tên của các tệp đầu ra kiểm thử bị bỏ qua.
none không in bản tóm tắt thử nghiệm.

`--test_output=output_style`

Chỉ định cách hiển thị kết quả kiểm thử:

summary cho thấy thông tin tóm tắt về việc từng lượt kiểm thử đạt hay không đạt. Đồng thời cho thấy tên tệp nhật ký đầu ra của các lượt kiểm thử không thành công. Bản tóm tắt sẽ được in ở cuối bản dựng (trong quá trình tạo bản dựng, người dùng sẽ chỉ thấy các thông báo tiến trình đơn giản khi quá trình kiểm thử bắt đầu, đạt hoặc không thành công). Đây là hành vi mặc định.
errors chỉ gửi đầu ra stdout/stderr kết hợp từ các hoạt động kiểm thử không thành công vào stdout ngay sau khi hoàn tất quá trình kiểm thử, đảm bảo rằng đầu ra kiểm thử từ các hoạt động kiểm thử đồng thời không bị xen kẽ với nhau. In bản tóm tắt tại bản dựng theo kết quả tóm tắt ở trên.
all tương tự như errors nhưng in kết quả cho tất cả các kiểm thử, bao gồm cả những kiểm thử đã vượt qua.
streamed truyền trực tuyến đầu ra stdout/stderr từ mỗi lượt kiểm thử theo thời gian thực.

`--java_debug`

Tuỳ chọn này khiến máy ảo Java của chương trình kiểm thử java phải đợi kết nối từ trình gỡ lỗi tuân thủ JDK trước khi bắt đầu kiểm thử. Tuỳ chọn này ngụ ý --test_output=streamed.

`--[no]verbose_test_summary`

Theo mặc định, tuỳ chọn này được bật, khiến thời gian kiểm thử và các thông tin bổ sung khác (chẳng hạn như lượt thử kiểm thử) được in ra phần tóm tắt kiểm thử. Nếu bạn chỉ định --noverbose_test_summary, thông tin tóm tắt quy trình kiểm thử sẽ chỉ bao gồm tên kiểm thử, trạng thái kiểm thử và chỉ báo kiểm thử được lưu vào bộ nhớ đệm, đồng thời sẽ được định dạng để nằm trong phạm vi 80 ký tự khi có thể.

`--test_tmpdir=path`

Chỉ định thư mục tạm thời cho các quy trình kiểm thử được thực thi cục bộ. Mỗi lượt kiểm thử sẽ được thực thi trong một thư mục con riêng biệt bên trong thư mục này. Thư mục này sẽ bị xoá ở đầu mỗi lệnh bazel test. Theo mặc định, bazel sẽ đặt thư mục này trong thư mục cơ sở đầu ra Bazel.

`--test_timeout=seconds` HOẶC `--test_timeout=seconds,seconds,seconds,seconds`

Ghi đè giá trị thời gian chờ cho tất cả kiểm thử bằng cách sử dụng số giây được chỉ định làm giá trị thời gian chờ mới. Nếu chỉ cung cấp một giá trị, thì giá trị này sẽ được dùng cho tất cả các danh mục thời gian chờ kiểm thử.

Ngoài ra, bạn có thể cung cấp 4 giá trị được phân tách bằng dấu phẩy, chỉ định thời gian chờ riêng lẻ cho các kiểm thử ngắn, trung bình, dài và vĩnh viễn (theo thứ tự đó). Dù ở dạng nào, giá trị 0 hoặc giá trị âm đối với bất kỳ kích thước kiểm thử nào cũng sẽ được thay thế bằng thời gian chờ mặc định cho các danh mục thời gian chờ nhất định như đã xác định trên trang Viết kiểm thử. Theo mặc định, Bazel sẽ sử dụng các thời gian chờ này cho tất cả hoạt động kiểm thử bằng cách suy ra giới hạn thời gian chờ từ kích thước kiểm thử, cho dù kích thước được đặt ngầm hay rõ ràng.

Những lần kiểm thử nêu rõ danh mục thời gian chờ khác với kích thước của chúng sẽ nhận được cùng một giá trị như thể thời gian chờ đó được thẻ kích thước đặt ngầm định. Vì vậy, bài kiểm thử có kích thước "nhỏ" khai báo thời gian chờ "dài" sẽ có cùng thời gian chờ có hiệu lực như bài kiểm thử "lớn" không có thời gian chờ rõ ràng.

`--test_arg=arg`

Truyền các tuỳ chọn dòng lệnh/cờ/đối số vào mỗi quy trình kiểm thử. Bạn có thể sử dụng tuỳ chọn này nhiều lần để chuyển nhiều đối số. Ví dụ: --test_arg=--logtostderr --test_arg=--v=3.

`--test_env=variable=_value_` HOẶC `--test_env=variable`

Chỉ định các biến bổ sung cần được đưa vào môi trường kiểm thử cho mỗi lần kiểm thử. Nếu bạn không chỉ định value, thì hệ thống sẽ kế thừa từ môi trường shell dùng để bắt đầu lệnh bazel test.

Bạn có thể truy cập môi trường qua một hoạt động kiểm thử bằng cách sử dụng System.getenv("var") (Java), getenv("var") (C hoặc C++),

`--run_under=command-prefix`

Thao tác này chỉ định một tiền tố mà trình chạy kiểm thử sẽ chèn vào trước lệnh kiểm thử trước khi chạy. command-prefix được chia thành các từ bằng quy tắc mã hoá shell Bourne, sau đó danh sách các từ được thêm vào trước lệnh sẽ được thực thi.

Nếu từ đầu tiên là một nhãn đủ điều kiện (bắt đầu bằng //), thì nhãn đó sẽ được tạo. Sau đó, nhãn được thay thế bằng vị trí thực thi tương ứng mà được thêm vào trước lệnh sẽ được thực thi cùng với các từ khác.

Một số lưu ý áp dụng:

PATH dùng để chạy kiểm thử có thể khác với PATH trong môi trường của bạn, vì vậy, bạn có thể cần phải sử dụng đường dẫn tuyệt đối cho lệnh --run_under (từ đầu tiên trong command-prefix).
stdin không được kết nối, vì vậy, bạn không thể sử dụng --run_under cho các lệnh tương tác.

Ví dụ:

        --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'

Lựa chọn thử nghiệm

Như đã trình bày trong phần Tuỳ chọn lựa chọn đầu ra, bạn có thể lọc hoạt động kiểm thử theo kích thước, thời gian chờ, thẻ hoặc ngôn ngữ. Bộ lọc tên chung tiện lợi có thể chuyển tiếp các đối số bộ lọc cụ thể đến trình chạy kiểm thử.

Lựa chọn khác cho `bazel test`

Cú pháp và các tuỳ chọn còn lại hoàn toàn giống như bazel build.

Đang chạy tệp thực thi

Lệnh bazel run tương tự như bazel build, ngoại trừ việc dùng lệnh này để tạo và chạy một mục tiêu duy nhất. Dưới đây là một phiên thông thường:

  % 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 tương tự nhưng không giống hệt nhau, khi gọi trực tiếp tệp nhị phân do Bazel tạo và hành vi của tệp nhị phân này sẽ khác nhau tuỳ thuộc vào việc tệp nhị phân được gọi có phải là một phép kiểm thử hay không.

Khi tệp nhị phân không phải là kiểm thử, thư mục đang hoạt động hiện tại sẽ là cây runfiles của tệp nhị phân.

Khi tệp nhị phân là một kiểm thử, thư mục đang hoạt động hiện tại sẽ là thư mục gốc thực thi và cố gắng sao chép các kiểm thử môi trường thường được chạy. Tuy nhiên, việc mô phỏng không hoàn hảo và bạn không thể chạy kiểm thử có nhiều phân đoạn theo cách này (bạn có thể sử dụng tuỳ chọn dòng lệnh --test_sharding_strategy=disabled để giải quyết vấn đề này)

Các biến môi trường bổ sung sau đây cũng có sẵn cho tệp nhị phân:

BUILD_WORKSPACE_DIRECTORY: gốc của không gian làm việc nơi bản dựng được chạy.
BUILD_WORKING_DIRECTORY: thư mục đang hoạt động hiện tại là nơi chạy Bazel.

Ví dụ: bạn có thể sử dụng các lệnh này để diễn giải tên tệp trên dòng lệnh theo cách thân thiện với người dùng.

Tuỳ chọn cho `bazel run`

`--run_under=command-prefix`

Cách này có tác dụng tương tự như tuỳ chọn --run_under cho bazel test (xem ở trên), ngoại trừ việc tuỳ chọn này áp dụng cho lệnh đang được bazel run chạy thay vì áp dụng cho các kiểm thử được chạy bởi bazel test và không thể chạy trong nhãn.

Lọc kết quả ghi nhật ký từ Bazel

Khi gọi một tệp nhị phân bằng bazel run, Bazel sẽ in kết quả ghi nhật ký từ chính Bazel và tệp nhị phân khi gọi. Để nhật ký bớt ồn ào hơn, bạn có thể chặn dữ liệu đầu ra từ chính Bazel bằng cờ --ui_event_filters và --noshow_progress.

Ví dụ: bazel run --ui_event_filters=-info,-stdout,-stderr --noshow_progress //java/myapp:myapp

Thực thi kiểm thử

bazel run cũng có thể thực thi các tệp nhị phân kiểm thử. Tệp này có tác dụng chạy kiểm thử gần đúng với môi trường được mô tả trong phần Viết kiểm thử. Lưu ý rằng không có đối số --test_* nào có hiệu lực khi chạy kiểm thử theo cách này, ngoại trừ --test_arg .

Dọn dẹp đầu ra của bản dựng

Lệnh `clean`

Bazel có một lệnh clean, tương tự như lệnh của Make. Thao tác này sẽ xoá các thư mục đầu ra cho tất cả cấu hình bản dựng do thực thể Bazel này thực hiện hoặc toàn bộ cây hoạt động do thực thể Bazel này tạo ra, đồng thời đặt lại bộ nhớ đệm nội bộ. Nếu được thực thi mà không có tuỳ chọn dòng lệnh nào, thì thư mục đầu ra cho tất cả các cấu hình sẽ bị xoá.

Hãy nhớ rằng mỗi thực thể Bazel được liên kết với một không gian làm việc duy nhất, do đó, lệnh clean sẽ xoá tất cả kết quả đầu ra khỏi tất cả các bản dựng bạn đã thực hiện với thực thể Bazel đó trong không gian làm việc đó.

Để xoá hoàn toàn toàn bộ cây hoạt động do một thực thể Bazel tạo, bạn có thể chỉ định tuỳ chọn --expunge. Khi được thực thi bằng --expunge, lệnh sạch sẽ chỉ xoá toàn bộ cây cơ sở đầu ra. Ngoài ra, cây cơ sở đầu ra còn chứa tất cả các tệp tạm thời do Bazel tạo. Thao tác này cũng dừng máy chủ Bazel sau khi dọn dẹp, tương đương với lệnh shutdown. Ví dụ: để dọn dẹp tất cả dấu vết trên ổ đĩa và bộ nhớ của một thực thể Bazel, bạn có thể chỉ định:

  % bazel clean --expunge

Ngoài ra, bạn có thể dọn sạch trong nền bằng cách sử dụng --expunge_async. Bạn có thể an toàn gọi một lệnh Bazel trong cùng một ứng dụng trong khi trình dọn dẹp không đồng bộ tiếp tục chạy.

Lệnh clean được cung cấp chủ yếu để lấy lại dung lượng ổ đĩa cho các không gian làm việc không còn cần thiết. Các bản tạo lại tăng dần của Bazel có thể không hoàn hảo vì vậy bạn có thể sử dụng clean để khôi phục trạng thái nhất quán khi phát sinh sự cố.

Thiết kế của Bazel là có thể khắc phục những vấn đề này và những lỗi này được ưu tiên cao cần được khắc phục. Nếu bạn phát hiện một bản dựng tăng dần không chính xác, hãy gửi báo cáo lỗi và báo cáo lỗi trong các công cụ thay vì sử dụng clean.

Truy vấn biểu đồ phần phụ thuộc

Bazel sử dụng ngôn ngữ truy vấn để đặt câu hỏi về biểu đồ phần phụ thuộc được sử dụng trong quá trình tạo bản dựng. Ngôn ngữ truy vấn được 2 lệnh sử dụng: query và cquery. Điểm khác biệt chính giữa 2 lệnh là truy vấn chạy sau giai đoạn tải và cquery chạy sau giai đoạn phân tích. Những công cụ này là trợ giúp vô giá cho nhiều công việc kỹ thuật phần mềm.

Ngôn ngữ truy vấn dựa trên ý tưởng về các phép toán đại số trên biểu đồ; ngôn ngữ này được ghi lại chi tiết trong

Tài liệu tham khảo về truy vấn Bazel. Vui lòng tham khảo tài liệu đó để tham khảo ví dụ và để biết các tuỳ chọn dòng lệnh dành riêng cho truy vấn.

Công cụ truy vấn chấp nhận một số tuỳ chọn dòng lệnh. --output chọn định dạng đầu ra. --[no]keep_going (bị tắt theo mặc định) khiến công cụ truy vấn tiếp tục tiến hành khi gặp lỗi; hành vi này có thể bị vô hiệu hoá nếu kết quả không đầy đủ không được chấp nhận trong trường hợp có lỗi.

Tuỳ chọn --[no]tool_deps (được bật theo mặc định) sẽ đưa các phần phụ thuộc trong cấu hình không phải mục tiêu vào biểu đồ phần phụ thuộc mà truy vấn hoạt động qua đó.

Tuỳ chọn --[no]implicit_deps, được bật theo mặc định, khiến các phần phụ thuộc ngầm ẩn được đưa vào biểu đồ phần phụ thuộc mà truy vấn hoạt động. Phần phụ thuộc ngầm ẩn là phần phụ thuộc không được chỉ định rõ ràng trong tệp BUILD nhưng được bazel thêm vào.

Ví dụ: "Hiển thị vị trí của các định nghĩa (trong tệp BUILD) của tất cả các quy tắc tạo sinh cần thiết để tạo tất cả các kiểm thử trong cây PEBL".

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

Truy vấn biểu đồ hành động

Lệnh aquery cho phép bạn truy vấn các hành động trong biểu đồ bản dựng. API này hoạt động trên biểu đồ mục tiêu được định cấu hình sau phân tích và hiển thị thông tin về các hành động, cấu phần phần mềm và mối quan hệ của chúng.

Công cụ này chấp nhận một số tuỳ chọn dòng lệnh. --output chọn định dạng đầu ra. Định dạng đầu ra mặc định (text) là định dạng mà con người có thể đọc được, hãy sử dụng proto hoặc textproto cho định dạng mà máy có thể đọc được. Đáng chú ý là lệnh aquery chạy trên một bản dựng Bazel thông thường và kế thừa tập hợp tuỳ chọn có sẵn trong bản dựng.

Phiên bản này hỗ trợ cùng một tập hợp hàm có sẵn cho query truyền thống nhưng siblings, buildfiles và tests.

Để biết thêm thông tin chi tiết, hãy xem phần Truy vấn biểu đồ hành động.

Các lệnh và tuỳ chọn khác

`help`

Lệnh help cung cấp trợ giúp trực tuyến. Theo mặc định, tuỳ chọn này sẽ hiển thị bản tóm tắt các lệnh có sẵn và chủ đề trợ giúp, như minh hoạ trong phần Xây dựng bằng Bazel. Việc chỉ định một đối số sẽ hiển thị trợ giúp chi tiết cho một chủ đề cụ thể. Hầu hết chủ đề là các lệnh Bazel, chẳng hạn như build hoặc query, nhưng có một số chủ đề trợ giúp khác không tương ứng với các lệnh.

`--[no]long` (`-l`)

Theo mặc định, bazel help [topic] chỉ in phần tóm tắt các lựa chọn liên quan cho một chủ đề. Nếu bạn chỉ định tuỳ chọn --long, thì hệ thống cũng sẽ in loại, giá trị mặc định và nội dung mô tả đầy đủ của từng tuỳ chọn.

`shutdown`

Bạn có thể dùng lệnh shutdown để dừng các quy trình của máy chủ Bazel. Lệnh này khiến máy chủ Bazel thoát ngay khi chuyển sang trạng thái rảnh (ví dụ: sau khi hoàn thành bất kỳ bản dựng nào hoặc lệnh khác đang diễn ra). Để biết thêm thông tin chi tiết, hãy xem bài viết Triển khai ứng dụng/máy chủ.

Các máy chủ Bazel sẽ tự dừng sau khi hết thời gian chờ ở trạng thái rảnh, vì vậy, lệnh này hiếm khi cần thiết. Tuy nhiên, lệnh này có thể hữu ích trong tập lệnh khi biết rằng sẽ không có thêm bản dựng nào xảy ra trong một không gian làm việc nhất định.

shutdown chấp nhận một tuỳ chọn là --iff_heap_size_greater_than _n_. Tuỳ chọn này yêu cầu đối số số nguyên (tính bằng MB). Nếu được chỉ định, thao tác này sẽ tắt có điều kiện đối với dung lượng bộ nhớ đã sử dụng. Điều này rất hữu ích đối với các tập lệnh khởi tạo nhiều bản dựng, vì mọi sự cố rò rỉ bộ nhớ trong máy chủ Bazel đều có thể khiến máy chủ gặp sự cố ngẫu nhiên; việc khởi động lại có điều kiện sẽ giành quyền sử dụng điều kiện này.

`info`

Lệnh info in nhiều giá trị liên kết với thực thể máy chủ Bazel hoặc với một cấu hình bản dựng cụ thể. (Các tập lệnh thúc đẩy bản dựng có thể sử dụng các tập lệnh này.)

Lệnh info cũng cho phép một đối số duy nhất (không bắt buộc), đó là tên của một trong các khoá trong danh sách bên dưới. Trong trường hợp này, bazel info key sẽ chỉ in giá trị cho một khoá đó. (Điều này đặc biệt thuận tiện khi viết tập lệnh cho Bazel, vì tính năng này giúp bạn không cần phải gửi kết quả thông qua sed -ne /key:/s/key://p:

Dữ liệu không phụ thuộc vào cấu hình

release: nhãn phát hành cho phiên bản Bazel này hoặc "phiên bản phát triển" nếu đây không phải là tệp nhị phân được phát hành.
workspace đường dẫn tuyệt đối đến thư mục không gian làm việc cơ sở.
install_base: đường dẫn tuyệt đối đến thư mục cài đặt mà thực thể Bazel này sử dụng cho người dùng hiện tại. Bazel cài đặt các tệp thực thi bắt buộc nội bộ bên dưới thư mục này.
output_base: đường dẫn tuyệt đối đến thư mục đầu ra cơ sở mà thực thể Bazel này sử dụng cho tổ hợp người dùng và không gian làm việc hiện tại. Bazel đặt toàn bộ bản dựng ban đầu và bản dựng đầu ra bên dưới thư mục này.
execution_root: đường dẫn tuyệt đối đến thư mục gốc thực thi trong output_base. Thư mục này là gốc của tất cả các tệp có thể truy cập vào các lệnh được thực thi trong bản dựng và là thư mục hoạt động cho các lệnh đó. Nếu thư mục không gian làm việc có thể ghi, thì một đường liên kết tượng trưng có tên bazel-<workspace> sẽ được đặt ở đó trỏ đến thư mục này.
output_path: đường dẫn tuyệt đối đến thư mục đầu ra bên dưới thư mục gốc thực thi được dùng cho mọi tệp thực sự được tạo do lệnh tạo bản dựng. Nếu thư mục không gian làm việc có thể ghi, thì một đường liên kết tượng trưng có tên bazel-out sẽ được đặt ở đó trỏ đến thư mục này.
server_pid: mã nhận dạng của quy trình máy chủ Bazel.
server_log: đường dẫn tuyệt đối đến tệp nhật ký gỡ lỗi của máy chủ Bazel. Tệp này chứa thông tin gỡ lỗi cho tất cả các lệnh trong suốt thời gian hoạt động của máy chủ Bazel và dành cho các nhà phát triển và người dùng thành thạo của Bazel sử dụng.
command_log: đường dẫn tuyệt đối đến tệp nhật ký lệnh; đường dẫn này chứa các luồng stdout và stderr xen kẽ của lệnh Bazel gần đây nhất. Lưu ý rằng việc chạy bazel info sẽ ghi đè nội dung của tệp này, vì sau đó tệp này sẽ trở thành lệnh Bazel gần đây nhất. Tuy nhiên, vị trí của tệp nhật ký lệnh sẽ không thay đổi trừ phi bạn thay đổi chế độ cài đặt của tuỳ chọn --output_base hoặc --output_user_root.
used-heap-size, committed-heap-size, max-heap-size: báo cáo nhiều tham số kích thước vùng nhớ khối xếp JVM. Tương ứng: bộ nhớ hiện đang được sử dụng, bộ nhớ hiện được hệ thống đảm bảo có thể cung cấp cho JVM từ hệ thống, mức phân bổ tối đa có thể.
gc-count, gc-time: Tổng số lượt thu gom rác tích luỹ kể từ thời điểm máy chủ Bazel này khởi động và thời gian thực hiện việc thu gom rác. Lưu ý rằng các giá trị này không được đặt lại khi bắt đầu mỗi bản dựng.
package_path: Danh sách các đường dẫn được phân tách bằng dấu hai chấm mà bạn có thể tìm kiếm các gói bằng bazel. Có cùng định dạng với đối số dòng lệnh tạo bản dựng --package_path.

Ví dụ: mã nhận dạng quy trình của máy chủ Bazel.

% bazel info server_pid
1285

Dữ liệu theo cấu hình cụ thể

Những dữ liệu này có thể bị ảnh hưởng bởi các tuỳ chọn cấu hình được chuyển đến bazel info, ví dụ: --cpu, --compilation_mode, v.v. Lệnh info chấp nhận tất cả các tuỳ chọn kiểm soát việc phân tích phần phụ thuộc, vì một số tuỳ chọn này xác định vị trí của thư mục đầu ra của bản dựng, lựa chọn trình biên dịch, v.v.

bazel-bin, bazel-testlogs, bazel-genfiles: báo cáo đường dẫn tuyệt đối đến thư mục bazel-* chứa các chương trình do bản dựng tạo ra. Tuy không phải lúc nào cũng giống với các đường liên kết tượng trưng bazel-* được tạo trong thư mục không gian làm việc cơ sở sau một bản dựng thành công. Tuy nhiên, nếu thư mục không gian làm việc ở chế độ chỉ đọc, thì bạn không thể tạo đường liên kết tượng trưng bazel-*. Các tập lệnh sử dụng giá trị do bazel info báo cáo, thay vì giả định rằng sự tồn tại của đường liên kết tượng trưng, sẽ mạnh mẽ hơn.
Môi trường"Tạo" hoàn chỉnh. Nếu cờ --show_make_env được chỉ định, tất cả biến trong môi trường "Tạo" của cấu hình hiện tại cũng sẽ hiển thị (chẳng hạn như CC, GLIBC_VERSION, v.v.). Đây là các biến được truy cập bằng cú pháp $(CC) hoặc varref("CC") bên trong các tệp BUILD.

Ví dụ: trình biên dịch C++ cho cấu hình hiện tại. Đây là biến $(CC) trong môi trường "Make" (Tạo), vì vậy, cờ --show_make_env là cần thiết.

  % bazel info --show_make_env -c opt COMPILATION_MODE
  opt

Ví dụ: thư mục đầu ra bazel-bin cho cấu hình hiện tại. Điều này đảm bảo sẽ chính xác ngay cả trong trường hợp không thể tạo đường liên kết tượng trưng bazel-bin vì một số lý do (chẳng hạn như khi bạn tạo từ một thư mục chỉ có thể đọc).

% 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` và `--version`

Lệnh phiên bản in thông tin chi tiết về phiên bản tệp nhị phân Bazel đã tạo, bao gồm danh sách thay đổi nơi tệp nhị phân được tạo và ngày tạo. Các thao tác này đặc biệt hữu ích trong việc xác định xem bạn có Bazel mới nhất hay đang báo cáo lỗi. Một số giá trị thú vị là:

changelist: danh sách thay đổi mà phiên bản Bazel này được phát hành.
label: nhãn phát hành cho phiên bản Bazel này hoặc "phiên bản phát triển" nếu đây không phải là tệp nhị phân được phát hành. Rất hữu ích khi báo cáo lỗi.

bazel --version, không có đối số nào khác, sẽ phát ra cùng một đầu ra như bazel version --gnu_format, ngoại trừ việc có thể khởi động máy chủ Bazel hoặc giải nén tệp lưu trữ máy chủ. bazel --version có thể chạy từ bất cứ đâu mà không cần có thư mục không gian làm việc.

`mobile-install`

Lệnh mobile-install cài đặt ứng dụng xuống thiết bị di động. Hiện tại, chỉ các thiết bị Android chạy ART mới được hỗ trợ.

Xem phần cài đặt trên thiết bị di động baazel để biết thêm thông tin.

Các tuỳ chọn sau được hỗ trợ:

`--incremental`

Nếu được đặt, Bazel sẽ cố gắng cài đặt ứng dụng dần dần, tức là chỉ những phần đã thay đổi kể từ bản dựng cuối cùng. Điều này không thể cập nhật các tài nguyên được tham chiếu từ AndroidManifest.xml, mã gốc hoặc tài nguyên Java (chẳng hạn như các tài nguyên được Class.getResource() tham chiếu). Nếu những nội dung này thay đổi, bạn phải bỏ qua lựa chọn này. Trái ngược với tinh thần của Bazel và do các hạn chế của nền tảng Android, người dùng có trách nhiệm biết khi nào lệnh này đủ hiệu quả và khi nào cần cài đặt đầy đủ.

Nếu bạn đang dùng thiết bị chạy Marshmallow trở lên, hãy cân nhắc sử dụng cờ --split_apks.

`--split_apks`

Liệu có sử dụng tệp apk phân tách để cài đặt và cập nhật ứng dụng trên thiết bị hay không. Chỉ hoạt động với các thiết bị chạy Marshmallow trở lên. Xin lưu ý rằng bạn không cần cờ --incremental khi sử dụng --split_apks.

`--start_app`

Khởi động ứng dụng ở trạng thái mới sau khi cài đặt. Tương đương với --start=COLD.

`--debug_app`

Chờ đính kèm trình gỡ lỗi trước khi khởi động ứng dụng ở trạng thái sạch sau khi cài đặt. Tương đương với --start=DEBUG.

`--start=_start_type_`

Cách khởi động ứng dụng sau khi cài đặt. Các thuộc tính _start_type_s được hỗ trợ là:

NO không khởi động ứng dụng. Đây là chế độ mặc định.
COLD Khởi động ứng dụng ở trạng thái sạch sau khi cài đặt.
WARM Duy trì và khôi phục trạng thái của ứng dụng khi cài đặt dần dần.
DEBUG Chờ trình gỡ lỗi trước khi khởi động ứng dụng ở trạng thái sạch sau khi cài đặt.

`--adb=path`

Cho biết tệp nhị phân adb sẽ được sử dụng.

Mặc định là sử dụng adb trong SDK Android do --android_sdk chỉ định.

`--adb_arg=serial`

Đối số bổ sung cho adb. Các lệnh này xuất hiện trước lệnh con trong dòng lệnh và thường dùng để chỉ định thiết bị nào sẽ cài đặt. Ví dụ: để chọn thiết bị Android hoặc trình mô phỏng mà bạn muốn sử dụng, hãy làm như sau:

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

gọi adb dưới dạng

adb -s deadbeef install ...

`--incremental_install_verbosity=number`

Độ chi tiết của lượt cài đặt gia tăng. Đặt là 1 để in nhật ký gỡ lỗi lên bảng điều khiển.

`dump`

Lệnh dump in để xuất một tệp kết xuất trạng thái nội bộ của máy chủ Bazel. Lệnh này chủ yếu dành cho các nhà phát triển Bazel, vì vậy, kết quả của lệnh này không được chỉ định và có thể thay đổi.

Theo mặc định, lệnh sẽ chỉ in thông báo trợ giúp nêu rõ các tuỳ chọn có thể kết xuất các khu vực cụ thể của trạng thái Bazel. Để kết xuất trạng thái nội bộ, bạn phải chỉ định ít nhất một trong các tuỳ chọn.

Các tuỳ chọn sau được hỗ trợ:

--action_cache kết xuất nội dung trong bộ nhớ đệm hành động.
--packages kết xuất nội dung trong bộ nhớ đệm của gói.
--skyframe kết xuất trạng thái của biểu đồ phần phụ thuộc Bazel nội bộ.
--rules kết xuất bản tóm tắt quy tắc cho từng quy tắc và lớp khía cạnh, bao gồm cả số lượng và số hành động. Điều này bao gồm cả quy tắc gốc và quy tắc Starlark. Nếu tính năng theo dõi bộ nhớ được bật thì mức sử dụng bộ nhớ của các quy tắc cũng được in.
--skylark_memory sẽ kết xuất tệp .gz tương thích pprof vào đường dẫn đã chỉ định. Bạn phải bật tính năng theo dõi bộ nhớ để mã này hoạt động.

Theo dõi bộ nhớ

Một số lệnh dump yêu cầu theo dõi bộ nhớ. Để bật tính năng này, bạn phải chuyển cờ khởi động cho 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 được đăng ký vào Bazel tại third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar, vì vậy, hãy nhớ điều chỉnh $BAZEL cho vị trí bạn lưu kho lưu trữ Bazel.

Đừng quên tiếp tục truyền các tuỳ chọn này cho Bazel đối với mọi lệnh, nếu không máy chủ sẽ khởi động lại.

Ví dụ:

    % 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`

Lệnh analyze-profile phân tích dữ liệu đã thu thập trước đó trong quá trình tạo bản dựng bằng cách sử dụng tuỳ chọn --profile. Tệp này cung cấp một số tuỳ chọn để phân tích quá trình thực thi bản dựng hoặc xuất dữ liệu ở định dạng được chỉ định.

Các tuỳ chọn sau được hỗ trợ:

--dump hiển thị tất cả dữ liệu được thu thập ở định dạng con người có thể đọc được. Tuy nhiên, tính năng này chưa hỗ trợ các định dạng khác.

Để biết thông tin chi tiết về định dạng và trợ giúp về cách sử dụng, hãy xem phần Khắc phục sự cố về hiệu suất bằng cách phân tích tài nguyên.

`canonicalize-flags`

Lệnh canonicalize-flags lấy danh sách các tuỳ chọn cho lệnh Bazel và trả về danh sách các tuỳ chọn có tác dụng tương tự. Danh sách tuỳ chọn mới là danh sách chính tắc. Ví dụ: 2 danh sách tuỳ chọn có cùng hiệu ứng được chuẩn hoá thành cùng một danh sách mới.

Bạn có thể sử dụng tuỳ chọn --for_command để chọn giữa các lệnh khác nhau. Tại thời điểm này, chỉ build và test được hỗ trợ. Các tuỳ chọn mà lệnh đã cho không hỗ trợ sẽ gây ra lỗi.

Ví dụ:

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

Tuỳ chọn khởi động

Các tuỳ chọn được mô tả trong phần này ảnh hưởng đến việc khởi động máy ảo Java mà quy trình máy chủ Bazel sử dụng và áp dụng cho tất cả các lệnh tiếp theo do máy chủ đó xử lý. Nếu có một máy chủ Bazel đang chạy mà các tuỳ chọn khởi động không khớp, thì máy chủ đó sẽ được khởi động lại.

Bạn phải chỉ định tất cả các tuỳ chọn được mô tả trong phần này bằng cú pháp --key=value hoặc --key value. Ngoài ra, các tuỳ chọn này phải xuất hiện trước tên của lệnh Bazel. Sử dụng startup --key=value để liệt kê các thành phần này trong tệp .bazelrc.

`--output_base=dir`

Tuỳ chọn này yêu cầu một đối số đường dẫn phải chỉ định một thư mục có thể ghi. Bazel sẽ sử dụng vị trí này để ghi tất cả kết quả đầu ra. Cơ sở đầu ra cũng là khoá mà ứng dụng xác định vị trí máy chủ Bazel. Bằng cách thay đổi cơ sở đầu ra, bạn thay đổi máy chủ sẽ xử lý lệnh.

Theo mặc định, cơ sở đầu ra được lấy từ tên đăng nhập của người dùng và tên của thư mục không gian làm việc (thực tế là chuỗi đại diện MD5), vì vậy, một giá trị thông thường sẽ có dạng như sau: /var/tmp/google/_bazel_johndoe/d41d8cd98f00b204e9800998ecf8427e.

Ví dụ:

 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

Trong lệnh này, hai lệnh Bazel chạy đồng thời (vì toán tử shell &), mỗi lệnh sử dụng một phiên bản máy chủ Bazel khác nhau (vì cơ sở đầu ra khác nhau). Ngược lại, nếu cơ sở đầu ra mặc định được sử dụng trong cả hai lệnh, thì cả hai yêu cầu sẽ được gửi đến cùng một máy chủ để xử lý tuần tự: tạo //foo trước, sau đó tạo một bản dựng //bar tăng dần.

`--output_user_root=dir`

Trỏ đến thư mục gốc nơi tạo cơ sở đầu ra và số lượt cài đặt. Thư mục không được tồn tại hoặc thuộc sở hữu của người dùng gọi. Trước đây, trang web này được phép trỏ đến một thư mục được chia sẻ giữa nhiều người dùng, nhưng giờ đã không được phép nữa. Điều này có thể được cho phép sau khi xử lý xong vấn đề #11100.

Nếu tuỳ chọn --output_base được chỉ định, tuỳ chọn này sẽ ghi đè bằng cách sử dụng --output_user_root để tính cơ số đầu ra.

Vị trí cơ sở cài đặt được tính toán dựa trên --output_user_root, cùng với thông tin nhận dạng MD5 của các tệp nhị phân nhúng Bazel.

Bạn có thể sử dụng tuỳ chọn --output_user_root để chọn vị trí cơ sở thay thế cho toàn bộ đầu ra của Bazel (cơ sở cài đặt và cơ sở đầu ra) nếu có vị trí tốt hơn trong bố cục hệ thống tệp của bạn.

`--server_javabase=dir`

Chỉ định máy ảo Java mà chính Bazel chạy. Giá trị phải là một đường dẫn đến thư mục chứa JDK hoặc JRE. Đó không được là một nhãn. Tuỳ chọn này sẽ xuất hiện trước bất kỳ lệnh Bazel nào, ví dụ:

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

Cờ này không ảnh hưởng đến các JVM mà các quy trình phụ Bazel sử dụng, chẳng hạn như ứng dụng, kiểm thử, công cụ, v.v. Thay vào đó, hãy sử dụng các tuỳ chọn bản dựng --javabase hoặc --host_javabase.

Cờ này trước đây có tên là --host_javabase (đôi khi được gọi là --host_javabase "phía bên trái") nhưng đã được đổi tên để tránh nhầm lẫn với cờ bản dựng --host_javabase (đôi khi được gọi là --host_javabase "phía bên phải").

`--host_jvm_args=string`

Chỉ định một tuỳ chọn khởi động để truyền đến máy ảo Java mà chính Bazel sẽ chạy. Bạn có thể sử dụng thuộc tính này để đặt kích thước ngăn xếp, ví dụ:

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

Bạn có thể sử dụng tuỳ chọn này nhiều lần với các đối số riêng lẻ. Xin lưu ý rằng bạn hiếm khi cần đặt cờ này. Bạn cũng có thể truyền một danh sách các chuỗi được phân tách bằng dấu cách, mỗi chuỗi sẽ được hiểu là một đối số JVM riêng biệt, nhưng tính năng này sẽ sớm ngừng hoạt động.

Điều này không ảnh hưởng đến bất kỳ JVM nào được các quy trình con của Bazel sử dụng: ứng dụng, kiểm thử, công cụ, v.v. Để chuyển các tuỳ chọn JVM đến các chương trình Java có thể thực thi, cho dù chạy bằng bazel run hay trên dòng lệnh, bạn nên sử dụng đối số --jvm_flags mà tất cả các chương trình java_binary và java_test đều hỗ trợ. Ngoài ra, đối với chương trình kiểm thử, hãy sử dụng bazel test --test_arg=--jvm_flags=foo ....

`--host_jvm_debug`

Tuỳ chọn này khiến máy ảo Java phải đợi kết nối từ trình gỡ lỗi tuân thủ JDWP trước khi gọi phương thức chính của chính Bazel. Thư viện này chủ yếu dành cho các nhà phát triển Bazel sử dụng.

`--autodetect_server_javabase`

Tuỳ chọn này khiến Bazel tự động tìm kiếm JDK đã cài đặt khi khởi động và quay lại JRE đã cài đặt nếu JRE được nhúng không có sẵn. Bạn có thể sử dụng --explicit_server_javabase để chọn một JRE rõ ràng để chạy Bazel.

`--batch`

Chế độ lô khiến Bazel không sử dụng chế độ máy khách/máy chủ tiêu chuẩn mà thay vào đó chạy quy trình Java cho một lệnh duy nhất. Quy trình này được dùng cho ngữ nghĩa dễ dự đoán hơn về việc xử lý tín hiệu, kiểm soát công việc và kế thừa biến môi trường. Cần thiết để chạy bazel trong nhà tù chroot.

Chế độ lô giữ lại các ngữ nghĩa xếp hàng thích hợp trong cùng một output_base. Tức là các lệnh gọi đồng thời sẽ được xử lý theo thứ tự mà không bị trùng lặp. Nếu một chế độ hàng loạt Bazel chạy trên một ứng dụng có máy chủ đang chạy, thì trước tiên, chế độ này sẽ đóng máy chủ trước khi xử lý lệnh.

Bazel sẽ chạy chậm hơn ở chế độ lô hoặc với các giải pháp thay thế được mô tả ở trên. Lý do là bộ nhớ đệm của tệp bản dựng nằm trong bộ nhớ nên không được duy trì giữa các lệnh gọi lô theo tuần tự. Do đó, việc sử dụng chế độ hàng loạt thường hợp lý hơn trong các trường hợp hiệu suất ít quan trọng hơn, chẳng hạn như bản dựng liên tục.

`--max_idle_secs=n`

Tuỳ chọn này chỉ định thời lượng (tính bằng giây) mà quy trình máy chủ Bazel sẽ đợi sau khi ứng dụng yêu cầu cuối cùng, trước khi thoát. Giá trị mặc định là 10800 (3 giờ). --max_idle_secs=0 sẽ khiến quá trình máy chủ Bazel tồn tại vô thời hạn.

Các tập lệnh gọi Bazel có thể sử dụng tuỳ chọn này để đảm bảo rằng các quy trình này không rời khỏi các quy trình máy chủ Bazel trên máy của người dùng khi các quy trình này sẽ không chạy. Ví dụ: một tập lệnh gửi trước có thể muốn gọi bazel query để đảm bảo rằng thay đổi đang chờ xử lý của người dùng không tạo ra các phần phụ thuộc không mong muốn. Tuy nhiên, nếu gần đây người dùng chưa tạo bản dựng trong không gian làm việc đó, thì tập lệnh gửi trước cần khởi động máy chủ Bazel chỉ để tập lệnh đó không hoạt động trong thời gian còn lại trong ngày. Bằng cách chỉ định một giá trị nhỏ của --max_idle_secs trong yêu cầu truy vấn, tập lệnh có thể đảm bảo rằng if khiến máy chủ mới khởi động, thì máy chủ đó sẽ thoát ngay, nhưng nếu đã có một máy chủ đang chạy, thì máy chủ đó sẽ tiếp tục chạy cho đến khi không hoạt động trong thời gian bình thường. Tất nhiên, bộ tính giờ ở trạng thái rảnh của máy chủ hiện tại sẽ được đặt lại.

`--[no]shutdown_on_low_sys_mem`

Nếu bạn bật và đặt --max_idle_secs thành một khoảng thời gian dương, thì sau khi máy chủ bản dựng không hoạt động trong một khoảng thời gian, hãy tắt máy chủ khi hệ thống sắp hết bộ nhớ. Chỉ dành cho Linux.

Ngoài việc chạy quy trình kiểm tra trạng thái rảnh tương ứng với max_idle_secs, máy chủ bản dựng sẽ bắt đầu giám sát bộ nhớ hệ thống còn trống sau khi máy chủ không hoạt động trong một khoảng thời gian. Nếu bộ nhớ hệ thống còn trống quá thấp, máy chủ sẽ thoát.

`--[no]block_for_lock`

Nếu bật, Bazel sẽ đợi các lệnh Bazel khác giữ khoá máy chủ hoàn tất trước khi tiếp tục. Nếu bị tắt, Bazel sẽ thoát do nhầm lẫn nếu không thể mở khoá ngay lập tức và tiếp tục.

Nhà phát triển có thể sử dụng tính năng này trong các bước kiểm tra trước khi gửi để tránh phải chờ lâu do một lệnh Bazel khác trong cùng một ứng dụng.

`--io_nice_level=n`

Đặt mức từ 0 đến 7 để lên lịch IO hiệu quả nhất. 0 là mức độ ưu tiên cao nhất, 7 là thấp nhất. Trình lập lịch biểu dự đoán chỉ có thể thực hiện lên mức ưu tiên 4. Giá trị âm sẽ bị bỏ qua.

`--batch_cpu_scheduling`

Sử dụng tính năng lập lịch biểu CPU của batch cho Bazel. Chính sách này hữu ích đối với các tải công việc không mang tính tương tác, nhưng không muốn hạ thấp giá trị tốt đẹp của chúng. Xem 'man 2 sched_setscheduler'. Chính sách này có thể cải thiện khả năng tương tác của hệ thống với chi phí thông lượng Bazel.

Tuỳ chọn khác

`--[no]announce_rc`

Kiểm soát việc Bazel có thông báo các tuỳ chọn lệnh được đọc từ tệp bazelrc khi khởi động hay không. (Các lựa chọn khởi động được thông báo vô điều kiện.)

`--color (yes|no|auto)`

Tuỳ chọn này xác định liệu Bazel có sử dụng màu sắc để làm nổi bật đầu ra trên màn hình hay không.

Nếu bạn đặt tuỳ chọn này thành yes, thì tính năng đầu ra màu sẽ bật. Nếu bạn đặt tuỳ chọn này thành auto, Bazel sẽ chỉ sử dụng đầu ra màu nếu đầu ra đang được gửi đến một thiết bị đầu cuối và biến môi trường term được đặt thành một giá trị không phải là dumb, emacs hoặc xterm-mono. Nếu bạn đặt tuỳ chọn này thành no, thì tính năng đầu ra màu sẽ bị tắt, bất kể đầu ra có chuyển đến thiết bị đầu cuối hay không và bất kể chế độ cài đặt của biến môi trường term.

`--config=name`

Chọn phần cấu hình bổ sung từ các tệp rc; đối với command hiện tại, thao tác này cũng lấy các tuỳ chọn từ command:name nếu có phần như vậy. Có thể được chỉ định nhiều lần để thêm cờ từ nhiều phần cấu hình. Bản mở rộng có thể tham chiếu đến các định nghĩa khác (ví dụ: bản mở rộng có thể theo chuỗi).

`--curses (yes|no|auto)`

Tuỳ chọn này xác định liệu Bazel có sử dụng các chế độ điều khiển con trỏ trong đầu ra màn hình hay không. Điều này giúp giảm bớt dữ liệu cuộn và tạo luồng đầu ra nhỏ gọn, dễ đọc hơn từ Bazel. Cách này hoạt động hiệu quả với --color.

Nếu bạn đặt tuỳ chọn này thành yes, thì chế độ sử dụng các chế độ điều khiển con trỏ sẽ bật. Nếu bạn đặt tuỳ chọn này thành no, thì chế độ sử dụng các chế độ điều khiển con trỏ sẽ tắt. Nếu bạn đặt tuỳ chọn này thành auto, thì việc sử dụng các chế độ điều khiển con trỏ sẽ được bật trong cùng điều kiện như đối với --color=auto.

`--[no]show_timestamps`

Nếu được chỉ định, dấu thời gian sẽ được thêm vào mỗi thông báo do Bazel tạo, trong đó chỉ định thời điểm hiển thị thông báo.

Lệnh và tuỳ chọn

Cú pháp mục tiêu

Tùy chọn

Vị trí gói hàng

--package_path

--deleted_packages

Kiểm tra lỗi

--[no]check_visibility

--output_filter=regex

Cờ công cụ

--copt=cc-option

--host_copt=cc-option

--host_conlyopt=cc-option

--host_cxxopt=cc-option

--host_linkopt=linker-option

--conlyopt=cc-option

--cxxopt=cc-option

--linkopt=linker-option

--strip (always|never|sometimes)

--stripopt=strip-option

--fdo_instrument=profile-output-dir

--fdo_optimize=profile-zip

--[no]output_symbol_counts

--java_language_version=version

--tool_java_language_version=version

--java_runtime_version=version

--tool_java_runtime_version=version

--jvmopt=jvm-option

--javacopt=javac-option

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

Xây dựng ngữ nghĩa

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

--cpu=cpu

--action_env=VAR=VALUE

--experimental_action_listener=label

--[no]experimental_extra_action_top_level_only

--experimental_extra_action_filter=regex

--host_cpu=cpu

--fat_apk_cpu=cpu[,cpu]*

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

--dynamic_mode=mode

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

--force_ignore_dash_static

--[no]force_pic

--android_resource_shrinking

--custom_malloc=malloc-library-target

--crosstool_top=label

--host_crosstool_top=label

--apple_crosstool_top=label

--android_crosstool_top=label

--compiler=version

--android_sdk=label

--java_toolchain=label

--host_java_toolchain=label

--javabase=(label)

--host_javabase=label

Chiến lược thực thi

--spawn_strategy=strategy

--strategy mnemonic=strategy

--strategy_regexp=&lt;filter,filter,...&gt;=&lt;strategy&gt;

--genrule_strategy=strategy

--jobs=n (-j)

--progress_report_interval=n

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

--[no]build_runfile_links

--[no]build_runfile_manifests

--[no]discard_analysis_cache

--[no]keep_going (-k)

--[no]use_ijars

--[no]interface_shared_objects

Chọn dữ liệu đầu ra

--[no]build

--[no]build_tests_only

--[no]check_up_to_date

--[no]compile_one_dependency

--save_temps

--build_tag_filters=tag[,tag]*

--test_size_filters=size[,size]*

--test_timeout_filters=timeout[,timeout]*

--test_tag_filters=tag[,tag]*

`--package_path`

`--deleted_packages`

`--[no]check_visibility`

`--output_filter=regex`

`--copt=cc-option`

`--host_copt=cc-option`

`--host_conlyopt=cc-option`

`--host_cxxopt=cc-option`

`--host_linkopt=linker-option`

`--conlyopt=cc-option`

`--cxxopt=cc-option`

`--linkopt=linker-option`

`--strip (always|never|sometimes)`

`--stripopt=strip-option`

`--fdo_instrument=profile-output-dir`

`--fdo_optimize=profile-zip`

`--[no]output_symbol_counts`

`--java_language_version=version`

`--tool_java_language_version=version`

`--java_runtime_version=version`

`--tool_java_runtime_version=version`

`--jvmopt=jvm-option`

`--javacopt=javac-option`

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

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

`--cpu=cpu`

`--action_env=VAR=VALUE`

`--experimental_action_listener=label`

`--[no]experimental_extra_action_top_level_only`

`--experimental_extra_action_filter=regex`

`--host_cpu=cpu`

`--fat_apk_cpu=cpu[,cpu]*`

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

`--dynamic_mode=mode`

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

`--force_ignore_dash_static`

`--[no]force_pic`

`--android_resource_shrinking`

`--custom_malloc=malloc-library-target`

`--crosstool_top=label`

`--host_crosstool_top=label`

`--apple_crosstool_top=label`

`--android_crosstool_top=label`

`--compiler=version`

`--android_sdk=label`

`--java_toolchain=label`

`--host_java_toolchain=label`

`--javabase=(label)`

`--host_javabase=label`

`--spawn_strategy=strategy`

`--strategy mnemonic=strategy`

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

`--genrule_strategy=strategy`

`--jobs=n` (-j)

`--progress_report_interval=n`

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

`--[no]build_runfile_links`

`--[no]build_runfile_manifests`

`--[no]discard_analysis_cache`

`--[no]keep_going` (-k)

`--[no]use_ijars`

`--[no]interface_shared_objects`

`--[no]build`

`--[no]build_tests_only`

`--[no]check_up_to_date`

`--[no]compile_one_dependency`

`--save_temps`

`--build_tag_filters=tag[,tag]*`

`--test_size_filters=size[,size]*`

`--test_timeout_filters=timeout[,timeout]*`

`--test_tag_filters=tag[,tag]*`

`--test_lang_filters=lang[,lang]*`

`--test_filter=filter-expression`

`--explain=logfile`

`--verbose_explanations`

`--profile=file`

`--[no]show_loading_progress`

`--[no]show_progress`

`--show_progress_rate_limit=n`

`--show_result=n`