नियम
उपनाम
नियम का सोर्स देखेंalias(name, actual, compatible_with, deprecation, features, restricted_to, tags, target_compatible_with, testonly, visibility)
alias
नियम से एक और नाम बनता है. इसे नियम कहा जा सकता है.
एलियासिंग सिर्फ़ "सामान्य" टारगेट के लिए काम करती है. खास तौर पर, package_group
और test_suite
को उपनाम नहीं दिया जा सकता.
उपनाम नियम की अपनी दृश्यता घोषणा होती है. दूसरे सभी मामलों में, यह नियम की तरह काम करता है (उदाहरण के लिए, सिर्फ़ उपनाम पर जांच को अनदेखा किया जाता है; इसके बजाय, सिर्फ़ रेफ़रंस के लिए बताए गए नियम का टेस्ट इस्तेमाल किया जाता है):
-
अगर जांच के नतीजों में उनके उपनाम का उल्लेख कमांड लाइन पर किया गया है, तो जांच नहीं होगी. बताए गए टेस्ट को चलाने वाला उपनाम तय करने के लिए, अपने
tests
एट्रिब्यूट में एक ही टारगेट वालेtest_suite
नियम का इस्तेमाल करें. -
एनवायरमेंट ग्रुप तय करते समय,
environment
नियमों के उपनाम इस्तेमाल नहीं किए जा सकते. ये--target_environment
कमांड लाइन विकल्प में भी काम नहीं करतीं.
उदाहरण
filegroup( name = "data", srcs = ["data.txt"], ) alias( name = "other", actual = ":data", )
तर्क
विशेषताएं | |
---|---|
name |
इस टारगेट के लिए यूनीक नाम. |
actual
|
|
कॉन्फ़िगरेशन सेटिंग
नियम का सोर्स देखेंconfig_setting(name, constraint_values, define_values, deprecation, distribs, features, flag_values, licenses, tags, testonly, values, visibility)
कॉन्फ़िगर करने लायक एट्रिब्यूट को ट्रिगर करने के मकसद से, कॉन्फ़िगरेशन की स्थिति (बिल्ड फ़्लैग या प्लैटफ़ॉर्म की पाबंदियों के तौर पर दिखाई जाती है) का मिलान करता है. इस नियम को इस्तेमाल करने का तरीका जानने के लिए, चुनें और सामान्य सुविधा की खास जानकारी के लिए, कॉन्फ़िगर करने लायक एट्रिब्यूट देखें.
उदाहरण
यह कोड ऐसे किसी भी बिल्ड से मेल खाता है जो --compilation_mode=opt
या
-c opt
को सेट करता है. इसे कमांड लाइन पर या सीधे तौर पर .bazelrc फ़ाइलों से सेट किया जा सकता है:
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
को सेट करता है. ऐसा कमांड लाइन पर किया गया है या सीधे तौर पर .bazelrc फ़ाइलों से किया गया है:
config_setting( name = "my_custom_flag_is_set", flag_values = { "//custom_flags:foo": "1" }, )
यहां एक ऐसे बिल्ड का मिलान किया गया है जो x86_64 आर्किटेक्चर और glibc वर्शन 2.25 वाले प्लैटफ़ॉर्म को टारगेट करता है, यह मानते हुए कि लेबल //example:glibc_2_25
के साथ constraint_value
मौजूद है. ध्यान दें कि अगर प्लैटफ़ॉर्म इन दोनों की तुलना में ज़्यादा कंस्ट्रेंट वैल्यू तय करता है, तो वह अब भी मैच करता है.
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" }
में पहले वाले वैल्यू के बजाय--copt
वैल्यू दी जाती है. हालांकि,--ios_multi_cpus
(Apple के नियमों के लिए) करता है:-ios_multi_cpus=a,b
औरios_multi_cpus=a --ios_multi_cpus=b
, दोनों["a", "b"]
देते हैं. फ़्लैग की परिभाषाएं देखें और अपनी शर्तों का ध्यान से परीक्षण करके, उनसे सटीक अपेक्षाओं की पुष्टि करें. - अगर आपको ऐसी स्थितियां तय करनी हैं जो पहले से मौजूद बिल्ड फ़्लैग के मुताबिक नहीं हैं, तो
Starlark के तय किए गए फ़्लैग का इस्तेमाल करें.
--define
का इस्तेमाल भी किया जा सकता है. हालांकि, इससे साइट की सुरक्षा कमज़ोर हो जाती है. ज़्यादा चर्चा के लिए यहां देखें. - अलग-अलग पैकेज में एक जैसी
config_setting
परिभाषाओं को दोहराने से बचें. इसके बजाय, किसी सामान्य पैकेज के बारे में बताने वाला सामान्यconfig_setting
देखें. values
,define_values
, औरconstraint_values
को एक हीconfig_setting
के किसी भी कॉम्बिनेशन में इस्तेमाल किया जा सकता है. हालांकि, दिए गए किसी भीconfig_setting
के लिए, कम से कम एक सेट करना ज़रूरी है.
तर्क
विशेषताएं | |
---|---|
name |
इस टारगेट के लिए यूनीक नाम. |
constraint_values
|
constraint_values का कम से कम सेट जिसे इस config_setting प्लैटफ़ॉर्म से मेल खाने के लिए,
टारगेट प्लैटफ़ॉर्म को तय करना होगा. यहां एक्ज़ीक्यूशन प्लैटफ़ॉर्म को शामिल नहीं किया जाता. कोई भी अतिरिक्त कंस्ट्रेंट वैल्यू, जिसे प्लैटफ़ॉर्म को नज़रअंदाज़ कर दिया जाता है. ज़्यादा जानकारी के लिए,
कॉन्फ़िगर करने लायक बिल्ड एट्रिब्यूट देखें.
अगर दो |
define_values
|
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
|
values की तरह है, लेकिन
उपयोगकर्ता के तय किए गए बिल्ड फ़्लैग के लिए.
यह एक खास एट्रिब्यूट है, क्योंकि उपयोगकर्ता के फ़्लैग किए गए फ़्लैग का इस्तेमाल लेबल के तौर पर किया जाता है. हालांकि, पहले से मौजूद फ़्लैग को आर्बिट्ररी स्ट्रिंग के तौर पर इस्तेमाल किया जाता है. |
values
|
यह नियम, कॉन्फ़िगर किए गए टारगेट का कॉन्फ़िगरेशन इनहेरिट करता है. यह सुविधा के लिए, कॉन्फ़िगरेशन वैल्यू को बिल्ड फ़्लैग (पिछले अगर फ़्लैग को कमांड लाइन पर साफ़ तौर पर सेट नहीं किया गया है, तो इसकी डिफ़ॉल्ट वैल्यू का इस्तेमाल किया जाता है.
अगर शब्दकोश में कोई कुंजी कई बार दिखाई देती है, तो सिर्फ़ आखिरी इंस्टेंस का इस्तेमाल किया जाता है.
अगर कोई कुंजी किसी ऐसे फ़्लैग का रेफ़रंस देती है जिसे कमांड लाइन (उदाहरण
|
फ़ाइल ग्रुप
नियम का सोर्स देखें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
|
"आउटपुट ग्रुप", टारगेट के आउटपुट आर्टफ़ैक्ट की कैटगरी है. इसे नियम के लागू होने में बताया जाता है. |
Genquery
नियम का सोर्स देखेंgenquery(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()
ब्ले क्वेरी भाषा में दी गई क्वेरी चलाता है और नतीजे को फ़ाइल में डाल देता है.
बिल्ड को एक जैसा बनाए रखने के लिए, क्वेरी को सिर्फ़
scope
एट्रिब्यूट में बताए गए टारगेट की ट्रांज़िटिव 'बंदी' पर जाने की अनुमति है. अगर strict
के बारे में नहीं बताया गया है या सही है, तो इस नियम का उल्लंघन करने वाली क्वेरी काम करना बंद कर देंगी. (strict
गलत होने पर,
दायरे से बाहर के टारगेट को बस चेतावनी के साथ छोड़ दिया जाएगा). यह पक्का करने का सबसे आसान तरीका है कि ऐसा न हो. इसका मतलब है कि क्वेरी के दायरे में उसी लेबल को शामिल करें जैसा कि क्वेरी में किया गया है.
यहां और कमांड लाइन पर की जाने वाली क्वेरी के बीच सिर्फ़ इतना अंतर है कि यहां वाइल्डकार्ड टारगेट की खास जानकारी (उदाहरण के लिए, //pkg:*
या //pkg:all
) वाली क्वेरी की अनुमति नहीं है.
इसके दो कारण हैं: पहला, क्योंकि genquery
एक दायरे को क्वेरी के आउटपुट को प्रभावित करने के लिए
स्थायी रूप से बंद होने वाली क्वेरी से बाहर टारगेट करने से रोकता है; और दूसरी बात, क्योंकि BUILD
फ़ाइलें वाइल्डकार्ड डिपेंडेंसी के लिए काम नहीं करतीं (उदाहरण के लिए, deps=["//a/..."]
की अनुमति नहीं है).
खोज क्वेरी का आउटपुट, --order_output=full
का इस्तेमाल करके ऑर्डर किया जाता है, ताकि
डेटरमिस्टिक आउटपुट लागू किया जा सके.
आउटपुट फ़ाइल का नाम नियम का नाम होता है.
उदाहरण
इस उदाहरण में, फ़ाइल के लिए तय किए गए टारगेट के ट्रांज़िट समय में लेबल की सूची बनाई गई है.
genquery( name = "kiwi-deps", expression = "deps(//kiwi:kiwi_lib)", scope = ["//kiwi:kiwi_lib"], )
तर्क
विशेषताएं | |
---|---|
name |
इस टारगेट के लिए यूनीक नाम. |
expression
|
a/BUILD में एट्रिब्यूट में मौजूद :b लेबल, टारगेट //:b का रेफ़रंस देगा.
|
opts
|
bazel query को भेजा जा सकता है. यहां कुछ क्वेरी विकल्पों की अनुमति नहीं है: --keep_going , --query_file , --universe_scope ,
--order_results , और --order_output . यहां नहीं दिए गए विकल्पों की डिफ़ॉल्ट वैल्यू bazel query की कमांड लाइन की तरह ही होंगी.
|
scope
|
|
strict
|
|
Genrule
नियम का सोर्स देखेंgenrule(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
, उपयोगकर्ताओं के तय किए गए Bash कमांड का इस्तेमाल करके, एक या एक से ज़्यादा फ़ाइलें जनरेट करता है.
जनरेट करने के नियम, बिल्ड से जुड़े सामान्य नियम होते हैं. इनका इस्तेमाल तब किया जा सकता है, जब टास्क पर कोई खास नियम न हो.
जैसे, आप Bash एक-लाइनर चला सकते हैं. हालांकि, अगर आपको C++ फ़ाइलों को कंपाइल करना है, तो मौजूदा cc_*
नियमों का पालन करें. ऐसा इसलिए, क्योंकि सभी काम बड़े पैमाने पर होते हैं.
ध्यान दें कि genrule को कमांड आर्ग्युमेंट को समझने के लिए शेल लगाना पड़ता है. PATH पर मौजूद आर्बिट्ररी प्रोग्राम का रेफ़रंस भी आसानी से दिया जा सकता है. हालांकि, यह कमांड की सेटिंग को ऐसा बनाता है जिससे यह प्रोसेस आसान न हो और हो सकता है कि इसे फिर से जनरेट न किया जा सके. अगर आपको सिर्फ़ एक टूल चलाना है, तो run_binary का इस्तेमाल करें.
जांच करने के लिए जनरेटर का इस्तेमाल न करें. टेस्ट और टेस्ट के नतीजों के लिए कुछ खास सुविधाएं होती हैं. इनमें, कैश मेमोरी में सेव करने से जुड़ी नीतियां और एनवायरमेंट वैरिएबल भी शामिल हैं. आम तौर पर, बिल्ड के पूरा होने और टारगेट आर्किटेक्चर पर,
जांच करने की ज़रूरत होती है. हालांकि, बिल्ड के दौरान और एक्ज़ीक्यूटिव आर्किटेक्चर पर
प्रोग्राम के नियम लागू किए जाते हैं. ये दोनों अलग-अलग हो सकते हैं. अगर आपको अलग-अलग कामों के लिए इस्तेमाल किए जाने वाले नियम की ज़रूरत है, तो sh_test
का इस्तेमाल करें.
क्रॉस-कंपाइलेशन विचार
क्रॉस-कंपाइलेशन के बारे में ज़्यादा जानकारी के लिए, इस्तेमाल के लिए गाइड देखें.
बिल्ड के दौरान genrule चलाने पर, उनके आउटपुट अक्सर बिल्ड के बाद इस्तेमाल किए जाते हैं. साथ ही, इनका इस्तेमाल डिप्लॉयमेंट या जांच के लिए किया जाता है. माइक्रोकंट्रोलर के लिए C कोड को कंपाइल करने का उदाहरण देखें: कंपाइलर C सोर्स फ़ाइलों को स्वीकार करता है और माइक्रोकंट्रोलर पर चलने वाले कोड जनरेट करता है. आम तौर पर, जनरेट किया गया कोड, उसे बनाने के लिए इस्तेमाल किए गए सीपीयू पर नहीं चलाया जा सकता. हालांकि, सी कोड कंपाइलर (अगर सोर्स से कंपाइल किया गया हो) को खुद कोड बनाना पड़ता है.
बिल्ड सिस्टम जिस मशीन पर काम करता है उसके बारे में बताने के लिए, exec कॉन्फ़िगरेशन का इस्तेमाल करता है. साथ ही, बिल्ड का आउटपुट जिस मशीन पर चलता है उसकी जानकारी देने के लिए टारगेट कॉन्फ़िगरेशन का इस्तेमाल करता है. इससे, इनमें से हर एक को कॉन्फ़िगर करने का विकल्प मिलता है. साथ ही, यह फ़ाइलों को अलग-अलग डायरेक्ट्री में अलग-अलग करता है, ताकि किसी तरह की कोई समस्या न आए.
genनियमों के लिए, बिल्ड सिस्टम यह पक्का करता है कि डिपेंडेंसी सही तरह से बनाई गई हैं:
ज़रूरी है कॉन्फ़िगरेशन के लिए srcs
बनाए गए हैं (ज़रूरी होने पर),
tools
को exe कॉन्फ़िगरेशन के लिए बनाया जाता है और आउटपुट को टारगेट कॉन्फ़िगरेशन के लिए माना जाता है. इससे
"बनाएं" वैरिएबल भी मिलता है जिन्हें जनरेट करने वाले निर्देश, इनसे जुड़े टूल को पास कर सकें.
यह जान-बूझकर किया गया है कि genrule कोई deps
एट्रिब्यूट के बारे में नहीं बताता है: पहले से मौजूद दूसरे नियम, नियमों के बीच भेजे गए भाषा के हिसाब से मुख्य जानकारी का इस्तेमाल करते हैं. इससे यह तय किया जाता है कि डिपेंडेंट नियमों को कैसे मैनेज करना है. हालांकि, genrules के लिए इस लेवल पर ऑटोमेशन की सुविधा उपलब्ध नहीं है. जनरेट करने की सुविधा, सिर्फ़ फ़ाइल और रनफ़ाइल के लेवल पर काम करती है.
खास मामले
एक्ज़ीक्यूटिव कोड को इकट्ठा करना: कुछ मामलों में बिल्ड सिस्टम को जनरेट करने के लिए, जनरेटर के नियमों को चलाने की ज़रूरत पड़ती है. इस तरह, बिल्ड के दौरान भी आउटपुट एक्ज़ीक्यूट किया जा सकता है. उदाहरण के लिए, अगर कोई जेंट्रल कुछ कस्टम कंपाइलर बनाता है, जिसे बाद में दूसरे जेन्रूल इस्तेमाल करते हैं, तो पहले वाले को उसके कॉन्फ़िगरेशन के लिए आउटपुट बनाना होगा. ऐसा इसलिए, क्योंकि कंपाइलर दूसरे जनरेशन के सिस्टम में चलेगा. इस मामले में,
बिल्ड सिस्टम अपने-आप सही काम करता है: यह टारगेट कॉन्फ़िगरेशन के बजाय,
एक्ज़ीक्यूशन कॉन्फ़िगरेशन के लिए, पहले जनरेशन के srcs
और
outs
को बनाता है. ज़्यादा जानकारी के लिए, उपयोगकर्ता मैन्युअल देखें.
JDK और C++ टूल: JDK या C++ कंपाइलर सुइट से मिले टूल का इस्तेमाल करने के लिए, बिल्ड सिस्टम इस्तेमाल करने के लिए वैरिएबल का सेट उपलब्ध कराता है. ज़्यादा जानकारी के लिए "बनाएं" वैरिएबल देखें.
जनरेशन का माहौल
genrule कमांड एक बैश शेल लागू करता है जो किसी कमांड या पाइपलाइन के फ़ेल होने पर कॉन्फ़िगर हो जाता है. इसके लिए set -e -o pipefail
का इस्तेमाल किया जाता है.
बिल्ड टूल, सैनिटाइज़ प्रोसेस प्रोसेस में Bash कमांड को एक्ज़ीक्यूट करता है. इससे, सिर्फ़ PATH
, PWD
, TMPDIR
, और कुछ अन्य जैसे मुख्य वैरिएबल तय किए जाते हैं.
यह पक्का करने के लिए कि बिल्ड फिर से जनरेट हो सकता है, उपयोगकर्ता के शेल एनवायरमेंट में
तय किए गए ज़्यादातर वैरिएबल, genrule के निर्देश पर नहीं भेजे जाते हैं. हालांकि, Bazel (लेकिन ब्लेज़ नहीं)
से उपयोगकर्ता के PATH
वैरिएबल की वैल्यू पास होती है.
PATH
की वैल्यू में किसी भी तरह का बदलाव होने पर, Bazel अगले बिल्ड पर कमांड को फिर से
लागू करेगा.
gen न्योते को नेटवर्क पर ऐक्सेस नहीं करना चाहिए. सिर्फ़ ऐसी प्रोसेस को जोड़ा जा सकता है जो कमांड के चिल्ड्रन हों. हालांकि, फ़िलहाल इसे लागू नहीं किया गया है.
बिल्ड सिस्टम किसी भी मौजूदा आउटपुट फ़ाइल को अपने-आप मिटा देता है. हालांकि, नियम जनरेट होने से पहले, यह सभी ज़रूरी पैरंट डायरेक्ट्री बना देता है. अगर कोई गड़बड़ी होती है, तो आउटपुट फ़ाइलें भी हट जाती हैं.
सामान्य सलाह
- पक्का करें कि जो टूल जेंट्रल्स की मदद से चलाए जा रहे हैं वे तय करते हों कि उनमें दी गई जानकारी शामिल न हो. उन्हें अपने आउटपुट में टाइमस्टैंप नहीं लिखने चाहिए. साथ ही, उन्हें सेट और मैप के लिए स्थायी क्रम का इस्तेमाल करना चाहिए. साथ ही, आउटपुट के लिए सिर्फ़ मिलते-जुलते फ़ाइल पाथ लिखने चाहिए. इस नियम का पालन न करने पर, बिल्ड सही तरीके से काम नहीं करेगा. (Bazel का इस्तेमाल करके, ऐसे नियम को फिर से नहीं बनाया गया जिसके बारे में आपको लगता था कि यह ऐसा होगा). साथ ही, कैश मेमोरी की परफ़ॉर्मेंस खराब हो जाएगी.
- आउटपुट, टूल, और सोर्स के लिए
$(location)
का ज़्यादा इस्तेमाल करें. अलग-अलग कॉन्फ़िगरेशन के लिए अलग-अलग आउटपुट फ़ाइलें मिलने की वजह से, जेनरल्स, हार्ड कोड किए गए और/या सटीक पाथ पर भरोसा नहीं कर सकती. - अगर कई जगहों पर एक जैसे या बहुत मिलते-जुलते जेनरूलों का इस्तेमाल किया गया है, तो सामान्य स्टारलार्क मैक्रो लिखें. अगर जनरेशन नियम जटिल है, तो उसे स्क्रिप्ट या Starlark नियम के मुताबिक इस्तेमाल करें. इससे पढ़ने की क्षमता के साथ-साथ जांच करने की सुविधा भी बेहतर होती है.
- पक्का करें कि एग्ज़िट कोड सही तरीके से दिख रहा हो या रजिस्ट्रेशन में गड़बड़ी हो.
- 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)
.- सिमलिंक और डायरेक्ट्री बनाने से बचें. Bazel, डायरेक्ट्री/सिमलिंक स्ट्रक्चर को कॉपी नहीं करता, जिसे genनियम ने बनाया है और इसकी डिपेंडेंसी की जांच सही तरीके से नहीं हो रही है.
- दूसरे नियमों में जेन्रूल का रेफ़रंस देते समय, आप जेनरूल के लेबल या अलग-अलग आउटपुट फ़ाइलों के लेबल का इस्तेमाल करें. कभी-कभी एक तरीका आसानी से पढ़ा जा सकता है. कभी-कभी दूसरे तरीका: इस्तेमाल करने के नियम के
srcs
में, आउटपुट को नाम के हिसाब से रेफ़र करने से, अनजाने में genrule के दूसरे आउटपुट पिक अप नहीं होंगे. हालांकि, अगर जंग नियम कई आउटपुट बनाता है, तो यह तरीका मुश्किल हो सकता है.
उदाहरण
इस उदाहरण से foo.h
जनरेट होता है. कोई सोर्स नहीं है, क्योंकि निर्देश कोई इनपुट नहीं लेता. निर्देश से चलने वाली "बाइनरी", एक ही पैकेज में मौजूद पर्ल स्क्रिप्ट है.
genrule( name = "foo", srcs = [], outs = ["foo.h"], cmd = "./$(location create_foo.pl) > \"$@\"", tools = ["create_foo.pl"], )
इस उदाहरण में, filegroup
और दूसरे genrule
के आउटपुट का इस्तेमाल करने का तरीका बताया गया है. ध्यान दें कि $(location)
के लिए अश्लील डायरेक्टिव इस्तेमाल करने के बजाय, $(SRCS)
का इस्तेमाल भी किया जा सकता है. इस उदाहरण में, ऊपर दिए गए तरीके का इस्तेमाल करके, Google पर कॉन्टेंट को दिखाने का अनुरोध किया गया है.
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 |
इस टारगेट के लिए यूनीक नाम. अन्य नियम के srcs या deps सेक्शन में, नाम से इस नियम के बारे में बताया जा सकता है. अगर नियम में सोर्स फ़ाइलें जनरेट की जाती हैं, तो आपको srcs एट्रिब्यूट का इस्तेमाल करना चाहिए.
|
srcs
|
यह एट्रिब्यूट,
बिल्ड सिस्टम यह पक्का करता है कि इन ज़रूरी शर्तों को genrule
कमांड चलाने से पहले बनाया जाए. इन्हें उसी कॉन्फ़िगरेशन का इस्तेमाल करके बनाया जाता है जिसमें मूल रूप से अनुरोध किया गया हो. इन ज़रूरी शर्तों की फ़ाइलों के नाम,
|
outs
|
आउटपुट फ़ाइलों को पैकेज सीमाओं को पार नहीं करना चाहिए. आउटपुट फ़ाइल नामों को पैकेज से संबंधित समझा जाता है.
अगर
genrule निर्देश से हर आउटपुट फ़ाइल को पहले से तय जगह पर बनाने की उम्मीद की जाती है.
जगह की जानकारी, |
cmd
|
$(location)
और "बनाएं" वैरिएबल के विकल्प के हिसाब से.
cmd_bash , cmd_ps , और cmd_bat
का फ़ॉलबैक. अगर इनमें से कोई भी लागू नहीं होता है, तो.
अगर कमांड लाइन की लंबाई, प्लैटफ़ॉर्म के लिए तय सीमा (Linux/macOS पर 64K, Windows पर 8K)
से ज़्यादा है, तो genrule, स्क्रिप्ट को कमांड लिखेगा और उस स्क्रिप्ट को काम करने देगा. यह
सभी cmd एट्रिब्यूट पर लागू होता है ( |
cmd_bash
|
इस एट्रिब्यूट की प्राथमिकता, |
cmd_bat
|
इस एट्रिब्यूट की प्राथमिकता,
|
cmd_ps
|
इस एट्रिब्यूट की प्राथमिकता
PowerShell को इस्तेमाल करना आसान बनाने और गड़बड़ी की आशंका को कम करने के लिए, हम genरूल में PowerShell निर्देश लागू करने से पहले, इन कमांड को चालू करके एनवायरमेंट को सेट अप करते हैं.
|
exec_tools
|
tools का इस्तेमाल करें.
कुछ समय तक |
executable
|
इस फ़्लैग को 'सही है' पर सेट करने का मतलब है कि आउटपुट एक एक्ज़ीक्यूटेबल फ़ाइल है.
इसे जनरेट किए गए एक्ज़ीक्यूटेबल के लिए, डेटा डिपेंडेंसी का एलान नहीं किया जा सकता. |
local
|
अगर इसे 'सही है' पर सेट किया जाता है, तो इस विकल्प की वजह से,
यह टैग के रूप में 'स्थानीय' देने के बराबर है ( |
message
|
यह चरण पूरा होने पर, एक प्रोग्रेस मैसेज प्रिंट किया जाएगा. डिफ़ॉल्ट रूप से, यह मैसेज "आउटपुट" (या कुछ ऐसा ही होता है) जनरेट करता है, लेकिन आप
उससे ज़्यादा
सटीक जानकारी दे सकते हैं. अपने |
output_licenses
|
common attributes
देखें
|
output_to_bindir
|
अगर इस विकल्प को 'सही है' पर सेट किया जाता है, तो आउटपुट फ़ाइलों को |
tools
|
बिल्ड सिस्टम यह पक्का करता है कि इन नियमों को, जनरेट करने वाले निर्देश को चलाने से पहले बनाया जाए.
इन्हें exec
कॉन्फ़िगरेशन के इस्तेमाल से बनाया जाता है, क्योंकि इन टूल को बिल्ड के हिस्से के तौर पर इस्तेमाल किया जाता है.
|
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
जैसे शुरू करने के लिए, ब्लेज़ पहले, //some/test:suite
टारगेट में शामिल किए गए सभी टेस्ट टारगेट की गणना करता है (इसे "test_suite एक्सपैंशन" कहते हैं). इसके बाद, ब्लेज़ उन टारगेट को बनाता है और उनकी जांच करता है.
उदाहरण
मौजूदा पैकेज में सभी छोटे टेस्ट चलाने के लिए एक टेस्ट सुइट.
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
|
अगर |