नियम
उपनाम
नियम का सोर्स देखेंalias(name, actual, compatible_with, deprecation, features, restricted_to, tags, target_compatible_with, testonly, visibility)
alias
नियम एक और नाम बनाता है, जिसे नियम कहा जा सकता है.
एलियासिंग सिर्फ़ "सामान्य" के लिए काम करता है टारगेट के लिए. खास तौर पर, package_group
और test_suite
को एलियास नहीं किया जा सकता.
एलियाज़िंग से जगह बनाने में आसानी हो सकती है, जहां टारगेट का नाम बदलने के लिए बहुत सारी फ़ाइलों में बदलाव करता है. आप किसी शब्द को स्टोर करने के लिए select फ़ंक्शन कॉल करें अगर आपको टारगेट के लिए.
अन्य नियम के तहत, 'किसको दिखे' सेटिंग का अपना एलान होता है. अन्य सभी मामलों में, यह जैसा कि इस नियम में बताया गया है (उदाहरण के लिए, उपनाम पर सिर्फ़ टेस्ट को नज़रअंदाज़ किया जाता है, सिर्फ़ testonly-ness को के बजाय कुछ छोटे अपवादों के साथ) का उपयोग किया जाता है:
-
अगर कमांड लाइन में उपनाम का इस्तेमाल किया जाता है, तो जांच नहीं की जाती हैं. उपनाम तय करने के लिए
जो रेफ़रेंस टेस्ट करता है,
test_suite
का इस्तेमाल करें नियम, जिसकेtests
में एक ही टारगेट हो एट्रिब्यूट की वैल्यू सबमिट करें. -
एनवायरमेंट ग्रुप तय करते समय,
environment
नियमों के लिए उपनाम नहीं होते हैं समर्थित हैं. ये--target_environment
कमांड लाइन में काम नहीं करते विकल्प भी है.
उदाहरण
filegroup( name = "data", srcs = ["data.txt"], ) alias( name = "other", actual = ":data", )
तर्क
विशेषताएं | |
---|---|
name |
नाम; आवश्यक इस टारगेट के लिए यूनीक नाम. |
actual
|
लेबल; आवश्यक वह टारगेट जिससे यह उपनाम दिखाता है. इसके लिए कोई नियम होना ज़रूरी नहीं है. यह एक इनपुट भी हो सकता है फ़ाइल से लिए जाते हैं. |
config_setting
नियम का सोर्स देखेंconfig_setting(name, constraint_values, define_values, deprecation, distribs, features, flag_values, licenses, tags, testonly, values, visibility)
के लिए अनुमानित कॉन्फ़िगरेशन स्थिति (बिल्ड फ़्लैग या प्लैटफ़ॉर्म कंस्ट्रेंट के रूप में बताई गई) से मेल खाती है कॉन्फ़िगर करने लायक एट्रिब्यूट को ट्रिगर करने के मकसद से बनाया गया है. इसके लिए चुनें पर जाएं इस नियम को कैसे इस्तेमाल करें और सामान्य सुविधा की खास जानकारी के लिए कॉन्फ़िगर किए जा सकने वाले एट्रिब्यूट.
उदाहरण
ये ऐसे किसी भी बिल्ड से मेल खाते हैं जो --compilation_mode=opt
या
-c opt
(या तो साफ़ तौर पर कमांड लाइन पर या सीधे तौर पर .baZZrc फ़ाइलों से):
config_setting( name = "simple", values = {"compilation_mode": "opt"} )
नीचे दिए गए उदाहरण ऐसे किसी भी बिल्ड से मेल खाते हैं जो ARM को टारगेट करता है और कस्टम डेफ़िनिशन को लागू करता है
FOO=bar
(उदाहरण के लिए, bazel build --cpu=arm --define FOO=bar ...
):
config_setting( name = "two_conditions", values = { "cpu": "arm", "define": "FOO=bar" } )
नीचे दी गई चीज़ें ऐसे किसी भी बिल्ड से मेल खाती हैं जो सेट की जाती है
उपयोगकर्ता के हिसाब से तय किया गया फ़्लैग
--//custom_flags:foo=1
(या तो साफ़ तौर पर कमांड लाइन पर या सीधे तौर पर
.bagelrc फ़ाइलें):
config_setting( name = "my_custom_flag_is_set", flag_values = { "//custom_flags:foo": "1" }, )
नीचे दिए गए उदाहरण ऐसे किसी भी बिल्ड से मेल खाते हैं जो x86_64 आर्किटेक्चर और glibc वाले प्लैटफ़ॉर्म को टारगेट करता है
यह मानते हुए कि लेबल के साथ constraint_value
मौजूद है, वर्शन 2.25
//example:glibc_2_25
. ध्यान दें कि अगर कोई प्लैटफ़ॉर्म एक से ज़्यादा कीवर्ड को परिभाषित करता है, तो
वैल्यू को इन दोनों से ज़्यादा रखें.
config_setting( name = "64bit_glibc_2_25", constraint_values = [ "@platforms//cpu:x86_64", "//example:glibc_2_25", ] )अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है इन सभी मामलों में, बिल्ड के अंदर कॉन्फ़िगरेशन में बदलाव हो सकता है. उदाहरण के लिए, टारगेट को उसके डिपार्टमेंट के अलावा किसी दूसरे प्लैटफ़ॉर्म के लिए बनाया जाना चाहिए. इसका मतलब है कि भले ही
config_setting
का मिलान टॉप-लेवल के कमांड लाइन फ़्लैग से नहीं होता है. हालांकि, यह अब भी मेल खा सकता है
कुछ बिल्ड टारगेट.
नोट
- एक से ज़्यादा विज्ञापन जोड़ने पर क्या होगा, यह जानने के लिए चुनें पर जाएं
config_setting
का कॉन्फ़िगरेशन, कॉन्फ़िगरेशन की मौजूदा स्थिति से होता है. - उन फ़्लैग के लिए जिनमें शॉर्टहैंड फ़ॉर्म काम करते हैं (जैसे कि
--compilation_mode
बनाम-c
),values
परिभाषाओं में फ़ुल फ़ॉर्म का इस्तेमाल किया जाना चाहिए. ये अपने-आप दोनों में से किसी भी फ़ॉर्म का इस्तेमाल करके, बोले जाने वाले वाक्यों का मिलान करना होगा. -
अगर किसी फ़्लैग में एक से ज़्यादा वैल्यू (जैसे,
--copt=-Da --copt=-Db
या सूची का टाइप) इस्तेमाल की जाती हैं Starlark फ़्लैग),values = { "flag": "a" }
मेल खाता है, अगर"a"
हो असली सूची में कहीं भी मौजूद रहेगा.values = { "myflag": "a,b" }
इसी तरह से काम करता है: यह--myflag=a --myflag=b
,--myflag=a --myflag=b --myflag=c
,--myflag=a,b
और--myflag=c,b,a
. सटीक सिमैंटिक अलग-अलग होते हैं फ़्लैग. उदाहरण के लिए,--copt
फ़ंक्शन में एक से ज़्यादा वैल्यू को इस्तेमाल नहीं किया जा सकता उदाहरण:--copt=a,b
,["a,b"]
देता है, जबकि--copt=a --copt=b
,["a", "b"]
देता है (इसलिएvalues = { "copt": "a,b" }
), पूर्व से मेल खाता है, लेकिन बाद वाले से नहीं). लेकिन--ios_multi_cpus
(Apple के नियमों के लिए) ऐसा करता है:-ios_multi_cpus=a,b
औरios_multi_cpus=a --ios_multi_cpus=b
दोनों["a", "b"]
का उत्पादन करते हैं. फ़्लैग की परिभाषाएं देखें और सटीक अनुमान लगाने के लिए, शर्तों को ध्यान से देखें. - अगर आपको ऐसी स्थितियां तय करनी हैं जिन्हें बिल्ट-इन बिल्ड फ़्लैग से मॉडल नहीं किया गया है, तो
स्टारलार्क के बनाए हुए झंडे.
--define
का भी इस्तेमाल किया जा सकता है, लेकिन इससे कम ऑफ़र मिलते हैं सहायता ली जाती है और इसका सुझाव नहीं दिया जाता. यहां जाएं: ज़्यादा चर्चा के लिए यहां जाएं. - अलग-अलग पैकेज में, एक जैसी
config_setting
परिभाषाएं दोहराने से बचें. इसके बजाय, कैननिकल पैकेज में बताए गए सामान्यconfig_setting
का रेफ़रंस दें. values
define_values
, औरconstraint_values
एक हीconfig_setting
में किसी भी कॉम्बिनेशन में इस्तेमाल किया जा सकता है, लेकिन कम से कम एक का इस्तेमाल करना ज़रूरी है किसी भी दिए गएconfig_setting
के लिए सेट हो.
तर्क
विशेषताएं | |
---|---|
name |
नाम; आवश्यक इस टारगेट के लिए यूनीक नाम. |
constraint_values
|
लेबल की सूची; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट रूप से constraint_values का कम से कम सेट, जिसे टारगेट प्लैटफ़ॉर्म को तय करना ज़रूरी है
ताकि इस config_setting से मेल खा सके. (निष्पादक प्लैटफ़ॉर्म
माना जाता है.) प्लैटफ़ॉर्म ने जिन अतिरिक्त कंस्ट्रेंट वैल्यू को शामिल नहीं किया है उन्हें अनदेखा कर दिया जाता है. यहां जाएं:
ज़्यादा जानकारी के लिए, कॉन्फ़िगर किए जा सकने वाले बिल्ड एट्रिब्यूट.
जब दो |
define_values
|
शब्दकोश: स्ट्रिंग -> String; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट रूप से values की तरह है, लेकिन
खास तौर पर, --define फ़्लैग के लिए.
इसका मतलब है कि: config_setting( name = "a_and_b", values = { "define": "a=1", "define": "b=2", })अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है काम नहीं करता क्योंकि एक ही कुंजी ( config_setting( name = "a_and_b", define_values = { "a": "1", "b": "2", })अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है
|
flag_values
|
शब्दकोश: label -> String; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट रूप से values की तरह है, लेकिन
के लिए
उपयोगकर्ता के तय किए गए बिल्ड फ़्लैग शामिल किए जाएंगे.
यह एक अलग एट्रिब्यूट है, क्योंकि उपयोगकर्ता के तय किए हुए फ़्लैग, लेबल के तौर पर रेफ़र किए जाते हैं बिल्ट-इन फ़्लैग को आर्बिट्रेरी स्ट्रिंग के तौर पर बताया जाता है. |
values
|
शब्दकोश: स्ट्रिंग -> String; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट रूप से यह नियम, कॉन्फ़िगर किए गए उस टारगेट के कॉन्फ़िगरेशन को इनहेरिट करता है जो
इसका रेफ़रंस सुविधा के लिए, कॉन्फ़िगरेशन वैल्यू को बिल्ड फ़्लैग के तौर पर दिखाया जाता है. इनके बिना
पिछले अगर कमांड लाइन पर फ़्लैग साफ़ तौर पर सेट नहीं किया गया है, तो इसके डिफ़ॉल्ट मान का इस्तेमाल किया जाता है.
अगर डिक्शनरी में कोई कुंजी एक से ज़्यादा बार दिखती है, तो सिर्फ़ आखिरी इंस्टेंस का इस्तेमाल किया जाता है.
अगर कुंजी किसी ऐसे फ़्लैग का संदर्भ देती है जिसे कमांड लाइन पर कई बार सेट किया जा सकता है (जैसे,
|
फ़ाइलग्रुप
नियम का सोर्स देखेंfilegroup(name, srcs, data, compatible_with, deprecation, distribs, features, licenses, output_group, restricted_to, tags, target_compatible_with, testonly, visibility)
टारगेट के कलेक्शन को एक सुविधाजनक नाम देने के लिए, filegroup
का इस्तेमाल करें.
इसके बाद, इन नियमों का रेफ़रंस दूसरे नियमों में दिया जा सकता है.
सीधे डायरेक्ट्री का रेफ़रंस देने के बजाय, filegroup
का इस्तेमाल करने का सुझाव दिया जाता है.
बाद वाली क्वेरी ठीक नहीं होती, क्योंकि बिल्ड सिस्टम के पास सभी फ़ाइलों की पूरी जानकारी नहीं होती
ताकि इन फ़ाइलों के बदलने पर यह दोबारा न बने. इसके साथ जोड़ने पर
ग्लोब, filegroup
यह पक्का कर सकता है कि सभी फ़ाइलें
बिल्ड सिस्टम के लिए साफ़ तौर पर पता होता है.
उदाहरण
दो सोर्स फ़ाइलों वाला filegroup
बनाने के लिए, यह करें
filegroup( name = "mygroup", srcs = [ "a_file.txt", "some/subdirectory/another_file.txt", ], )
इसके अलावा, टेस्टडेटा डायरेक्ट्री बनाने के लिए, glob
का इस्तेमाल करें:
filegroup( name = "exported_testdata", srcs = glob([ "testdata/*.dat", "testdata/logs/**/*.log", ]), )
इन परिभाषाओं का इस्तेमाल करने के लिए, किसी भी नियम के लेबल के साथ filegroup
रेफ़रंस दें:
cc_library( name = "my_library", srcs = ["foo.cc"], data = [ "//my_package:exported_testdata", "//my_package:mygroup", ], )
तर्क
विशेषताएं | |
---|---|
name |
नाम; आवश्यक इस टारगेट के लिए यूनीक नाम. |
srcs
|
लेबल की सूची; डिफ़ॉल्ट रूप से
किसी समस्या के लिए ग्लोब एक्सप्रेशन के नतीजे का इस्तेमाल करना आम बात है
|
data
|
लेबल की सूची; डिफ़ॉल्ट रूप से
|
output_group
|
String; "आउटपुट ग्रुप" टारगेट के आउटपुट आर्टफ़ैक्ट की एक कैटगरी है, जिसे नियम लागू करना. |
Genquery
नियम का सोर्स देखेंgenquery(name, deps, data, compatible_with, compressed_output, deprecation, distribs, exec_compatible_with, exec_properties, expression, features, licenses, opts, restricted_to, scope, strict, tags, target_compatible_with, testonly, visibility)
genquery()
इसमें बताई गई क्वेरी चलाता है
ब्लेज़ क्वेरी की भाषा और नतीजे को डंप करता है
.
बिल्ड को एक जैसा बनाए रखने के लिए, क्वेरी को सिर्फ़
scope
में बताए गए लक्ष्यों का अस्थायी तौर पर बंद होना
एट्रिब्यूट की वैल्यू सबमिट करें. लागू होने के दौरान, इस नियम का उल्लंघन करने वाली क्वेरी फ़ेल हो जाएंगी, अगर
strict
एट्रिब्यूट की वैल्यू नहीं दी गई है या यह सही है (अगर strict
गलत है,
दायरे से बाहर के टारगेट को सिर्फ़ चेतावनी के साथ छोड़ दिया जाएगा). कॉन्टेंट बनाने
ऐसा न हो, यह पक्का करने का सबसे आसान तरीका है कि एक जैसे लेबल बताएं
के स्कोप में दिखेगा.
यहां और कमांड के तौर पर इस्तेमाल की जा सकने वाली क्वेरी के बीच सिर्फ़ एक अंतर है
लाइन से वाइल्डकार्ड टारगेट की खास जानकारी वाली क्वेरी (जैसे कि
//pkg:*
या //pkg:all
) की अनुमति नहीं है.
इसकी दो वजहें हैं: पहली, क्योंकि genquery
में
के अस्थायी बंद होने के दायरे से बाहर के टारगेट को रोकने के लिए,
अपने आउटपुट पर असर डालने के लिए क्वेरी; और दूसरा, क्योंकि BUILD
फ़ाइलों में
वाइल्डकार्ड डिपेंडेंसी के साथ काम नहीं करता (जैसे, deps=["//a/..."]
अनुमति नहीं है).
डिटरमिनिस्टिक आउटपुट लागू करने के लिए, जेनक्वेरी के आउटपुट को लेक्सिकोग्राफ़िक रूप से व्यवस्थित किया जाता है,
अपवाद के साथ --output=graph|minrank|maxrank
या जब somepath
का इस्तेमाल टॉप-लेवल फ़ंक्शन के तौर पर किया जाता है.
आउटपुट फ़ाइल का नाम ही नियम का नाम होता है.
उदाहरण
यह उदाहरण, फ़ाइल के लिए निर्दिष्ट लक्ष्य.
genquery( name = "kiwi-deps", expression = "deps(//kiwi:kiwi_lib)", scope = ["//kiwi:kiwi_lib"], )
तर्क
विशेषताएं | |
---|---|
name |
नाम; आवश्यक इस टारगेट के लिए यूनीक नाम. |
compressed_output
|
बूलियन; True है, तो क्वेरी आउटपुट को GZIP फ़ाइल फ़ॉर्मैट में लिखा जाता है. इस सेटिंग का इस्तेमाल किया जा सकता है
का इस्तेमाल करें. बेज़ल
यह क्वेरी आउटपुट को 220 बाइट से ज़्यादा, अंदरूनी तौर पर कंप्रेस करता है, भले ही
इस सेटिंग का मान है, इसलिए इसे True पर सेट करने से
हीप. हालांकि, यह आउटपुट फ़ाइल लिखते समय Basel को डिकंप्रेशन करने से नहीं रोकता है,
इसमें ज़्यादा मेमोरी खर्च हो सकती है.
|
expression
|
String; आवश्यक एक्ज़ीक्यूट की जाने वाली क्वेरी. BUILD फ़ाइलों में कमांड लाइन और अन्य जगहों से उलट, यहां मौजूद लेबल का समाधान, फ़ाइल फ़ोल्डर की रूट डायरेक्ट्री के हिसाब से किया जाता है. उदाहरण के लिए,a/BUILD फ़ाइल में इस एट्रिब्यूट में मौजूद :b लेबल,
टारगेट //:b .
|
opts
|
स्ट्रिंग की सूची; bazel query को भेजा जा सकता है. क्वेरी के कुछ विकल्पों की अनुमति नहीं है
यहां: --keep_going , --query_file , --universe_scope ,
--order_results और --order_output . विकल्प यहां नहीं दिए गए हैं
इनके डिफ़ॉल्ट मान ठीक वैसे ही होंगे जैसे bazel query की कमांड लाइन पर होते हैं.
|
scope
|
लेबल की सूची; आवश्यक क्वेरी का स्कोप. क्वेरी को ट्रांज़िटिव से बाहर के टारगेट को छूने की अनुमति नहीं है इन लक्ष्यों को बंद करने में मदद करे. |
strict
|
बूलियन; |
सामान्य
नियम का सोर्स देखेंgenrule(name, srcs, outs, cmd, cmd_bash, cmd_bat, cmd_ps, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, executable, features, licenses, local, message, output_licenses, output_to_bindir, restricted_to, tags, target_compatible_with, testonly, toolchains, tools, visibility)
genrule
, उपयोगकर्ता के तय किए गए Bash निर्देश का इस्तेमाल करके, एक या उससे ज़्यादा फ़ाइलें जनरेट करता है.
जेन रूल, बिल्ड के सामान्य नियम होते हैं. किसी टास्क के लिए कोई खास नियम न होने पर, इन नियमों का इस्तेमाल किया जा सकता है.
उदाहरण के लिए, Bash वन-लाइनर चलाया जा सकता है. हालांकि, अगर आपको C++ फ़ाइलें इकट्ठा करनी हैं, तो
मौजूदा cc_*
नियमों के अनुसार, क्योंकि सभी लिफ़्टिंग पहले ही पूरी की जा चुकी हैं
आपके लिए.
ध्यान दें कि कमांड आर्ग्युमेंट की व्याख्या करने के लिए, जेनरल को एक शेल की ज़रूरत होती है. PATH पर उपलब्ध आर्बिट्रेरी प्रोग्राम का रेफ़रंस देना आसान है, हालांकि इससे कमांड नॉन-हर्मेटिक और हो सकता है कि दोबारा जनरेट न हो सके. अगर आपको सिर्फ़ एक टूल चलाना है, तो run_binary आज़माएं.
टेस्ट करने के लिए जेनरूल का इस्तेमाल न करें. टेस्ट और टेस्ट के लिए खास डिस्पेंसेशन हैं
नतीजे. इनमें कैशिंग नीतियां और एनवायरमेंट वैरिएबल भी शामिल हैं. आम तौर पर, टेस्ट को चलाना ज़रूरी होता है
बिल्ड पूरा होने के बाद और टारगेट आर्किटेक्चर पर, जबकि जेनरल को इस दौरान एक्ज़ीक्यूट किया जाता है
पर आधारित होता है (दोनों अलग-अलग हो सकते हैं). अगर आपको किसी सामान्य मकसद की ज़रूरत है
टेस्ट करने के लिए, sh_test
का इस्तेमाल करें.
क्रॉस-कंपाइलेशन के बारे में ध्यान देने वाली बातें
इस बारे में ज़्यादा जानकारी के लिए इस्तेमाल के लिए गाइड देखें क्रॉस-कंपाइलेशन.
जेनरूल बिल्ड के दौरान चलते हैं, लेकिन उनके आउटपुट का इस्तेमाल बिल्ड के बाद, डिप्लॉयमेंट या टेस्टिंग हो रही है. किसी माइक्रोकंट्रोलर के लिए C कोड कंपाइल करने के उदाहरण पर विचार करें: कंपाइलर C स्वीकार करता है सोर्स फ़ाइलें इस्तेमाल करता है और कोड जनरेट करता है, जो माइक्रोकंट्रोलर पर चलता है. साफ़ तौर पर जनरेट किया गया कोड उस सीपीयू पर नहीं चलाया जा सकता जिसका इस्तेमाल इसे बनाने के लिए किया गया था, लेकिन सी कंपाइलर (अगर सोर्स से कंपाइल किया गया हो) ऐसा भी हो सकता है.
बिल्ड सिस्टम, उन मशीन(मशीनों) का ब्यौरा देने के लिए एक्ज़िक कॉन्फ़िगरेशन का इस्तेमाल करता है जिन पर बिल्ड चलता है और उन मशीन(मशीनों) का वर्णन करने के लिए लक्ष्य कॉन्फ़िगरेशन, जिन पर बिल्ड का आउटपुट है चलना चाहिए. यह इनमें से हर एक को कॉन्फ़िगर करने का विकल्प देता है और यह समस्याओं से बचने के लिए, एक-दूसरे से जुड़ी फ़ाइलों को अलग-अलग डायरेक्ट्री में स्टोर करें.
जेनरूल के लिए, बिल्ड सिस्टम यह पक्का करता है कि डिपेंडेंसी सही तरीके से बनाई गई हैं:
srcs
को target कॉन्फ़िगरेशन के लिए बनाया गया है (अगर ज़रूरी हो),
tools
को exec कॉन्फ़िगरेशन के लिए बनाया गया है और आउटपुट
टारगेट कॉन्फ़िगरेशन के लिए सेट होनी चाहिए. यह
"बनाएं" वाले वैरिएबल जनरेट करने के निर्देश से जुड़े टूल तक भेजे जा सकते हैं.
यह जान-बूझकर बनाया गया है कि जेन रूल किसी deps
एट्रिब्यूट के बारे में नहीं बताता: पहले से मौजूद अन्य नियम
नियमों के बीच पास की गई, भाषा पर आधारित मेटा जानकारी अपने-आप तय करती है कि
डिपेंडेंट नियमों को हैंडल कर सकता है, लेकिन जेन रूल के लिए इस लेवल का ऑटोमेशन मुमकिन नहीं है. सामान्य नियम काम करते हैं
पूरी तरह से फ़ाइल और रनफ़ाइल लेवल पर.
खास मामले
एक्ज़िक-एक्ज़ेक्यूलेशन कंपाइलेशन: कुछ मामलों में, बिल्ड सिस्टम को ऐसे genनियमों को चलाने की ज़रूरत होती है जो
आउटपुट को बिल्ड के दौरान भी एक्ज़ीक्यूट किया जा सकता है. उदाहरण के लिए, अगर जेनरुल कुछ कस्टम कंपाइलर बनाता है
इसका इस्तेमाल बाद में किसी अन्य जेनरुल में किया जाता है. पहले वाले को
exec कॉन्फ़िगरेशन चलाते हैं, क्योंकि यही वह जगह है जहां कंपाइलर अन्य जेनरूल में चलेगा. इस मामले में,
बिल्ड सिस्टम अपने-आप सही काम करता है: यह srcs
को बनाता है और
टारगेट के बजाय, exec कॉन्फ़िगरेशन के लिए पहले जेन रूल का outs
कॉन्फ़िगरेशन. ज़्यादा जानकारी के लिए इस्तेमाल के लिए गाइड देखें
जानकारी.
JDK और C++ टूलिंग: JDK या C++ कंपाइलर सुइट से किसी टूल का इस्तेमाल करने के लिए, बिल्ड सिस्टम इस्तेमाल करने के लिए वैरिएबल का एक सेट उपलब्ध कराता है. "बनाएं" देखें वैरिएबल के लिए विवरण.
जेनरुल एनवायरमेंट
जेनरूल कमांड को ऐसे बैश शेल से चलाया जाता है जिसे किसी निर्देश की वजह से फ़ेल होने के लिए कॉन्फ़िगर किया जाता है
या set -e -o pipefail
का इस्तेमाल करके, पाइपलाइन काम नहीं करती है.
बिल्ड टूल, Bash कमांड को ऐसे सैनिटाइज़ प्रोसेस एनवायरमेंट में लागू करता है जो
सिर्फ़ कोर वैरिएबल के बारे में बताता है, जैसे कि PATH
, PWD
,
TMPDIR
, और कुछ अन्य.
यह पक्का करने के लिए कि बिल्ड फिर से बनाए जा सकें, उपयोगकर्ता के शेल में तय किए गए ज़्यादातर वैरिएबल
हालांकि, एनवायरमेंट को जेनरल के निर्देश पर पास नहीं किया जाता. हालांकि, बेज़ल (लेकिन
Blaze) उपयोगकर्ता के PATH
एनवायरमेंट वैरिएबल की वैल्यू पास करता है.
PATH
की वैल्यू में कोई भी बदलाव करने से, Basel का निर्देश फिर से लागू हो जाएगा
काफ़ी अहम है.
सामान्य निर्देश का इस्तेमाल करके, सिर्फ़ उन प्रोसेस को नेटवर्क ऐक्सेस किया जा सकता है जिन्हें के चाइल्ड से जुड़े हुए हैं, हालांकि यह अभी लागू नहीं किया गया है.
बिल्ड सिस्टम, मौजूदा आउटपुट फ़ाइलों को अपने-आप मिटा देता है. हालांकि, यह सभी ज़रूरी पैरंट फ़ाइलें बनाता है करने से पहले कुछ अलग करना होता है. गड़बड़ी होने पर, आउटपुट वाली सभी फ़ाइलें भी हटा दी जाएंगी.
सामान्य सलाह
- यह पक्का करें कि जेनरूल की मदद से चलने वाले टूल डिटरमिनिस्टिक और हर्मेटिक हों. इन्हें नहीं लिखना चाहिए टाइमस्टैंप बहुत अच्छे होते हैं. साथ ही, सेट और मैप के लिए उन्हें स्टेबल क्रम का इस्तेमाल करना चाहिए. आउटपुट के लिए सिर्फ़ मिलते-जुलते फ़ाइल पाथ लिखें, ऐब्सलूट पाथ को नहीं. इस नियम का पालन न करने पर इसकी वजह से उम्मीद के मुताबिक बिल्ड व्यवहार हो जाता है (बेज़ल उस सामान्य नियम को फिर से नहीं बना रहा है जिसके बारे में आपको लगता था) और कैश परफ़ॉर्मेंस में कमी.
- आउटपुट, टूल, और सोर्स के लिए,
$(location)
का ज़्यादा इस्तेमाल करें. इस वजह से अलग-अलग कॉन्फ़िगरेशन के लिए आउटपुट फ़ाइलों को अलग-अलग कैटगरी में रखें. जेन नियम, हार्ड कोड किए गए कोड का इस्तेमाल नहीं कर सकते और/या ऐब्सलूट पाथ का इस्तेमाल करें. - अगर समान या बहुत मिलते-जुलते जेन रूल इस्तेमाल किए गए हैं, तो एक सामान्य स्टारलार्क मैक्रो लिखें एक से ज़्यादा जगह पर. अगर जेनरुल जटिल है, तो इसे स्क्रिप्ट में या इस तरह लागू करें: स्टारलार्क नियम. इससे ऐप्लिकेशन को पढ़ना आसान होने के साथ-साथ, टेस्ट करने में आसानी होती है.
- पक्का करें कि एग्ज़िट कोड सही तरीके से यह दिखाता हो कि सामान्य नियम लागू हुआ या नहीं.
- stdout या stderr पर जानकारी देने वाले मैसेज न लिखें. यह डीबग करने के लिए फ़ायदेमंद है, लेकिन यह आसानी से शोर हो जाए; जनरेट किए गए सामान्य नियम के लिए, कोई कार्रवाई नहीं की जानी चाहिए. वहीं दूसरी ओर, जेनरल के काम न करने पर को गड़बड़ी के अच्छे मैसेज निकलने चाहिए.
$$
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)
.- सिमलिंक और डायरेक्ट्री बनाने से बचें. Baज़ल, डायरेक्ट्री/सिमलिंक पर कॉपी नहीं होता जेन रूल की मदद से बनाई गई संरचना और डायरेक्ट्री की डिपेंडेंसी की जांच करने वाली जानकारी ठीक नहीं है.
- अन्य नियमों में जेन रूल का रेफ़रंस देते समय, जेनरल के लेबल या
अलग-अलग आउटपुट फ़ाइलों के लेबल के साथ. कभी-कभी एक तरीका ज़्यादा पढ़ने लायक होता है, कभी-कभी
अन्य: इस्तेमाल करने वाले नियम की
srcs
में नाम से आउटपुट देने से बचें जेनरूल के दूसरे आउटपुट को अनजाने में चुनना कई आउटपुट देता है.
उदाहरण
इस उदाहरण से foo.h
जनरेट हुई है. कोई सोर्स उपलब्ध नहीं है, क्योंकि कमांड नहीं ली जाती
इनपुट दें. "बाइनरी" कमांड से रन करने पर, जेनुलेशन के पैकेज में पर्ल स्क्रिप्ट होती है.
genrule( name = "foo", srcs = [], outs = ["foo.h"], cmd = "./$(location create_foo.pl) > \"$@\"", tools = ["create_foo.pl"], )
नीचे दिए गए उदाहरण में, filegroup
का इस्तेमाल करने का तरीका बताया गया है
और एक और genrule
के आउटपुट पा सकते हैं. ध्यान दें कि इसके बजाय $(SRCS)
का इस्तेमाल किया जा रहा है
$(location)
डायरेक्टिव का सुझाव भी काम करेगा; इस उदाहरण में बाद वाले उदाहरण का इस्तेमाल
दिखाने के लिए किया जा सकता है.
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) > $@", )
तर्क
विशेषताएं | |
---|---|
name |
नाम; आवश्यक इस टारगेट के लिए यूनीक नाम. आप इस नियम को अन्य BUILD का srcs या deps सेक्शन
नियम. अगर यह नियम सोर्स फ़ाइलें जनरेट करता है, तो आपको
srcs एट्रिब्यूट की वैल्यू सबमिट करें.
|
srcs
|
लेबल की सूची; डिफ़ॉल्ट रूप से
यह एट्रिब्यूट, उन टूल की सूची बनाने के लिए सही नहीं है जिन्हें
बिल्ड सिस्टम यह पक्का करता है कि जेनरूल का इस्तेमाल करने से पहले, इन ज़रूरी शर्तों को पूरा किया जाए
निर्देश दें; इन्हें मूल बिल्ड अनुरोध वाले कॉन्फ़िगरेशन का ही इस्तेमाल करके बनाया जाता है. कॉन्टेंट बनाने
इन पूर्वापेक्षाओं की फ़ाइलों के नाम आदेश के लिए
|
outs
|
फ़ाइल नामों की सूची; कॉन्फ़िगर नहीं किया जा सकता; आवश्यक इस नियम के तहत जनरेट की गई फ़ाइलों की सूची.आउटपुट फ़ाइलों को पैकेज की सीमाएं पार नहीं करनी चाहिए. आउटपुट फ़ाइल नामों को पैकेज के हिसाब से समझा जाता है.
अगर
जेनरूल कमांड से हर आउटपुट फ़ाइल को पहले से तय जगह पर बनाया जाता है.
जन नियम के हिसाब से "बनाएं" का इस्तेमाल करके, |
cmd
|
String; $(location)
और "बनाएं" पर निर्भर करता है वैरिएबल की जगह बदलें.
cmd_bash , cmd_ps , और cmd_bat का फ़ॉलबैक है,
विकल्प मिलते हैं.
अगर कमांड लाइन की लंबाई, प्लैटफ़ॉर्म की सीमा से ज़्यादा है (Linux/macOS पर 64K, Windows पर 8K),
तो genral किसी स्क्रिप्ट में कमांड लिखेगा और उस स्क्रिप्ट को काम करने के लिए एक्ज़ीक्यूट करेगा. यह
सभी cmd एट्रिब्यूट ( |
cmd_bash
|
String; इस एट्रिब्यूट की प्राथमिकता |
cmd_bat
|
String; इस एट्रिब्यूट की प्राथमिकता
|
cmd_ps
|
String; इस एट्रिब्यूट की प्राथमिकता
PowerShell को इस्तेमाल करना आसान बनाने और गड़बड़ियों को कम करने के लिए, हम ये काम करते हैं: कमांड को भी सेट अप करने की ज़रूरत होती है.
|
executable
|
बूलियन; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट रूप से
इस फ़्लैग को 'सही' पर सेट करने का मतलब है कि आउटपुट एक एक्ज़ीक्यूटेबल फ़ाइल है और उसे
जनरेट की गई एक्ज़ीक्यूटेबल के लिए डेटा डिपेंडेंसी का एलान नहीं किया जा सकता. |
local
|
बूलियन;
अगर इस नीति को 'सही है' पर सेट किया जाता है, तो यह विकल्प इस
यह 'स्थानीय' वैल्यू देने के बराबर है टैग ( |
message
|
String;
बिल्ड का यह चरण पूरा होते ही, प्रोग्रेस का मैसेज प्रिंट किया जाएगा. डिफ़ॉल्ट रूप से,
मैसेज "आउटपुट जनरेट हो रहा है" है (या ऐसी ही कुछ अजीब चीज़ें) लेकिन आप हमारे
ज़्यादा सटीक है. |
output_licenses
|
लाइसेंस का टाइप; common attributes
देखें
|
output_to_bindir
|
बूलियन; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट रूप से
अगर इस विकल्प को 'सही है' पर सेट किया जाता है, तो इस विकल्प की वजह से आउटपुट फ़ाइलें |
tools
|
लेबल की सूची; डिफ़ॉल्ट रूप से
बिल्ड सिस्टम यह पक्का करता है कि gen बचाने के लिए निर्देश चलाने से पहले, इन ज़रूरी शर्तों को पूरा किया जाए;
इन्हें exec का इस्तेमाल करके बनाया जाता है
कॉन्फ़िगरेशन में बदलाव नहीं किया जा सकता, क्योंकि इन टूल को बिल्ड के हिस्से के तौर पर एक्ज़ीक्यूट किया जाता है. इसका पाथ
अलग-अलग
|
starlark_doc_extract
नियम का सोर्स देखेंstarlark_doc_extract(name, deps, src, data, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, licenses, render_main_repo_name, restricted_to, symbol_names, tags, target_compatible_with, testonly, visibility)
starlark_doc_extract()
नियमों और फ़ंक्शन (इनमें ये शामिल हैं) के लिए दस्तावेज़ एक्सट्रैक्ट करता है
मैक्रो), पहलुओं, और सेवा देने वाली कंपनियों को दिए गए .bzl
में तय या दोबारा एक्सपोर्ट किया गया हो या
.scl
फ़ाइल. इस नियम का आउटपुट एक ModuleInfo
बाइनरी प्रोटो है, जैसा कि बताया गया है
इंच
stardoc_output.proto
के लेवल को हाइलाइट कर सकते हैं.
इंप्लिसिट आउटपुट टारगेट
name.binaryproto
(डिफ़ॉल्ट आउटपुट): AModuleInfo
बाइनरी प्रोटो.name.textproto
(सिर्फ़ तब बनाया जाता है, जब साफ़ तौर पर अनुरोध किया गया हो): टेक्स्टname.binaryproto
का प्रोटो वर्शन.
चेतावनी: इस नियम के आउटपुट फ़ॉर्मैट के स्थिर होने की कोई गारंटी नहीं है. इसका उद्देश्य मुख्य रूप से Stardoc की ओर से अंदरूनी इस्तेमाल करता है.
तर्क
विशेषताएं | |
---|---|
name |
नाम; आवश्यक इस टारगेट के लिए यूनीक नाम. |
deps
|
लेबल की सूची; डिफ़ॉल्ट रूप से load() -ed से
src . इन टारगेट का इस्तेमाल सामान्य इस्तेमाल के तहत किया जाना चाहिए
bzl_library
लक्षित करता है, लेकिन starlark_doc_extract नियम उसे लागू नहीं करता है और
ऐसा कोई भी लक्ष्य जो अपने DefaultInfo में Starlark फ़ाइलें उपलब्ध कराता है.
ध्यान दें कि रैप की गई Starlark फ़ाइलें, सोर्स ट्री में मौजूद होनी चाहिए; बेज़ल यह नहीं कर सकते
|
src
|
लेबल; आवश्यक एक Starlark फ़ाइल जिससे दस्तावेज़ एक्सट्रैक्ट करना है.ध्यान दें कि यह सोर्स ट्री में मौजूद फ़ाइल होनी चाहिए; बेज़ल |
render_main_repo_name
|
बूलियन; //foo:bar.bzl को इसके तौर पर मिटाया जाएगा
@main_repo_name//foo:bar.bzl ).
मुख्य डेटा स्टोर करने की जगह के लिए इस्तेमाल किया जाने वाला नाम, इसके लिए दस्तावेज़ जनरेट करते समय, इस एट्रिब्यूट को |
symbol_names
|
स्ट्रिंग की सूची;
|
test_suite
नियम का सोर्स देखेंtest_suite(name, compatible_with, deprecation, distribs, features, licenses, restricted_to, tags, target_compatible_with, testonly, tests, visibility)
test_suite
, टेस्ट के ऐसे सेट के बारे में बताता है जिसे "काम का" माना जाता है इंसानों को किस तरह इस्तेमाल करना चाहिए. यह
इससे प्रोजेक्ट को टेस्ट के सेट तय करने की अनुमति मिलती है. उदाहरण के लिए, "चेकइन से पहले आपको वे टेस्ट जो चलाने चाहिए", "हमारा
प्रोजेक्ट के स्ट्रेस टेस्ट के तौर पर मार्क किया जा सकता है" या "सभी छोटे टेस्ट" जैसे टेस्ट का इस्तेमाल करना चाहिए. blaze test
निर्देश इस क्रम का पालन करता है
संगठन का नाम: blaze test //some/test:suite
जैसे शुरू करने के लिए, Blaze पहले
//some/test:suite
टारगेट में ट्रांज़िट रूप से शामिल किए गए सभी टेस्ट टारगेट की गणना करता है (हम
इसे "test_suite एक्सपैंशन") कॉल करें. इसके बाद, Blaze उन टारगेट को तैयार करके उनकी जांच करता है.
उदाहरण
मौजूदा पैकेज में सभी छोटे टेस्ट चलाने के लिए टेस्ट सुइट.
test_suite( name = "small_tests", tags = ["small"], )
टेस्ट का खास सेट चलाने वाला टेस्ट सुइट:
test_suite( name = "smoke_tests", tests = [ "system_unittest", "public_api_unittest", ], )
मौजूदा पैकेज में सभी ऐसी जांच करने के लिए टेस्ट सुइट जो फ़्लेकी नहीं हैं.
test_suite( name = "non_flaky_test", tags = ["-flaky"], )
तर्क
विशेषताएं | |
---|---|
name |
नाम; आवश्यक इस टारगेट के लिए यूनीक नाम. |
tags
|
स्ट्रिंग की सूची; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट रूप से "-" से शुरू होने वाले टैग वर्ण को नेगेटिव टैग माना जाता है. कॉन्टेंट बनाने "-" से पहले वर्ण को टैग का हिस्सा नहीं माना जाता है, इसलिए सुइट टैग "-small" का परीक्षण के "छोटे" से मेल खाता है साइज़. अन्य सभी टैग का इस्तेमाल किया जाता है पॉज़िटिव टैग. इसके अलावा, सकारात्मक टैग को ज़्यादा साफ़ तौर पर दिखाने के लिए, टैग की शुरुआत भी "+" वर्ण का इस्तेमाल करें, जिसकी गणना टैग के टेक्स्ट के हिस्से के रूप में नहीं की जाएगी. यह सकारात्मक और नकारात्मक के बीच के अंतर को आसानी से पढ़ा जा सकता है. सिर्फ़ उन नियमों की जांच करें जो सभी पॉज़िटिव टैग से और नेगेटिव किसी भी से मेल नहीं खाते टैग, टेस्ट सुइट में शामिल कर दिए जाएंगे. ध्यान दें कि इसका मतलब यह नहीं कि उस गड़बड़ी की जांच की जाए के लिए, जिन टेस्ट को फ़िल्टर करके बाहर कर दिया गया है उन्हें छोड़ दिया गया है; स्किप की गई डिपेंडेंसी परीक्षण अब भी कानूनी होने चाहिए (उदाहरण के लिए, दिखाई देने की सीमाओं की वजह से ब्लॉक न किया गया हो).
ध्यान दें कि जांच के
अगर आपको ऐसा |
tests
|
लेबल की सूची; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट रूप से
भाषा के अलावा, यहां किसी भी
अगर |