Quy tắc
bí danh
Xem nguồn quy tắcalias(name, actual, compatible_with, deprecation, features, restricted_to, tags, target_compatible_with, testonly, visibility)
Quy tắc alias
tạo ra một tên khác cho quy tắc.
Bí danh chỉ hoạt động cho các mục tiêu "thông thường". Cụ thể, package_group
và test_suite
không được đặt bí danh.
Quy tắc bí danh có nội dung khai báo chế độ hiển thị riêng. Trong mọi khía cạnh khác, quy tắc này hoạt động giống như quy tắc mà tệp tham chiếu (ví dụ: chỉ kiểm thử trên bí danh sẽ bị bỏ qua; việc chỉ kiểm thử quy tắc được tham chiếu sẽ được sử dụng) với một số ngoại lệ nhỏ:
-
Các thử nghiệm sẽ không chạy nếu bí danh của chúng được đề cập trên dòng lệnh. Để xác định một bí danh chạy thử nghiệm được tham chiếu, hãy sử dụng quy tắc
test_suite
có một mục tiêu duy nhất trong thuộc tínhtests
. -
Khi xác định các nhóm môi trường, các bí danh đối với các quy tắc
environment
sẽ không được hỗ trợ. Chúng cũng không được hỗ trợ trong tuỳ chọn dòng lệnh--target_environment
.
Ví dụ
filegroup( name = "data", srcs = ["data.txt"], ) alias( name = "other", actual = ":data", )
Đối số
Thuộc tính | |
---|---|
name |
Tên duy nhất cho mục tiêu này. |
actual
|
|
cài đặt cấu hình
Xem nguồn quy tắcconfig_setting(name, constraint_values, define_values, deprecation, distribs, features, flag_values, licenses, tags, testonly, values, visibility)
Khớp với trạng thái cấu hình dự kiến (được biểu thị dưới dạng cờ bản dựng hoặc các ràng buộc về nền tảng) với mục đích kích hoạt các thuộc tính có thể định cấu hình. Vui lòng xem cách chọn để biết cách sử dụng quy tắc này và Các thuộc tính có thể định cấu hình để biết thông tin tổng quan về tính năng chung.
Ví dụ
Đoạn mã sau khớp với bất kỳ bản dựng nào đặt --compilation_mode=opt
hoặc -c opt
(tức là rõ ràng tại dòng lệnh hoặc hoàn toàn từ tệp .bazelrc):
config_setting( name = "simple", values = {"compilation_mode": "opt"} )
Mục sau đây khớp với bất kỳ bản dựng nào nhắm mục tiêu ARM và áp dụng định nghĩa tùy chỉnh FOO=bar
(ví dụ: bazel build --cpu=arm --define FOO=bar ...
):
config_setting( name = "two_conditions", values = { "cpu": "arm", "define": "FOO=bar" } )
Phần sau khớp với bất kỳ bản dựng nào đặt
cờ do người dùng xác định
--//custom_flags:foo=1
(ở dòng lệnh một cách rõ ràng hoặc trực tiếp từ
tệp .bazelrc):
config_setting( name = "my_custom_flag_is_set", flag_values = { "//custom_flags:foo": "1" }, )
Phần sau khớp với bất kỳ bản dựng nào nhắm mục tiêu một nền tảng có kiến trúc x86_64 và glibc
phiên bản 2.25, giả sử sự tồn tại của constraint_value
với nhãn
//example:glibc_2_25
. Xin lưu ý rằng một nền tảng vẫn khớp nếu xác định thêm các giá trị ràng buộc khác ngoài hai giá trị này.
config_setting( name = "64bit_glibc_2_25", constraint_values = [ "@platforms//cpu:x86_64", "//example:glibc_2_25", ] )Trong tất cả những trường hợp này, có thể cấu hình thay đổi trong bản dựng, ví dụ: nếu mục tiêu cần được xây dựng cho một nền tảng khác với nền tảng phụ thuộc, thì ngay cả khi
config_setting
không khớp với cờ dòng lệnh cấp cao nhất, thì nó vẫn có thể khớp với một số mục tiêu bản dựng.
Ghi chú
- Xem phần chọn để biết điều gì sẽ xảy ra khi nhiều
config_setting
khớp với trạng thái cấu hình hiện tại. - Đối với cờ hỗ trợ biểu mẫu viết tắt (ví dụ:
--compilation_mode
so với-c
), định nghĩavalues
phải sử dụng biểu mẫu đầy đủ. Các lệnh gọi này tự động so khớp lệnh gọi bằng một trong hai biểu mẫu. -
Nếu một cờ nhận nhiều giá trị (như
--copt=-Da --copt=-Db
hoặc một loại cờ danh sách larlark),values = { "flag": "a" }
sẽ khớp nếu"a"
có mặt ở bất kỳ đâu trong danh sách thực tế.values = { "myflag": "a,b" }
hoạt động theo cách tương tự: thuộc tính này khớp với--myflag=a --myflag=b
,--myflag=a --myflag=b --myflag=c
,--myflag=a,b
và--myflag=c,b,a
. Ngữ nghĩa chính xác sẽ khác nhau giữa các cờ. Ví dụ:--copt
không hỗ trợ nhiều giá trị trong cùng một phiên bản:--copt=a,b
tạo ra["a,b"]
trong khi--copt=a --copt=b
tạo ra["a", "b"]
(vì vậy,values = { "copt": "a,b" }
khớp với giá trị cũ nhưng không khớp với giá trị sau). Nhưng--ios_multi_cpus
(đối với quy tắc của Apple) có:-ios_multi_cpus=a,b
vàios_multi_cpus=a --ios_multi_cpus=b
đều tạo ra["a", "b"]
. Hãy kiểm tra định nghĩa cờ và kiểm tra kỹ các điều kiện của bạn để xác minh chính xác kỳ vọng. - Nếu bạn cần xác định những điều kiện không được mô hình hoá bằng cờ bản dựng tích hợp sẵn, hãy sử dụng
cờ Starlark xác định. Bạn cũng có thể sử dụng
--define
. Tuy nhiên, bạn nên sử dụng dịch vụ hỗ trợ kém hơn và chúng tôi không khuyên bạn làm như vậy. Xem tại đây để thảo luận thêm. - Tránh lặp lại định nghĩa
config_setting
giống hệt nhau trong các gói khác nhau. Thay vào đó, hãy tham chiếu đến mộtconfig_setting
phổ biến được xác định trong gói chính tắc. - Bạn có thể dùng
values
,define_values
vàconstraint_values
trong mọi cách kết hợp trong cùng mộtconfig_setting
, nhưng bạn phải đặt ít nhất một tuỳ chọn cho mọiconfig_setting
nhất định.
Đối số
Thuộc tính | |
---|---|
name |
Tên duy nhất cho mục tiêu này. |
constraint_values
|
constraint_values mà nền tảng mục tiêu phải chỉ định để khớp với config_setting này. (Nền tảng thực thi không được
xem xét tại đây.) Mọi giá trị ràng buộc bổ sung mà nền tảng đã bỏ qua. Hãy xem bài viết
Các thuộc tính có thể định cấu hình cho bản dựng để biết thông tin chi tiết.
Trong trường hợp hai |
define_values
|
values nhưng dành riêng cho cờ --define .
Điều đó có nghĩa là: config_setting( name = "a_and_b", values = { "define": "a=1", "define": "b=2", }) không hoạt động vì cùng một khoá ( config_setting( name = "a_and_b", define_values = { "a": "1", "b": "2", }) khớp với
|
flag_values
|
values nhưng đối với
cờ bản dựng do người dùng xác định.
Đây là một thuộc tính riêng biệt vì cờ do người dùng xác định được tham chiếu dưới dạng nhãn trong khi cờ tích hợp được tham chiếu dưới dạng chuỗi tuỳ ý. |
values
|
Quy tắc này kế thừa cấu hình của mục tiêu đã định cấu hình tham chiếu đến cấu hình đó trong câu lệnh Để thuận tiện, hãy chỉ định các giá trị cấu hình dưới dạng cờ bản dựng (không có Nếu cờ không được đặt rõ ràng tại dòng lệnh, giá trị mặc định sẽ được sử dụng.
Nếu một khoá xuất hiện nhiều lần trong từ điển, thì chỉ trường hợp cuối cùng được sử dụng.
Nếu một khoá tham chiếu đến một cờ có thể được đặt nhiều lần trên dòng lệnh (ví dụ:
|
nhóm tệp
Xem nguồn quy tắcfilegroup(name, srcs, data, compatible_with, deprecation, distribs, features, licenses, output_group, restricted_to, tags, target_compatible_with, testonly, visibility)
Sử dụng filegroup
để đặt tên thuận tiện cho tập hợp mục tiêu.
Sau đó, bạn có thể tham chiếu đến những quy tắc này từ các quy tắc khác.
Bạn nên sử dụng filegroup
thay vì tham chiếu trực tiếp các thư mục.
Phần sau không có âm thanh vì hệ thống xây dựng không có đầy đủ kiến thức về tất cả các tệp bên dưới thư mục, do đó có thể không tạo lại được khi những tệp này thay đổi. Khi kết hợp với glob, filegroup
có thể đảm bảo rằng hệ thống xây dựng biết rõ tất cả các tệp.
Ví dụ
Để tạo một filegroup
bao gồm hai tệp nguồn, hãy thực hiện
filegroup( name = "mygroup", srcs = [ "a_file.txt", "some/subdirectory/another_file.txt", ], )
Hoặc sử dụng glob
để đi kèm thư mục dữ liệu kiểm thử:
filegroup( name = "exported_testdata", srcs = glob([ "testdata/*.dat", "testdata/logs/**/*.log", ]), )
Để sử dụng các định nghĩa này, hãy tham chiếu đến filegroup
bằng một nhãn từ bất kỳ quy tắc nào:
cc_library( name = "my_library", srcs = ["foo.cc"], data = [ "//my_package:exported_testdata", "//my_package:mygroup", ], )
Đối số
Thuộc tính | |
---|---|
name |
Tên duy nhất cho mục tiêu này. |
srcs
|
Thông thường, bạn nên dùng kết quả của biểu thức glob cho giá trị của thuộc tính |
data
|
Các mục tiêu có tên trong thuộc tính |
output_group
|
"Nhóm đầu ra" là một danh mục các cấu phần phần mềm đầu ra của một mục tiêu, được xác định trong cách triển khai quy tắc đó. |
truy vấn tạo thế
Xem nguồn quy tắcgenquery(name, deps, data, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, expression, features, licenses, opts, restricted_to, scope, strict, tags, target_compatible_with, testonly, visibility)
genquery()
chạy một truy vấn được chỉ định bằng Ngôn ngữ truy vấn linh hoạt và kết quả được chuyển thành một tệp.
Để đảm bảo bản dựng nhất quán, truy vấn chỉ được phép truy cập vào việc đóng tạm thời của các mục tiêu được chỉ định trong thuộc tính scope
. Các truy vấn vi phạm quy tắc này sẽ không thực hiện được trong quá trình thực thi nếu strict
không được chỉ định hoặc đúng (nếu strict
sai, các mục tiêu nằm ngoài phạm vi sẽ chỉ bị bỏ qua kèm theo cảnh báo). Cách dễ nhất để đảm bảo việc này không xảy ra là đề cập đến cùng một nhãn trong phạm vi như trong biểu thức truy vấn.
Điểm khác biệt duy nhất giữa các truy vấn được phép ở đây và trên dòng lệnh
là không được phép chứa các truy vấn chứa thông số mục tiêu ký tự đại diện (ví dụ:
//pkg:*
hoặc //pkg:all
).
Lý do có hai phần tử: thứ nhất, vì genquery
phải chỉ định phạm vi để ngăn các mục tiêu bên ngoài việc đóng truy vấn chuyển tiếp nhằm tác động đến đầu ra của truy vấn; và thứ hai, vì các tệp BUILD
không hỗ trợ các phần phụ thuộc ký tự đại diện (ví dụ: deps=["//a/..."]
không được phép).
Đầu ra của truy vấn thế hệ mới được sắp xếp bằng cách sử dụng --order_output=full
để thực thi đầu ra xác định.
Tên của tệp đầu ra là tên của quy tắc.
Ví dụ
Ví dụ này sẽ viết danh sách các nhãn trong phần đóng cửa bắc cầu của mục tiêu được chỉ định vào một tệp.
genquery( name = "kiwi-deps", expression = "deps(//kiwi:kiwi_lib)", scope = ["//kiwi:kiwi_lib"], )
Đối số
Thuộc tính | |
---|---|
name |
Tên duy nhất cho mục tiêu này. |
expression
|
:b trong thuộc tính này trong tệp a/BUILD sẽ tham chiếu đến //:b mục tiêu.
|
opts
|
bazel query . Một số tùy chọn truy vấn không được phép
ở đây: --keep_going , --query_file , --universe_scope ,
--order_results và --order_output . Các tùy chọn không được chỉ định ở đây
sẽ có các giá trị mặc định giống như trên dòng lệnh của bazel query .
|
scope
|
|
strict
|
|
tạo quy tắc
Xem nguồn quy tắcgenrule(name, srcs, outs, cmd, cmd_bash, cmd_bat, cmd_ps, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, exec_tools, executable, features, licenses, local, message, output_licenses, output_to_bindir, restricted_to, tags, target_compatible_with, testonly, toolchains, tools, visibility)
genrule
tạo một hoặc nhiều tệp bằng lệnh Bash do người dùng xác định.
Genrules là các quy tắc tạo bản dựng chung mà bạn có thể sử dụng nếu không có quy tắc cụ thể cho tác vụ.
Ví dụ: bạn có thể chạy một dòng giới thiệu Bash. Tuy nhiên, nếu bạn cần biên dịch tệp C++, hãy tuân thủ các quy tắc cc_*
hiện có, vì bạn đã thực hiện tất cả những công việc khó khăn.
Lưu ý rằng genrule yêu cầu một shell để diễn giải đối số lệnh. Bạn cũng có thể dễ dàng tham chiếu các chương trình tuỳ ý có sẵn trên PATH, tuy nhiên, điều này khiến lệnh không có tính khép kín và có thể không tái tạo được. Nếu bạn chỉ cần chạy một công cụ duy nhất, hãy cân nhắc sử dụng run_binary.
Không sử dụng quy tắc tạo gen để chạy kiểm thử. Có các chính sách đặc biệt cho quá trình kiểm thử và kết quả kiểm thử, bao gồm cả chính sách về bộ nhớ đệm và các biến môi trường. Các thử nghiệm thường cần được chạy
sau khi bản dựng hoàn tất và trên cấu trúc mục tiêu, trong khi các quy tắc tạo gen được thực thi trong
bản dựng và trên cấu trúc thực thi (hai có thể khác nhau). Nếu bạn cần một quy tắc kiểm thử đa năng, hãy sử dụng sh_test
.
Những điểm cần cân nhắc khi biên dịch chéo
Xem hướng dẫn sử dụng để biết thêm thông tin về tính năng biên dịch chéo.
Mặc dù quy tắc tạo gen chạy trong quá trình tạo bản dựng, nhưng kết quả của chúng thường được sử dụng sau bản dựng để triển khai hoặc thử nghiệm. Hãy xem xét ví dụ về việc biên dịch mã C cho một bộ vi điều khiển: trình biên dịch chấp nhận các tệp nguồn C và tạo mã chạy trên bộ vi điều khiển. Mã được tạo rõ ràng là không thể chạy trên CPU dùng để xây dựng mã, nhưng bản thân trình biên dịch C (nếu được biên dịch từ nguồn) thì phải làm như vậy.
Hệ thống xây dựng sử dụng cấu hình thực thi để mô tả(các) máy mà bản dựng sẽ chạy và cấu hình mục tiêu để mô tả(các) máy mà đầu ra của bản dựng sẽ được chạy trên đó. Công cụ này cung cấp các tuỳ chọn để định cấu hình từng thư mục và tách riêng các tệp tương ứng thành các thư mục riêng biệt để tránh xung đột.
Đối với các quy tắc tạo hệ thống, hệ thống xây dựng đảm bảo rằng các phần phụ thuộc được xây dựng một cách phù hợp:
srcs
được xây dựng (nếu cần) cho cấu hình target,
tools
được xây dựng cho cấu hình exec và kết quả được coi là
dành cho cấu hình target. Nó cũng cung cấp
các biến "Make" mà các lệnh genrule có thể chuyển đến các công cụ tương ứng.
Mục đích là để genrule không xác định thuộc tính deps
: các quy tắc tích hợp khác sử dụng thông tin meta phụ thuộc vào ngôn ngữ được truyền giữa các quy tắc để tự động xác định cách xử lý các quy tắc phụ thuộc, nhưng mức độ tự động hoá này không thể áp dụng cho các quy tắc tạo gen. Genrules chỉ hoạt động
ở cấp độ tệp và runfiles.
Các trường hợp đặc biệt
Biên dịch thực thi: trong một số trường hợp, hệ thống xây dựng cần chạy quy tắc tạo sao cho kết quả cũng có thể được thực thi trong quá trình tạo. Ví dụ: nếu một genrule xây dựng một số trình biên dịch tuỳ chỉnh mà sau đó được một genrule khác sử dụng, thì trình biên dịch đầu tiên phải tạo ra kết quả cho cấu hình thực thi vì đó là nơi trình biên dịch sẽ chạy trong genrule khác. Trong trường hợp này, hệ thống xây dựng sẽ tự động thực hiện đúng việc: hệ thống sẽ tạo srcs
và outs
của quy tắc tạo gen đầu tiên cho cấu hình thực thi thay vì cấu hình mục tiêu. Hãy xem hướng dẫn sử dụng để biết thêm thông tin.
Công cụ JDK và C++: để sử dụng một công cụ trong trình biên dịch JDK hoặc C++, hệ thống xây dựng cung cấp một tập hợp các biến để sử dụng. Hãy xem biến"Tạo" để biết thông tin chi tiết.
Môi trường Gengen
Lệnh genrule được thực thi bởi một vỏ Bash được định cấu hình để không thực hiện được khi lệnh
hoặc một quy trình không thành công, bằng cách sử dụng set -e -o pipefail
.
Công cụ xây dựng sẽ thực thi lệnh Bash trong môi trường quy trình được dọn dẹp, chỉ xác định các biến cốt lõi như PATH
, PWD
, TMPDIR
và một số biến khác.
Để đảm bảo các bản dựng có thể tái tạo, hầu hết các biến được xác định trong môi trường shell của người dùng sẽ không được chuyển qua lệnh của genrule. Tuy nhiên, Bazel (nhưng không phải Blaze) truyền giá trị biến môi trường PATH
của người dùng.
Mọi thay đổi đối với giá trị của PATH
sẽ khiến Bazel thực thi lại lệnh trên bản dựng tiếp theo.
Lệnh genrule không được truy cập vào mạng ngoại trừ việc kết nối các quy trình là phần tử con của lệnh đó, mặc dù thao tác này hiện không được thực thi.
Hệ thống xây dựng tự động xoá mọi tệp đầu ra hiện có, nhưng tạo mọi thư mục mẹ cần thiết trước khi chạy quy tắc tạo gen. Thao tác này cũng xoá mọi tệp đầu ra trong trường hợp xảy ra lỗi.
Lời khuyên chung
- Đảm bảo rằng các công cụ chạy bằng quy tắc gen mang tính quyết định và khép kín. Họ không nên viết dấu thời gian vào kết quả của mình và nên sử dụng thứ tự ổn định cho các tập hợp và bản đồ, cũng như chỉ viết các đường dẫn tệp tương đối đến đầu ra, không phải đường dẫn tuyệt đối. Việc không tuân theo quy tắc này sẽ dẫn đến hành vi xây dựng không mong muốn (Bazel không tạo lại quy tắc mà bạn nghĩ là sẽ có) và làm giảm hiệu suất bộ nhớ đệm.
- Sử dụng
$(location)
một cách rộng rãi cho các kết quả, công cụ và nguồn. Do sự phân tách của các tệp đầu ra cho các cấu hình khác nhau, các quy tắc tạo gen không thể dựa vào đường dẫn tuyệt đối được mã hoá cứng và/hoặc tuyệt đối. - Viết một macro Starlark phổ biến trong trường hợp các quy tắc tạo giống nhau hoặc rất giống nhau được sử dụng ở nhiều nơi. Nếu quy tắc chung phức tạp, hãy cân nhắc triển khai quy tắc này trong một tập lệnh hoặc dưới dạng quy tắc Starlark. Điều này giúp cải thiện khả năng đọc cũng như khả năng kiểm tra.
- Đảm bảo rằng mã thoát chỉ ra chính xác thành công hoặc không thành công của quy tắc tạo gen.
- Không viết thông báo thông tin cho stdout hoặc stderr. Mặc dù hữu ích khi gỡ lỗi, nhưng cách làm này có thể dễ dàng trở thành tiếng ồn; một quy tắc tạo thành công sẽ im lặng. Mặt khác, quy tắc tạo gen không thành công sẽ tạo ra thông báo lỗi tốt.
$$
evaluates to a$
, a literal dollar-sign, so in order to invoke a shell command containing dollar-signs such asls $(dirname $x)
, one must escape it thus:ls $$(dirname $$x)
.- Tránh tạo các đường liên kết tượng trưng và thư mục. Bazel không sao chép cấu trúc thư mục/đường liên kết tượng trưng do genrules tạo ra và việc kiểm tra phần phụ thuộc của các thư mục sẽ không có âm thanh.
- Khi tham chiếu genrule trong các quy tắc khác, bạn có thể sử dụng nhãn của genrule hoặc nhãn của từng tệp đầu ra. Đôi khi, một phương pháp dễ đọc hơn, đôi khi phương thức khác: tham chiếu kết quả theo tên trong
srcs
của quy tắc tiêu thụ sẽ tránh việc vô tình chọn các kết quả khác của quy tắc chung, nhưng có thể tẻ nhạt nếu quy tắc đó tạo ra nhiều kết quả đầu ra.
Ví dụ
Ví dụ này sẽ tạo ra foo.h
. Không có nguồn nào vì lệnh này không lấy bất kỳ dữ liệu đầu vào nào. " nhị phân" do lệnh chạy là một tập lệnh perl trong cùng một gói với genrule.
genrule( name = "foo", srcs = [], outs = ["foo.h"], cmd = "./$(location create_foo.pl) > \"$@\"", tools = ["create_foo.pl"], )
Ví dụ sau đây cho biết cách sử dụng filegroup
và kết quả của một genrule
khác. Xin lưu ý rằng việc sử dụng $(SRCS)
thay vì
các lệnh $(location)
rõ ràng cũng sẽ hoạt động; ví dụ này sử dụng nội dung sau để
minh họa.
genrule( name = "concat_all_files", srcs = [ "//some:files", # a filegroup with multiple files in it ==> $(locations) "//other:gen", # a genrule with a single output ==> $(location) ], outs = ["concatenated.txt"], cmd = "cat $(locations //some:files) $(location //other:gen) > $@", )
Đối số
Thuộc tính | |
---|---|
name |
Tên duy nhất cho mục tiêu này. Bạn có thể tham khảo quy tắc này theo tên trong phần srcs hoặc deps của các quy tắc BUILD khác. Nếu quy tắc tạo các tệp nguồn, bạn nên sử dụng thuộc tính srcs .
|
srcs
|
Thuộc tính này không phù hợp để liệt kê các công cụ do
Hệ thống xây dựng đảm bảo những điều kiện tiên quyết này được xây dựng trước khi chạy lệnh genrule; chúng được xây dựng bằng cùng cấu hình với yêu cầu bản dựng ban đầu. Tên của các tệp trong những điều kiện tiên quyết này có sẵn cho lệnh dưới dạng danh sách được phân tách bằng dấu cách trong |
outs
|
Tệp đầu ra không được vượt quá ranh giới của gói. Tên tệp đầu ra được hiểu là tương đối so với gói.
Nếu bạn đặt cờ
Lệnh genrule dự kiến sẽ tạo từng tệp đầu ra tại một vị trí định trước.
Vị trí có sẵn trong |
cmd
|
$(location)
và thay đổi biến"Make".
cmd_bash , cmd_ps và cmd_bat , nếu không có API nào phù hợp.
Nếu độ dài dòng lệnh vượt quá giới hạn nền tảng (64K trên Linux/macOS, 8K trên Windows),
thì genrule sẽ ghi lệnh này vào một tập lệnh và thực thi tập lệnh đó. Cách này áp dụng cho mọi thuộc tính Cmd ( |
cmd_bash
|
Thuộc tính này có mức độ ưu tiên cao hơn |
cmd_bat
|
Thuộc tính này có mức độ ưu tiên cao hơn
|
cmd_ps
|
Thuộc tính này có mức độ ưu tiên cao hơn
Để giúp Powershell dễ sử dụng hơn và ít xảy ra lỗi hơn, chúng tôi chạy các lệnh sau để thiết lập môi trường trước khi thực thi lệnh Powershell trong genrule.
|
exec_tools
|
tools .
Trong một khoảng thời gian, |
executable
|
Việc đặt cờ này thành Đúng có nghĩa là đầu ra là một tệp thực thi và có thể chạy bằng lệnh
Không hỗ trợ khai báo các phần phụ thuộc dữ liệu cho tệp thực thi đã tạo. |
local
|
Nếu bạn đặt chính sách này thành Đúng, thì tùy chọn này sẽ buộc
Điều này tương đương với việc cung cấp "local" dưới dạng thẻ ( |
message
|
Một thông báo tiến trình sẽ được in khi bước xây dựng này được thực thi. Theo mặc định, thông báo sẽ là "Đang tạo đầu ra" (hoặc nội dung nào đó tương tự nhau), nhưng bạn có thể cung cấp thông báo cụ thể hơn. Hãy sử dụng thuộc tính này thay vì |
output_licenses
|
common attributes
|
output_to_bindir
|
Nếu bạn đặt chính sách này thành Đúng, tuỳ chọn này sẽ ghi các tệp đầu ra vào thư mục |
tools
|
Hệ thống xây dựng đảm bảo những điều kiện tiên quyết này được xây dựng trước khi chạy lệnh genrule;
chúng được xây dựng bằng cách sử dụng exec
cấu hình, vì các công cụ này được thực thi như một phần của bản dựng. Bạn có thể lấy đường dẫn của một mục tiêu
Bất kỳ |
bộ_thử_nghiệm
Xem nguồn quy tắctest_suite(name, compatible_with, deprecation, distribs, features, licenses, restricted_to, tags, target_compatible_with, testonly, tests, visibility)
test_suite
xác định một tập hợp kiểm thử được coi là "hữu ích" với con người. Điều này cho phép các dự án xác định các tập hợp kiểm thử, chẳng hạn như "kiểm thử mà bạn phải chạy trước khi kiểm tra", "kiểm thử căng thẳng trong dự án" hoặc "tất cả kiểm thử nhỏ". Lệnh blaze test
tuân theo loại tổ chức này: Đối với lệnh gọi như blaze test //some/test:suite
, trước tiên, Blaze liệt kê tất cả mục tiêu kiểm thử được đưa vào mục tiêu //some/test:suite
(chúng tôi gọi đây là "mở rộng test_ suite"), sau đó Blaze xây dựng và kiểm thử các mục tiêu đó.
Ví dụ
Một bộ kiểm thử chạy tất cả các kiểm thử nhỏ trong gói hiện tại.
test_suite( name = "small_tests", tags = ["small"], )
Bộ kiểm thử chạy một tập hợp kiểm thử cụ thể:
test_suite( name = "smoke_tests", tests = [ "system_unittest", "public_api_unittest", ], )
Một bộ kiểm thử chạy tất cả các kiểm thử trong gói hiện tại không ổn định.
test_suite( name = "non_flaky_test", tags = ["-flaky"], )
Đối số
Thuộc tính | |
---|---|
name |
Tên duy nhất cho mục tiêu này. |
tags
|
Thẻ bắt đầu bằng ký tự "-" được coi là thẻ phủ định. Ký tự "-" trước đó không được coi là một phần của thẻ, vì vậy, thẻ bộ "-small" khớp với kích thước "nhỏ" của thử nghiệm. Tất cả các thẻ khác được coi là thẻ dương. Nếu muốn làm cho các thẻ tích cực trở nên rõ ràng hơn, thì thẻ cũng có thể bắt đầu bằng ký tự "+", ký tự này sẽ không được đánh giá trong văn bản của thẻ. Hệ thống này chỉ đơn giản là dễ đọc sự khác biệt tích cực và tiêu cực. Chỉ những quy tắc kiểm thử khớp với tất cả thẻ khẳng định và không có thẻ tiêu cực nào mới được đưa vào bộ kiểm thử. Xin lưu ý rằng điều này không có nghĩa là việc bỏ qua quá trình kiểm tra lỗi đối với các phần phụ thuộc trên các kiểm thử bị lọc bỏ sẽ phụ thuộc vào các kiểm thử bị bỏ qua vẫn cần phải hợp pháp (ví dụ: không bị các quy tắc ràng buộc hiển thị).
Từ khoá thẻ
Lưu ý rằng
Nếu cần một |
tests
|
Mọi
Nếu thuộc tính |