इस पेज पर उन विकल्पों के बारे में बताया गया है जो Bazel के कई निर्देशों के साथ उपलब्ध हैं.
जैसे, bazel build
, bazel run
, और bazel test
. यह पेज, Build with Bazel में Bazel के निर्देशों की सूची में शामिल है.
टारगेट सिंटैक्स
build
या test
जैसे कुछ निर्देश, टारगेट की सूची पर काम कर सकते हैं. वे
लेबल के मुकाबले ज़्यादा लचीले सिंटैक्स का इस्तेमाल करते हैं. इस बारे में बनाया जाने वाला टारगेट तय करना लेख में बताया गया है.
विकल्प
नीचे दिए सेक्शन में बिल्ड के दौरान उपलब्ध विकल्पों के बारे में बताया गया है. जब --long
का इस्तेमाल सहायता निर्देश के लिए किया जाता है, तो ऑन-लाइन सहायता मैसेज हर विकल्प के मतलब, उसके टाइप, और डिफ़ॉल्ट वैल्यू के बारे में खास जानकारी देते हैं.
ज़्यादातर विकल्प सिर्फ़ एक बार तय किए जा सकते हैं. कई बार तय किए जाने पर, आखिरी इंस्टेंस जीतता है. कई बार तय किए जा सकने वाले विकल्पों की ऑन-लाइन सहायता में 'कई बार इस्तेमाल किया जा सकता है' टेक्स्ट के साथ उनकी पहचान की जाती है.
पैकेज की जगह
--package_path
यह विकल्प उन डायरेक्ट्री के सेट को तय करता है जिन्हें किसी दिए गए पैकेज की BUILD फ़ाइल ढूंढने के लिए खोजा जाता है.
Bazel, पैकेज पाथ में खोज करके अपने पैकेज ढूंढता है. यह bazel डायरेक्ट्री की कोलन से अलग की गई क्रम वाली सूची है. हर डायरेक्ट्री, आंशिक सोर्स ट्री का रूट है.
--package_path
विकल्प का इस्तेमाल करके, कस्टम पैकेज पाथ तय करने के लिए:
% bazel build --package_path %workspace%:/some/other/root
पैकेज पाथ के एलिमेंट तीन फ़ॉर्मैट में दिखाए जा सकते हैं:
- अगर पहला वर्ण
/
है, तो पाथ की वैल्यू नहीं बताई जाती है. - अगर पाथ
%workspace%
से शुरू होता है, तो पाथ को पास की नज़दीकी बेज़ल डायरेक्ट्री के हिसाब से लिया जाता है. उदाहरण के लिए, अगर आपकी वर्किंग डायरेक्ट्री/home/bob/clients/bob_client/bazel/foo
है, तो पैकेज-पाथ में मौजूद स्ट्रिंग%workspace%
को/home/bob/clients/bob_client/bazel
में बड़ा कर दिया जाएगा. - अन्य कोई भी चीज़, वर्किंग डायरेक्ट्री से जुड़ी होती है.
आम तौर पर, यह आपकी ज़रूरत से मेल नहीं खाता.
अगर bazel फ़ाइल फ़ोल्डर के नीचे मौजूद डायरेक्ट्री से Bazel का इस्तेमाल किया जाता है, तो यह अनचाहे तरीके से काम कर सकता है.
उदाहरण के लिए, अगर पैकेज-पाथ एलिमेंट
.
का इस्तेमाल किया जाता है और फिर इसे/home/bob/clients/bob_client/bazel/foo
डायरेक्ट्री में cd किया जाता है, तो पैकेज/home/bob/clients/bob_client/bazel/foo
डायरेक्ट्री से रिज़ॉल्व हो जाएंगे.
अगर पैकेज पाथ डिफ़ॉल्ट नहीं है, तो सुविधा के लिए इसे अपनी Bazel कॉन्फ़िगरेशन फ़ाइल में डालें.
Bazel के लिए मौजूदा डायरेक्ट्री में कोई पैकेज होना ज़रूरी नहीं है. इसलिए, अगर सभी ज़रूरी पैकेज पाने के लिए पैकेज पाथ में किसी और जगह मौजूद हों, तो खाली बैजल वर्कस्पेस से बिल्ड किया जा सकता है.
उदाहरण: किसी खाली क्लाइंट से बनाना
% mkdir -p foo/bazel % cd foo/bazel % touch WORKSPACE % bazel build --package_path /some/other/path //foo
--deleted_packages
यह विकल्प उन पैकेज की कॉमा-सेपरेटेड लिस्ट के बारे में बताता है जिन्हें Bazel मिटाया जा सकता है. साथ ही, पैकेज पाथ पर किसी डायरेक्ट्री से लोड करने की कोशिश नहीं करनी चाहिए. इसका इस्तेमाल, पैकेज को मिटाए बिना सिम्युलेट करने के लिए किया जा सकता है.
गड़बड़ी जांच
ये विकल्प, Bazel की गड़बड़ी की जांच और/या चेतावनियों को कंट्रोल करते हैं.
--[no]check_visibility
अगर यह विकल्प 'गलत है' पर सेट है, तो 'किसको दिखे' सेटिंग की स्थिति के बजाय कोई चेतावनी नहीं दिखती है. इस विकल्प की डिफ़ॉल्ट वैल्यू 'सही' होती है, ताकि डिफ़ॉल्ट रूप से, विज़िबिलिटी की जांच की जा सके.
--output_filter=regex
--output_filter
विकल्प, रेगुलर एक्सप्रेशन से मैच करने वाले टारगेट के लिए सिर्फ़ बिल्ड और कंपाइलेशन चेतावनियां दिखाएगा. अगर कोई टारगेट,
दिए गए रेगुलर एक्सप्रेशन से मेल नहीं खाता और एक्ज़ीक्यूशन पूरा हो जाता है, तो इसके स्टैंडर्ड
आउटपुट और स्टैंडर्ड गड़बड़ी को हटा दिया जाता है.
इस विकल्प के लिए यहां कुछ सामान्य मान दिए गए हैं:
`--output_filter='^//(first/project|second/project):'` | तय किए गए पैकेज के लिए आउटपुट दिखाएं. |
`--output_filter='^//((?!(first/bad_project|second/bad_project):).)*$'` | चुने गए पैकेज के लिए आउटपुट न दिखाएं. |
`--output_filter=` | सब कुछ दिखाएं. |
`--output_filter=DONT_MATCH_ANYTHING` | कुछ न दिखाएं. |
टूल फ़्लैग
इन विकल्पों से यह तय होता है कि Bazel, दूसरे टूल को कौनसे विकल्प देगा.
--copt=cc-option
इस विकल्प में एक तर्क होता है, जिसे कंपाइलर को भेजा जाता है. प्री-प्रोसेसिंग, कंपाइल, और/या C, C++ या असेंबलर कोड को असेंबल करने के लिए, जब भी इसे शुरू किया जाएगा, तब कंपाइलर को आर्ग्युमेंट पास किया जाएगा. लिंक करते समय, इसे पास नहीं किया जाएगा.
इस विकल्प का इस्तेमाल एक से ज़्यादा बार किया जा सकता है. उदाहरण के लिए:
% bazel build --copt="-g0" --copt="-fpic" //foo
डीबग टेबल के बिना foo
लाइब्रेरी को कंपाइल करेगा, ताकि पोज़िशन-इंडिपेंडेंट कोड जनरेट हो सके.
--host_copt=cc-option
यह विकल्प एक तर्क लेता है, जिसे होस्ट कॉन्फ़िगरेशन में कंपाइल की गई सोर्स फ़ाइलों के लिए, कंपाइलर को भेजा जाता है. यह --copt
विकल्प के जैसा है. हालांकि, यह सिर्फ़ होस्ट कॉन्फ़िगरेशन पर लागू होता है.
--host_conlyopt=cc-option
यह विकल्प एक आर्ग्युमेंट लेता है, जिसे होस्ट कॉन्फ़िगरेशन में कंपाइल की गई C सोर्स फ़ाइलों के कंपाइलर को भेजा जाता है. यह --conlyopt
विकल्प के जैसा है, लेकिन सिर्फ़ होस्ट कॉन्फ़िगरेशन पर लागू होता है.
--host_cxxopt=cc-option
यह विकल्प एक तर्क लेता है, जिसे होस्ट कॉन्फ़िगरेशन में कंपाइल की गई C++ सोर्स फ़ाइलों के लिए कंपाइलर को भेजा जाता है. यह --cxxopt
विकल्प के जैसा है. हालांकि, यह सिर्फ़ होस्ट कॉन्फ़िगरेशन पर लागू होता है.
--host_linkopt=linker-option
यह विकल्प एक तर्क लेता है, जिसे होस्ट कॉन्फ़िगरेशन में कंपाइल की गई सोर्स फ़ाइलों के लिंकर को भेजा जाता है. यह --linkopt
विकल्प के जैसा है. हालांकि, यह सिर्फ़ होस्ट कॉन्फ़िगरेशन पर लागू होता है.
--conlyopt=cc-option
इस विकल्प की मदद से एक आर्ग्युमेंट बनाया जाता है, जिसे C सोर्स फ़ाइलों को कंपाइल करते समय, कंपाइलर को भेजा जाता है.
यह --copt
की तरह है, लेकिन सिर्फ़ C कंपाइलेशन पर लागू होता है, C++ कंपाइलेशन या लिंकिंग पर नहीं. इसलिए, --conlyopt
का इस्तेमाल करके सी-खास विकल्प (जैसे, -Wno-pointer-sign
) पास किए जा सकते हैं.
--cxxopt=cc-option
इस विकल्प में एक तर्क होता है, जिसे C++ सोर्स फ़ाइलों को कंपाइल करते समय, कंपाइलर को भेजा जाता है.
यह --copt
जैसा है. हालांकि, यह सिर्फ़ C++ कंपाइलेशन पर लागू होता है, C कंपाइलेशन या लिंकिंग पर नहीं. इसलिए, --cxxopt
का इस्तेमाल करके C++ के खास विकल्प
(जैसे कि -fpermissive
या -fno-implicit-templates
) पास किए जा सकते हैं.
उदाहरण के लिए:
% bazel build --cxxopt="-fpermissive" --cxxopt="-Wno-error" //foo/cruddy_code
--linkopt=linker-option
यह विकल्प एक आर्ग्युमेंट लेता है, जिसे लिंक करते समय कंपाइलर को भेजा जाता है.
यह --copt
से मिलता-जुलता है. हालांकि, यह सिर्फ़ लिंक करने पर लागू होता है, कंपाइलेशन पर नहीं. इसलिए, ऐसे कंपाइलर विकल्पों को पास किया जा सकता है जो --linkopt
का इस्तेमाल करके, लिंक के समय ही काम करते हैं (जैसे कि -lssp
या -Wl,--wrap,abort
). उदाहरण के लिए:
% bazel build --copt="-fmudflap" --linkopt="-lmudflap" //foo/buggy_code
बिल्ड के नियम, अपने एट्रिब्यूट में लिंक के विकल्प भी तय कर सकते हैं. इस विकल्प की सेटिंग को हमेशा प्राथमिकता दी जाती है. cc_library.linkopts पर भी जाएं.
--strip (always|never|sometimes)
इस विकल्प से तय होता है कि क्या Bazel, लिंकर को -Wl,--strip-debug
विकल्प के साथ चालू करके, सभी बाइनरी और शेयर की गई लाइब्रेरी से डीबग करने की जानकारी हटाएगा.
--strip=always
का मतलब है कि डीबग करने की जानकारी को हमेशा हटाएं.
--strip=never
का मतलब है कि डीबग करने की जानकारी कभी न हटाएं.
--strip=sometimes
की डिफ़ॉल्ट वैल्यू का मतलब है कि अगर --compilation_mode
fastbuild
है, तो स्ट्रिप करें.
% bazel build --strip=always //foo:bar
जनरेट की गई सभी बाइनरी से डीबग करने की जानकारी हटाकर, टारगेट को कंपाइल करेगा.
Bazel का --strip
विकल्प, ld के --strip-debug
विकल्प से मेल खाता है:
यह सिर्फ़ डीबग करने की जानकारी को हटाता है. अगर किसी वजह से डीबग के बजाय, सभी सिंबल को हटाना है, तो आपको ld के --strip-all
विकल्प का इस्तेमाल करना होगा. यह विकल्प Bazel को --linkopt=-Wl,--strip-all
भेजकर किया जा सकता है. यह भी ध्यान रखें
कि Bazel का --strip
फ़्लैग सेट करने से
--linkopt=-Wl,--strip-all
बदल जाएगा. इसलिए, आपको सिर्फ़ एक फ़्लैग को सेट करना चाहिए.
अगर सिर्फ़ एक बाइनरी तैयार की जा रही है और सभी सिंबल को हटाना है, तो --stripopt=--strip-all
को पास किया जा सकता है. साथ ही, टारगेट का //foo:bar.stripped
वर्शन भी साफ़ तौर पर बनाया जा सकता है. जैसा कि --stripopt
के सेक्शन में बताया गया है, इससे फ़ाइनल बाइनरी के लिंक होने के बाद स्ट्रिप से जुड़ी कार्रवाई लागू होती है. इसके लिए, बिल्ड की सभी लिंक कार्रवाइयों को शामिल नहीं किया जाता.
--stripopt=strip-option
*.stripped
बाइनरी जनरेट करते समय, strip
कमांड को पास करने के लिए यह एक अतिरिक्त विकल्प है. डिफ़ॉल्ट वैल्यू
-S -p
है. इस विकल्प का इस्तेमाल एक से ज़्यादा बार किया जा सकता है.
--fdo_instrument=profile-output-dir
--fdo_instrument
विकल्प, बिल्ट-इन C/C++ बाइनरी को एक्ज़ीक्यूट करने पर, एफ़डीओ (फ़ीडबैक से मिलने वाला ऑप्टिमाइज़ेशन) प्रोफ़ाइल आउटपुट को जनरेट करने की सुविधा चालू करता है. जीसीसी के लिए, दिए गए तर्क का इस्तेमाल .gcda फ़ाइलों के हर ऑब्जेक्ट फ़ाइल डायरेक्ट्री ट्री के लिए एक डायरेक्ट्री प्रीफ़िक्स के तौर पर किया जाता है. इसमें हर .o फ़ाइल की प्रोफ़ाइल की जानकारी होती है.
प्रोफ़ाइल डेटा ट्री जनरेट होने के बाद, प्रोफ़ाइल ट्री को zip अप करना चाहिए. साथ ही, उसे
--fdo_optimize=profile-zip
FDO-ऑप्टिमाइज़ किए गए कंपाइलेशन को चालू करने के लिए, Bazel विकल्प में देना चाहिए.
एलएलवीएम कंपाइलर के लिए आर्ग्युमेंट वह डायरेक्ट्री भी होती है जिसमें रॉ एलएलवीएम प्रोफ़ाइल की डेटा फ़ाइल(फ़ाइलें) डंप की जाती हैं. उदाहरण के लिए:
--fdo_instrument=/path/to/rawprof/dir/
.
एक ही समय पर --fdo_instrument
और --fdo_optimize
विकल्प इस्तेमाल नहीं किए जा सकते.
--fdo_optimize=profile-zip
--fdo_optimize
विकल्प की मदद से, कंपाइल करते समय
हर ऑब्जेक्ट वाली फ़ाइल की प्रोफ़ाइल की जानकारी का इस्तेमाल किया जा सकता है, ताकि कंपाइलेशन करते समय एफ़डीओ (सुझाव के तौर पर
ऑप्टिमाइज़ेशन) को ऑप्टिमाइज़ किया जा सके. जीसीसी के लिए, दिया गया तर्क वह zip फ़ाइल होती है जिसमें .gcda फ़ाइलों की पहले से जनरेट की गई फ़ाइल ट्री होती है. इसमें हर .o फ़ाइल की प्रोफ़ाइल जानकारी होती है.
इसके अलावा, दिया गया तर्क, .afdo एक्सटेंशन से पहचानी गई ऑटो प्रोफ़ाइल की तरफ़ इशारा कर सकता है.
एलएलवीएम कंपाइलर के लिए दिया गया तर्क, llvm-profdata टूल से तैयार की गई, इंडेक्स की गई LLVM प्रोफ़ाइल की आउटपुट फ़ाइल की ओर इशारा करना चाहिए और उसमें .profdata एक्सटेंशन होना चाहिए.
एक ही समय पर --fdo_instrument
और --fdo_optimize
विकल्प इस्तेमाल नहीं किए जा सकते.
--[no]output_symbol_counts
अगर यह सुविधा चालू की जाती है, तो C++ एक्ज़ीक्यूटेबल बाइनरी का गोल्ड-इन्वॉल्ड लिंक, एक प्रतीक गिनती वाली फ़ाइल (--print-symbol-counts
गोल्ड विकल्प के ज़रिए) दिखाएगा. लिंकर के हर इनपुट के लिए, फ़ाइल तय किए गए निशानों की संख्या और बाइनरी में इस्तेमाल किए गए प्रतीकों की संख्या लॉग करती है.
इस जानकारी का इस्तेमाल, गैर-ज़रूरी लिंक डिपेंडेंसी को ट्रैक करने के लिए किया जा सकता है.
चिह्न की गिनती वाली फ़ाइल को बाइनरी के आउटपुट पाथ में
[targetname].sc
नाम से लिखा जाता है.
यह विकल्प डिफ़ॉल्ट रूप से बंद होता है.
--java_language_version=version
यह विकल्प Java सोर्स के वर्शन के बारे में बताता है. उदाहरण के लिए:
% bazel build --java_language_version=8 java/com/example/common/foo:all
कंपाइल करता है और सिर्फ़ ऐसे कंस्ट्रक्ट को अनुमति देता है जो Java 8 स्पेसिफ़िकेशन के साथ काम करते हैं.
डिफ़ॉल्ट वैल्यू 11 है. -->
संभावित वैल्यू ये हैं: 8, 9, 10, 11, 14, और 15. इन्हें default_java_toolchain
का इस्तेमाल करके, कस्टम Java टूलचेन रजिस्टर करके बढ़ाया जा सकता है.
--tool_java_language_version=version
Java लैंग्वेज वर्शन, जिसका इस्तेमाल उन टूल को बनाने में किया जाता है जो बिल्ड के दौरान काम करते हैं. डिफ़ॉल्ट वैल्यू 11 है.
--java_runtime_version=version
यह विकल्प, JVM के उस वर्शन के बारे में बताता है जिसका इस्तेमाल, कोड को चलाने और टेस्ट करने के लिए किया जाता है. उदाहरण के लिए:
% bazel run --java_runtime_version=remotejdk_11 java/com/example/common/foo:java_application
रिमोट रिपॉज़िटरी से JDK 11 डाउनलोड करता है और इसका इस्तेमाल करके Java ऐप्लिकेशन चलाता है.
डिफ़ॉल्ट वैल्यू localjdk
है.
वैल्यू इस तरह की हो सकती हैं: localjdk
, localjdk_version
,
remotejdk_11
, और remote_jdk17
.
local_java_repository
या remote_java_repostory
रिपॉज़िटरी के नियमों का इस्तेमाल करके, कस्टम जेवीएम को रजिस्टर करके वैल्यू बढ़ाई जा सकती है.
--tool_java_runtime_version=version
यह जेवीएम का वर्शन है, जिसका इस्तेमाल उन टूल को चलाने के लिए किया जाता है जो बिल्ड के दौरान ज़रूरी होते हैं.
डिफ़ॉल्ट वैल्यू remotejdk_11
है.
--jvmopt=jvm-option
इस विकल्प की मदद से, Java वीएम को विकल्प के तर्क भेजे जाते हैं. इसका इस्तेमाल एक बड़े तर्क के साथ या अलग-अलग तर्कों के साथ कई बार किया जा सकता है. उदाहरण के लिए:
% bazel build --jvmopt="-server -Xms256m" java/com/example/common/foo:all
सभी Java बाइनरी को लॉन्च करने के लिए, सर्वर वीएम का इस्तेमाल करेगा. साथ ही, वीएम के लिए स्टार्टअप हीप साइज़ को 256 एमबी पर सेट करेगा.
--javacopt=javac-option
इस विकल्प की मदद से, विकल्प के आर्ग्युमेंट को javac पर भेजा जा सकता है. इसका इस्तेमाल एक बड़े तर्क के साथ या अलग-अलग तर्कों के साथ कई बार किया जा सकता है. उदाहरण के लिए:
% bazel build --javacopt="-g:source,lines" //myprojects:prog
javac डिफ़ॉल्ट डीबग जानकारी के साथ java_binary फिर से बनाएगा (bazel डिफ़ॉल्ट की बजाय).
यह विकल्प javac को पास किया जाता है. यह Javac के लिए बिल्ट-इन डिफ़ॉल्ट विकल्पों के बाद और हर नियम के विकल्पों से पहले लागू होता है. javac जीत के किसी भी विकल्प की आखिरी खास बातें. javac के लिए डिफ़ॉल्ट विकल्प ये हैं:
-source 8 -target 8 -encoding UTF-8
--strict_java_deps (default|strict|off|warn|error)
इस विकल्प से यह कंट्रोल किया जाता है कि javac सीधे तौर पर डिपेंडेंसी के गायब होने की जांच करता है या नहीं. Java टारगेट को सीधे तौर पर इस्तेमाल किए जाने वाले सभी टारगेट को, डिपेंडेंसी के तौर पर साफ़ तौर पर बताना चाहिए. यह फ़्लैग javac को निर्देश देता है कि वह हर तरह की JavaScript फ़ाइल की जांच करने के लिए इस्तेमाल किए गए जार की पहचान करे. साथ ही, अगर वे मौजूदा टारगेट की डायरेक्ट डिपेंडेंसी के आउटपुट न हों, तो चेतावनी/गड़बड़ी की चेतावनी दें.
off
का मतलब है कि जांच बंद है.warn
का मतलब है कि JavaScript, हर डायरेक्ट डिपेंडेंसी के लिए[strict]
टाइप की स्टैंडर्ड JavaScript चेतावनियां जनरेट करेगा.default
,strict
, औरerror
सभी मीन जावाक, चेतावनियों के बजाय गड़बड़ियां जनरेट करेंगे. इस वजह से, अगर कोई डायरेक्ट डिपेंडेंसी नहीं मिलती है, तो मौजूदा टारगेट पूरी तरह तैयार नहीं हो पाएगा. अगर फ़्लैग के बारे में नहीं बताया गया है, तो भी यह डिफ़ॉल्ट तरीके से लागू होता है.
बिल्ड सिमैंटिक
ये विकल्प बिल्ड कमांड और/या आउटपुट फ़ाइल के कॉन्टेंट पर असर डालते हैं.
--compilation_mode (fastbuild|opt|dbg)
(-c)
--compilation_mode
विकल्प (अक्सर -c
, खास तौर पर -c opt
में छोटा किया जाता है) fastbuild
, dbg
या opt
का आर्ग्युमेंट लेता है. यह कई C/C++ कोड जनरेट करने वाले विकल्पों पर असर डालता है, जैसे कि ऑप्टिमाइज़ेशन का लेवल और डीबग टेबल के पूरा होने की स्थिति. Bazel हर अलग कंपाइलेशन मोड के लिए, एक अलग आउटपुट डायरेक्ट्री का इस्तेमाल करता है. इससे आपको हर बार पूरी तरह से फिर से बनाने की ज़रूरत नहीं, मोड के बीच स्विच करने में मदद मिलती है.
fastbuild
का मतलब है, जितनी जल्दी हो सके उतना जल्दी बनाएं: डीबग करने की कम से कम जानकारी जनरेट करें (-gmlt -Wl,-S
) और ऑप्टिमाइज़ न करें. यह डिफ़ॉल्ट है. ध्यान दें:-DNDEBUG
को सेट नहीं किया जाएगा.dbg
का मतलब है डीबग करने की सुविधा के साथ बिल्ड (-g
), ताकि आप जीडीबी (या किसी दूसरे डीबगर) का इस्तेमाल कर सकें.opt
का मतलब है कि ऑप्टिमाइज़ेशन की सुविधा के साथ बिल्ड औरassert()
कॉल बंद होने पर (-O2 -DNDEBUG
). डीबग करने की जानकारीopt
मोड में तब तक जनरेट नहीं होगी, जब तक कि आप--copt -g
को भी पास नहीं कर लेते.
--cpu=cpu
यह विकल्प बिल्ड के दौरान बाइनरी के कंपाइलेशन के लिए इस्तेमाल किए जाने वाले टारगेट सीपीयू आर्किटेक्चर को तय करता है.
--action_env=VAR=VALUE
सभी कार्रवाइयों के चलने के दौरान उपलब्ध एनवायरमेंट वैरिएबल के सेट को तय करता है.
वैरिएबल को नाम से तय किया जा सकता है. इस स्थिति में, वैल्यू को शुरू करने वाले एनवायरमेंट से लिया जाएगा या name=value
पेयर से लिया जाएगा, जो वैल्यू को शुरू करने वाले एनवायरमेंट से अलग सेट करता है.
इस --action_env
फ़्लैग के बारे में एक से ज़्यादा बार बताया जा सकता है. अगर एक से ज़्यादा --action_env
फ़्लैग में, एक ही वैरिएबल को कोई वैल्यू असाइन की जाती है, तो नया असाइनमेंट जीत जाएगा.
--experimental_action_listener=label
experimental_action_listener
विकल्प, Bazel को निर्देश देता है कि वह
label के बताए गए action_listener
नियम की जानकारी का इस्तेमाल करके, बिल्ड ग्राफ़ में extra_actions
डाले.
--[no]experimental_extra_action_top_level_only
अगर यह विकल्प 'सही' पर सेट है, तो --experimental_action_listener
कमांड लाइन विकल्प से तय की गई
अतिरिक्त कार्रवाइयां, सिर्फ़ टॉप लेवल टारगेट के लिए शेड्यूल की जाएंगी.
--experimental_extra_action_filter=regex
यह experimental_extra_action_filter
विकल्प, Bazel को
extra_actions
शेड्यूल करने के लिए टारगेट के सेट को फ़िल्टर करने का निर्देश देता है.
इस फ़्लैग को सिर्फ़
--experimental_action_listener
फ़्लैग के साथ इस्तेमाल किया जा सकता है.
जिस टारगेट-टू-बिल्ड का अनुरोध किया गया है उसके ट्रांज़िटिव क्लोज़र में मौजूद सभी extra_actions
, डिफ़ॉल्ट रूप से शेड्यूल होने के लिए शेड्यूल किए जाते हैं.
--experimental_extra_action_filter
, शेड्यूल करने की सुविधा को extra_actions
तक सीमित कर देगा. इसमें मालिक का लेबल, बताए गए रेगुलर एक्सप्रेशन से मैच करेगा.
इस उदाहरण में, extra_actions
की शेड्यूलिंग को सीमित कर दिया गया है. ऐसा सिर्फ़ उन कार्रवाइयों पर लागू होगा जिनमें मालिक के लेबल में '/bar/' शामिल हो:
% bazel build --experimental_action_listener=//test:al //foo/... \ --experimental_extra_action_filter=.*/bar/.*
--host_cpu=cpu
यह विकल्प उस सीपीयू आर्किटेक्चर का नाम बताता है जिसका इस्तेमाल होस्ट टूल बनाने के लिए किया जाना चाहिए.
--fat_apk_cpu=cpu[,cpu]*
वे सीपीयू जो android_binary
नियमों के deps
में C/C++ लाइब्रेरी बनाने के लिए हैं. हालांकि, C/C++ के अन्य नियमों पर इसका कोई असर नहीं पड़ेगा. उदाहरण के लिए, अगर
cc_library
, android_binary
नियम के ट्रांज़िटिव deps
और cc_binary
नियम में दिखता है, तो cc_library
को कम से कम दो बार बनाया जाएगा:
android_binary
नियम के लिए, --fat_apk_cpu
के साथ बताए गए हर सीपीयू के लिए एक बार और cc_binary
नियम के लिए, --cpu
से बताए गए सीपीयू के लिए एक बार.
डिफ़ॉल्ट वैल्यू armeabi-v7a
है.
--fat_apk_cpu
के साथ बताए गए हर सीपीयू के लिए, एक .so
फ़ाइल बनाई और APK में पैकेज की जाती है. .so
फ़ाइल के नाम के पहले, android_binary
नियम का नाम "lib" होता है. उदाहरण के लिए, अगर android_binary
का नाम "foo" है, तो फ़ाइल libfoo.so
होगी.
--per_file_copt=[+-]regex[,[+-]regex]...@option[,option]...
अगर कोई C++ फ़ाइल मौजूद है, तो उसके साथ लेबल या एक्ज़ीक्यूशन पाथ दिया गया है. यह पाथ, शामिल किए गए रेगुलर एक्सप्रेशन एक्सप्रेशन से मेल खाता है और किसी भी एक्सक्लूज़न एक्सप्रेशन से मैच नहीं करता है. फ़ाइल, दिए गए विकल्पों की मदद से बनाई जाएगी. लेबल मैचिंग, लेबल के कैननिकल फ़ॉर्म का इस्तेमाल करता है
(जैसे, //package
:label_name
).
एक्ज़ीक्यूशन पाथ, आपकी फ़ाइल फ़ोल्डर की डायरेक्ट्री का मिलता-जुलता पाथ होता है. इसमें C++ फ़ाइल का बेस नेम (इसमें एक्सटेंशन भी शामिल है) शामिल होता है. इसमें प्लैटफ़ॉर्म पर निर्भर सभी प्रीफ़िक्स भी शामिल हैं.
जनरेट की गई फ़ाइलों से मिलान करने के लिए (जैसे कि genrole आउटपुट)
Bazel सिर्फ़ प्रोग्राम चलाने के पाथ का इस्तेमाल कर सकता है. इस मामले में regexp को '//' से शुरू नहीं होना चाहिए, क्योंकि यह किसी एक्ज़ीक्यूशन पाथ से मेल नहीं खाता. पैकेज के नाम का इस्तेमाल इस तरह किया जा सकता है:
--per_file_copt=base/.*\.pb\.cc@-g0
. यह base
नाम की डायरेक्ट्री में मौजूद हर .pb.cc
फ़ाइल से मेल खाएगा.
इस विकल्प का इस्तेमाल एक से ज़्यादा बार किया जा सकता है.
यह विकल्प लागू किया जाता है, भले ही कंपाइलेशन मोड का इस्तेमाल किया गया हो. उदाहरण के लिए, ऐसी कुछ फ़ाइलों को --compilation_mode=opt
के साथ कंपाइल किया जा सकता है जिन्हें इकट्ठा किया जा सकता है. ऐसा तब भी किया जा सकता है, जब अच्छे से ऑप्टिमाइज़ करने की सुविधा चालू हो या ऑप्टिमाइज़ेशन की सुविधा बंद हो.
चेतावनी: अगर कुछ फ़ाइलों को डीबग सिंबल के साथ चुनिंदा रूप से इकट्ठा किया गया है, तो लिंक करने के दौरान सिंबल हटाए जा सकते हैं. इसे --strip=never
सेट करके रोका जा सकता है.
सिंटैक्स: [+-]regex[,[+-]regex]...@option[,option]...
जहां
regex
का मतलब ऐसे रेगुलर एक्सप्रेशन से है जिसे
+
के साथ शुरू किया जा सकता है, ताकि
उन पैटर्न की पहचान की जा सके जिनमें वह शामिल है. साथ ही, बाहर रखे जाने वाले पैटर्न की पहचान
करने के लिए -
का इस्तेमाल किया जा सकता है. option
का मतलब है आर्बिट्रेरी विकल्प, जो
C++ कंपाइलर को भेजा जाता है. अगर किसी विकल्प में ,
है, तो उसे इस तरह कोट किया जाना चाहिए
\,
. विकल्पों में @
भी हो सकता है, क्योंकि रेगुलर एक्सप्रेशन को विकल्पों से अलग करने के लिए, सिर्फ़ पहले
@
का इस्तेमाल किया जाता है.
उदाहरण:
--per_file_copt=//foo:.*\.cc,-//foo:file\.cc@-O0,-fprofile-arcs
//foo/
में सभी .cc
फ़ाइलों के लिए file.cc
को छोड़कर,
C++ कंपाइलर की कमांड लाइन में, -O0
और -fprofile-arcs
विकल्प जोड़ता है.
--dynamic_mode=mode
इससे यह तय होता है कि बिल्ड के नियमों पर linkstatic एट्रिब्यूट के साथ इंटरैक्ट करके, C++ बाइनरी को डाइनैमिक तौर पर लिंक किया जाएगा या नहीं.
मोड:
auto
: प्लैटफ़ॉर्म पर निर्भर मोड में बदल जाता है; Linux के लिएdefault
और साइगविन के लिएoff
.default
: bazel यह चुनने की अनुमति देता है कि डाइनैमिक तरीके से लिंक करना है या नहीं. ज़्यादा जानकारी के लिए linkstatic देखें.fully
: सभी टारगेट को डाइनैमिक तौर पर लिंक करता है. इससे, लिंक करने का समय बढ़ जाएगा और नतीजे के तौर पर जनरेट होने वाली बाइनरी का साइज़ कम हो जाएगा.off
: सभी टारगेट को ज़्यादातर स्टैटिक मोड में लिंक करता है. अगर-static
को linkopts में सेट किया गया है, तो टारगेट पूरी तरह से स्टैटिक हो जाएंगे.
--fission (yes|no|[dbg][,opt][,fastbuild])
Fission को चालू करता है, जो सिर्फ़ .o फ़ाइलों के बजाय, खास .dwo फ़ाइलों पर C++ डीबग करने की जानकारी लिखता है, जबकि दूसरी तरह से यह जा सकता है. इससे इनपुट का साइज़, लिंक तक काफ़ी कम हो जाता है और लिंक का समय कम हो सकता है.
[dbg][,opt][,fastbuild]
(उदाहरण:
--fission=dbg,fastbuild
) पर सेट करने पर, फ़ंक्शन सिर्फ़ कंपाइलेशन मोड के तय सेट के लिए चालू होता है. यह bazelrc सेटिंग
के लिए फ़ायदेमंद है. yes
पर सेट करने पर, Fission
सभी पर चालू हो जाता है. no
पर सेट करने पर, Fission
सभी पर बंद हो जाता है. डिफ़ॉल्ट वैल्यू no
है.
--force_ignore_dash_static
अगर यह फ़्लैग सेट है, तो cc_*
नियमों BUILD फ़ाइलों के linkopts में किसी भी -static
विकल्प को अनदेखा कर दिया जाता है. इसका इस्तेमाल सिर्फ़ C++ की सुरक्षा को ध्यान में रखकर किए जाने वाले
बिल्ड के लिए किया जा सकता है.
--[no]force_pic
चालू होने पर, सभी C++ कंपाइलेशन पोज़िशन-इंडिपेंडेंट कोड ("-fPIC") बनाते हैं. लिंक, बिना पीआईसी लाइब्रेरी के बजाय, पहले से बनी पीआईसी लाइब्रेरी को प्राथमिकता देते हैं. साथ ही, लिंक, रैंक पर निर्भर एक्ज़ीक्यूटेबल ("-pie") बनाते हैं. डिफ़ॉल्ट रूप से यह बंद रहता है.
--android_resource_shrinking
चुनें कि android_binary के नियमों के लिए संसाधन को छोटा करना है या नहीं. android_binary नियमों पर shrink_resources एट्रिब्यूट के लिए डिफ़ॉल्ट सेट करता है. ज़्यादा जानकारी के लिए उस नियम से जुड़े दस्तावेज़ देखें. डिफ़ॉल्ट तौर पर, यह बंद होता है.
--custom_malloc=malloc-library-target
जब बताया जाए, तब हमेशा दिए गए मैलोक इंप्लीमेंटेशन का इस्तेमाल करें. साथ ही, सभी malloc="target"
एट्रिब्यूट को ओवरराइड करें, जिनमें डिफ़ॉल्ट
का इस्तेमाल करने वाले टारगेट भी शामिल हों (malloc
के बारे में न बताते हुए).
--crosstool_top=label
यह विकल्प, क्रॉसटूल कंपाइलर सुइट की जगह के बारे में बताता है, जिसे बिल्ड के दौरान सभी C++ कंपाइलेशन के लिए इस्तेमाल किया जाता है. Bazel, CROSSTOOL फ़ाइल के लिए उस जगह
को देखेगा और उसका इस्तेमाल करके, --compiler
के लिए
अपने-आप सेटिंग तय करेगा.
--host_crosstool_top=label
अगर इसके बारे में नहीं बताया गया है, तो Bazel, होस्ट कॉन्फ़िगरेशन में कोड को कंपाइल करने के लिए, --crosstool_top
की वैल्यू का इस्तेमाल करता है. जैसे, बिल्ड के दौरान चलने वाले टूल. इस फ़्लैग का मुख्य मकसद क्रॉस-कंपाइलेशन
को चालू करना है.
--apple_crosstool_top=label
objc*, ios*, और apple* के नियमों के ट्रांज़िटिव deps
में C/C++ नियमों को कंपाइल करने के लिए इस्तेमाल किया जाने वाला क्रॉसटूल. ऐसे टारगेट के लिए, यह फ़्लैग --crosstool_top
को ओवरराइट कर देता है.
--android_crosstool_top=label
android_binary
नियमों के ट्रांज़िटिव deps
में C/C++ नियमों को कंपाइल करने के लिए इस्तेमाल किया जाने वाला क्रॉसटूल. अगर बिल्ड में अन्य टारगेट के लिए किसी
अलग क्रॉसटूल की ज़रूरत हो, तो यह काम का है. डिफ़ॉल्ट रूप से, Workspace
फ़ाइल में android_ndk_repository
नियम से जनरेट किए गए क्रॉसटूल का इस्तेमाल किया जाता है.
--fat_apk_cpu
भी देखें.
--compiler=version
यह विकल्प, C/C++ कंपाइलर वर्शन (जैसे कि gcc-4.1.0
) के बारे में बताता है, जिसका इस्तेमाल बिल्ड के दौरान बाइनरी को कंपाइल करने के लिए किया जाता है. अगर आपको कोई कस्टम क्रॉसटूल
इस्तेमाल करना है, तो इस फ़्लैग के बारे में बताने के बजाय,
आपको CROSSTOOL फ़ाइल का इस्तेमाल करना चाहिए.
--android_sdk=label
इस विकल्प से Android SDK/प्लैटफ़ॉर्म टूलचेन और Android रनटाइम लाइब्रेरी के बारे में पता चलता है. इसका इस्तेमाल Android से जुड़े किसी भी नियम को बनाने के लिए किया जाएगा.
अगर WorkspaceSPACE फ़ाइल में android_sdk_repository
नियम तय किया गया है, तो Android SDK अपने-आप चुन लिया जाएगा.
--java_toolchain=label
यह विकल्प, Java सोर्स फ़ाइलों को कंपाइल करने के लिए इस्तेमाल किए जाने वाले java_toolchain के लेबल के बारे में बताता है.
--host_java_toolchain=label
अगर इसके बारे में नहीं बताया गया है, तो bazel, होस्ट कॉन्फ़िगरेशन में कोड को कंपाइल करने के लिए --java_toolchain
की वैल्यू का इस्तेमाल करता है. जैसे, बिल्ड के दौरान चलने वाले टूल के लिए. इस फ़्लैग का मुख्य मकसद क्रॉस-कंपाइलेशन
को चालू करना है.
--javabase=(label)
यह विकल्प, बेस Java इंस्टॉलेशन के लेबल को सेट करता है, ताकि bazel Run, bazel जांच, और java_binary
औरjava_test
नियमों के मुताबिक बनाई गई Java बाइनरी फ़ाइल के लिए, उसका इस्तेमाल किया जा सके. JAVABASE
और JAVA
"Make" वैरिएबल को इस विकल्प से लिया जाता है.
--host_javabase=label
यह विकल्प, बेस Java इंस्टॉलेशन का लेबल सेट करता है, ताकि उसे होस्ट कॉन्फ़िगरेशन में इस्तेमाल किया जा सके. उदाहरण के लिए, JavaBuilder और Singlejar जैसे होस्ट बिल्ड टूल के लिए.
यह Java कंपाइलर को नहीं चुनता, जिसका इस्तेमाल Java सोर्स फ़ाइलों को कंपाइल करने के लिए किया जाता है. कंपाइलर को,
--java_toolchain
विकल्प की सेटिंग में जाकर चुना जा सकता है.
प्लान लागू करने की रणनीति
इन विकल्पों से इस बात पर असर पड़ता है कि Bazel, बिल्ड को कैसे एक्ज़ीक्यूट करेगा. बिल्ड से जनरेट की गई आउटपुट फ़ाइलों पर इनका कोई खास असर नहीं होना चाहिए. आम तौर पर, उनका मुख्य असर बिल्ड की रफ़्तार पर होता है.
--spawn_strategy=strategy
इस विकल्प से यह कंट्रोल होता है कि निर्देश कहां और कैसे लागू किए जाते हैं.
standalone
की वजह से कमांड, लोकल सबप्रोसेस के तौर पर एक्ज़ीक्यूट होते हैं. यह मान अब सेवा में नहीं है. इसके बजाय, कृपयाlocal
का इस्तेमाल करें.sandboxed
की वजह से, लोकल मशीन पर सैंडबॉक्स में कमांड एक्ज़ीक्यूट होते हैं. इसके लिए ज़रूरी है कि सभी इनपुट फ़ाइलें, डेटा डिपेंडेंसी, और टूलsrcs
,data
, औरtools
एट्रिब्यूट में डायरेक्ट डिपेंडेंसी के तौर पर शामिल हों. Bazel डिफ़ॉल्ट रूप से, लोकल सैंडबॉक्सिंग की सुविधा को उन सिस्टम पर चालू करता है जो सैंडबॉक्स किए गए एक्ज़ीक्यूशन की सुविधा देते हैं.local
की वजह से कमांड, लोकल सबप्रोसेस के तौर पर एक्ज़ीक्यूट होते हैं.- उपलब्ध होने पर,
worker
किसी स्थायी वर्कर का इस्तेमाल करके कमांड लागू करता है. docker
की वजह से, लोकल मशीन पर डॉकर सैंडबॉक्स में कमांड एक्ज़ीक्यूट किए जाते हैं. इसके लिए ज़रूरी है कि डॉकर इंस्टॉल किया गया हो.remote
, कमांड को रिमोट तरीके से एक्ज़ीक्यूट करता है; यह सिर्फ़ तब उपलब्ध होता है, जब रिमोट एक्ज़ीक्यूटर को अलग से कॉन्फ़िगर किया गया हो.
--strategy mnemonic=strategy
इस विकल्प से यह कंट्रोल किया जाता है कि कमांड कहां और कैसे लागू किए जाएंगे. साथ ही, यह हर मिनट के आधार पर --spawn_strategy (और --genrule_strategy के साथ mnemonic जेनरूल) को बदल देता है. इस्तेमाल की जा सकने वाली रणनीतियों और उनके असर के बारे में जानने के लिए, --spawn_strategy देखें.
--strategy_regexp=<filter,filter,...>=<strategy>
इस विकल्प से यह तय किया जाता है कि किसी regex_filter
से मेल खाने वाले निर्देशों को लागू करने के लिए, किस रणनीति का इस्तेमाल किया जाना चाहिए. रेगुलर एक्सप्रेशन फ़िल्टर मैच करने के बारे में जानने के लिए,
--per_file_copt
देखें. इस्तेमाल की जा सकने वाली रणनीतियों और उनके असर के बारे में जानने के लिए,
--spawn_strategy देखें.
ब्यौरे से मेल खाने वाले आखिरी regex_filter
का इस्तेमाल किया जाता है. यह विकल्प रणनीति तय करने के लिए
अन्य फ़्लैग को बदल देता है.
- उदाहरण:
--strategy_regexp=//foo.*\\.cc,-//foo/bar=local
का मतलब,local
रणनीति का इस्तेमाल करके कार्रवाइयां चलाना है. ऐसा तब होता है, जब जानकारी //foo.*.cc से मेल खाती है, लेकिन //foo/bar से नहीं. - उदाहरण:
--strategy_regexp='Compiling.*/bar=local' --strategy_regexp=Compiling=sandboxed
sandboxed
रणनीति के साथ 'Compiling //foo/bar/baz' चलाता है, लेकिन ऑर्डर रिवर्स करने से,local
के साथ चलता है. - उदाहरण:
--strategy_regexp='Compiling.*/bar=local,sandboxed'
, '//foo/Bar/baz' कोlocal
रणनीति के साथ चलाता है और काम न करने पर,sandboxed
पर वापस चला जाता है.
--genrule_strategy=strategy
यह --strategy=Genrule=strategy
के लिए शॉर्ट-हैंड की तरह इस्तेमाल नहीं किया जाता है.
--jobs=n
(-j)
एक पूर्णांक तर्क वाला यह विकल्प, उन जॉब की संख्या की सीमा तय करता है जिन्हें बिल्ड के एक्ज़ीक्यूट होने के चरण के दौरान एक साथ चलाया जाना चाहिए.
--progress_report_interval=n
Bazel समय-समय पर उन जॉब की प्रोग्रेस रिपोर्ट प्रिंट करता है जो अभी तक पूरी नहीं हुई हैं (जैसे कि लंबे समय तक चलने वाले टेस्ट). इस विकल्प से रिपोर्टिंग फ़्रीक्वेंसी सेट हो जाती है. प्रोग्रेस को हर n
सेकंड में प्रिंट किया जाएगा.
डिफ़ॉल्ट 0 है, यानी कि एक इंंक्रीमेंटल एल्गोरिदम: पहली रिपोर्ट 10 सेकंड बाद, फिर 30 सेकंड बाद प्रिंट की जाएगी. इसके बाद, प्रोग्रेस को हर मिनट में एक बार रिपोर्ट किया जाएगा.
जब बेज़ेल, कर्सर कंट्रोल का इस्तेमाल कर रहा हो, जैसा कि --curses
में बताया गया है, तब प्रोग्रेस की रिपोर्ट हर सेकंड दी जाती है.
--local_{ram,cpu}_resources resources or resource expression
ये विकल्प तय करते हैं कि स्थानीय संसाधनों की संख्या (एमबी में रैम और सीपीयू लॉजिकल कोर की संख्या) कितनी है. बिल्ड और टेस्ट गतिविधियों को स्थानीय तौर पर चलाने के लिए शेड्यूल करते समय Bazel ध्यान में रख सकता है. ये एक पूर्णांक या एक कीवर्ड (Host_RAM या Host_CPUS) लेते हैं, जिसके बाद [-|*
फ़्लोट]
(उदाहरण के लिए, --local_cpu_resources=2
, --local_ram_resources=HOST_RAM*.5
, और --local_cpu_resources=HOST_CPUS-1
) ज़रूरी नहीं होता है.
फ़्लैग अलग-अलग होते हैं; एक या दोनों सेट किए जा सकते हैं. डिफ़ॉल्ट रूप से, Bazel सीधे लोकल सिस्टम के कॉन्फ़िगरेशन से रैम की मात्रा और सीपीयू (CPU) की संख्या का अनुमान लगाता है.
--[no]build_runfile_links
यह विकल्प डिफ़ॉल्ट रूप से चालू होता है. इससे पता चलता है कि टेस्ट और बाइनरी के लिए रनफ़ाइल सिमलिंक, आउटपुट डायरेक्ट्री में बनाए जाने चाहिए या नहीं.
--nobuild_runfile_links
का इस्तेमाल करके यह पुष्टि की जा सकती है कि रनफ़ाइल ट्री बनाने के लिए, ऊपर से खर्च किए बिना सभी टारगेट कंपाइल किए जाते हैं या नहीं.
जब टेस्ट (या ऐप्लिकेशन) चलाए जाते हैं, तो उनकी रन-टाइम डेटा डिपेंडेंसी एक ही जगह इकट्ठा होती है. Bazel के आउटपुट ट्री में,
यह "रनफ़ाइल" ट्री है. इसे आम तौर पर, इससे जुड़े बाइनरी या टेस्ट
के सिबलिंग के तौर पर रूट किया जाता है.
जांच करने के दौरान, रनफ़ाइलों को $TEST_SRCDIR/workspace/packagename/filename
फ़ॉर्म के पाथ से ऐक्सेस किया जा सकता है.
रनफ़ाइल ट्री यह पक्का करता है कि टेस्ट के पास उन सभी फ़ाइलों का ऐक्सेस हो
जिन पर उनकी तय की गई निर्भरता है. इसके अलावा, और कुछ नहीं. डिफ़ॉल्ट रूप से, रनफ़ाइल ट्री को ज़रूरी फ़ाइलों के लिए सिमबॉलिक लिंक का सेट तैयार करके लागू किया जाता है. जैसे-जैसे लिंक का सेट बढ़ता है, वैसे-वैसे
इस काम की लागत भी बढ़ती जाती है. साथ ही, कुछ बड़े बिल्ड के लिए यह
बिल बनने में लगने वाले कुल समय में अहम योगदान दे सकता है.
खास तौर पर इसलिए, क्योंकि हर एक टेस्ट (या ऐप्लिकेशन) के लिए अपना रनफ़ाइल ट्री होता है.
--[no]build_runfile_manifests
यह विकल्प, डिफ़ॉल्ट रूप से चालू होता है. इससे यह तय होता है कि रनफ़ाइल मेनिफ़ेस्ट को आउटपुट ट्री में लिखा जाना चाहिए या नहीं.
इसे बंद करने का मतलब है कि --nobuild_runfile_links
.
रिमोट तरीके से भी टेस्ट लागू करते समय, इसे बंद किया जा सकता है, क्योंकि रनफ़ाइल ट्री इन-मेमोरी मेनिफ़ेस्ट की मदद से रिमोट तरीके से बनाए जाते हैं.
--[no]discard_analysis_cache
यह विकल्प चालू होने पर, Bazel प्रोसेस शुरू होने से ठीक पहले, विश्लेषण की कैश मेमोरी को खारिज कर देगा. इससे एक्ज़ीक्यूशन फ़ेज़ के लिए, ज़्यादा मेमोरी (करीब 10%) खाली हो जाएगी. इसकी कमी यह है कि इसके बाद के बिल्ड की प्रोसेस धीमी हो जाएगी. मेमोरी सेव करने वाला मोड भी देखें.
--[no]keep_going
(-k)
GNU Make की तरह, पहली गड़बड़ी मिलने पर बिल्ड का निष्पादन चरण रुक जाता है. कभी-कभी गड़बड़ियों का सामना करते हुए भी जितना हो सके उतना बनाने की कोशिश करना मददगार होता है. इस विकल्प से वह तरीका चालू होता है. इसे तय करने पर, बिल्ड हर उस टारगेट को बनाने की कोशिश करेगा जिसकी ज़रूरी शर्तें पूरी हो गई थीं. हालांकि, यह गड़बड़ियों को अनदेखा कर देगा.
हालांकि, यह विकल्प आम तौर पर बिल्ड के एक्ज़ीक्यूशन चरण से जुड़ा होता है, लेकिन यह विश्लेषण के चरण पर भी असर डालता है: अगर बिल्ड कमांड में कई टारगेट तय किए गए हों, लेकिन उनमें से सिर्फ़ कुछ का ही
सही विश्लेषण किया जा सकता हो, तो जब तक --keep_going
तय नहीं किया जाएगा, तब तक बिल्ड गड़बड़ी के साथ बंद रहेगा. ऐसे में बिल्ड, एक्ज़ीक्यूशन के लिए आगे बढ़ेगा, लेकिन सिर्फ़ उन टारगेट के लिए जिनका सही तरीके से विश्लेषण किया जा चुका है.
--[no]use_ijars
यह विकल्प, Bazel के लिए java_library
टारगेट को इकट्ठा करने का तरीका बदल देता है. डिपेंडेंट java_library
टारगेट को कंपाइल करने के लिए, java_library
के आउटपुट का इस्तेमाल करने के बजाय, Bazel ऐसे इंटरफ़ेस जार बनाएगा जिनमें सिर्फ़ गैर-निजी सदस्यों (सार्वजनिक, सुरक्षित, और डिफ़ॉल्ट (पैकेज) ऐक्सेस करने के तरीकों और फ़ील्ड के हस्ताक्षर शामिल होंगे. साथ ही, डिपेंडेंट टारगेट को कंपाइल करने के लिए इंटरफ़ेस जार का इस्तेमाल करेंगे. इसकी मदद से, सिर्फ़ मेथड बॉडी या क्लास के निजी सदस्यों में किए जाने वाले बदलावों को दोबारा कंपाइल करने से बचा जा सकता है.
--[no]interface_shared_objects
इस विकल्प से इंटरफ़ेस शेयर किए गए ऑब्जेक्ट चालू होते हैं. इससे बाइनरी और शेयर की गई अन्य लाइब्रेरी, लागू करने के बजाय शेयर किए गए ऑब्जेक्ट के इंटरफ़ेस पर निर्भर करती हैं. जब सिर्फ़ लागू करने के तरीके में बदलाव होता है, तो Bazel फिर से ऐसे टारगेट बनाने से बच सकता है जो बेहद बदली गई शेयर लाइब्रेरी पर निर्भर होते हैं.
आउटपुट चुनना
इन विकल्पों से यह तय होता है कि क्या बनाना है या क्या टेस्ट करना है.
--[no]build
इस विकल्प से बिल्ड का एक्ज़ीक्यूशन फ़ेज़ शुरू होता है; यह डिफ़ॉल्ट रूप से चालू रहता है. जब इसे बंद किया जाता है, तो एक्ज़ीक्यूशन चरण छोड़ दिया जाता है और लोडिंग और विश्लेषण के केवल पहले दो चरण होते हैं.
यह विकल्प BUILD फ़ाइलों की पुष्टि करने और इनपुट में गड़बड़ियों का पता लगाने के लिए काम का हो सकता है, वह भी बिना कुछ बनाए.
--[no]build_tests_only
अगर जानकारी दी गई है, तो Bazel सिर्फ़ वही कॉन्टेंट बनाएगा जो *_test
और test_suite
नियमों को चलाने के लिए ज़रूरी है. इन नियमों को उनके साइज़, समय खत्म, टैग या भाषा की वजह से फ़िल्टर नहीं किया गया था.
बताए जाने पर, Bazel कमांड लाइन में दिए गए अन्य टारगेट को अनदेखा कर देगा.
डिफ़ॉल्ट रूप से, यह विकल्प बंद होता है और Bazel
उन सभी चीज़ों को तैयार करेगा जिनका अनुरोध किया गया है. इसमें *_test
और test_suite
नियम भी शामिल हैं, जिन्हें
टेस्टिंग से फ़िल्टर कर दिया गया है. यह काम का है, क्योंकि शायद bazel test --build_tests_only foo/...
को चलाने से, foo
ट्री में सभी बिल्ड ब्रेक का पता न चले.
--[no]check_up_to_date
इस विकल्प से Bazel बिल्ड नहीं कर पाता है, बल्कि सिर्फ़ जांच करता है कि बताए गए सभी टारगेट अप-टू-डेट हैं या नहीं. अगर ऐसा है, तो बिल्ड सामान्य तरीके से पूरा हो जाता है. हालांकि, अगर कोई फ़ाइल पुरानी होने की वजह से, पुरानी हो जाती है, तो गड़बड़ी की शिकायत की जाती है और बिल्ड फ़ेल हो जाता है. इस विकल्प से यह पता लगाया जा सकता है कि सोर्स में बदलाव (उदाहरण के लिए, सबमिट करने से पहले की जांच) के मुकाबले, किसी बिल्ड पर हाल ही में कार्रवाई हुई है या नहीं. ऐसा करने से, बिल्ड पर होने वाले खर्च की ज़रूरत नहीं पड़ती.
--check_tests_up_to_date
भी देखें.
--[no]compile_one_dependency
आर्ग्युमेंट फ़ाइलों की एक डिपेंडेंसी कंपाइल करें. यह IDE में सोर्स फ़ाइलों की जांच करने के लिए सिंटैक्स के लिए फ़ायदेमंद है. उदाहरण के लिए, बदलाव/बिल्ड/टेस्ट साइकल में गड़बड़ियों का जल्द से जल्द पता लगाने के लिए, सोर्स फ़ाइल पर निर्भर किसी एक टारगेट को फिर से बनाना. इस आर्ग्युमेंट का असर, फ़्लैग नहीं करने वाले सभी आर्ग्युमेंट के बारे में बताने के तरीके पर पड़ता है: हर आर्ग्युमेंट, फ़ाइल का टारगेट लेबल या काम करने वाली मौजूदा डायरेक्ट्री से जुड़ा एक सादा फ़ाइल नाम होना चाहिए. साथ ही, हर सोर्स फ़ाइल नाम के हिसाब से एक नियम बनाया जाना चाहिए. इसके लिए:
C++ और Java सोर्स, तो एक ही लैंग्वेज स्पेस के नियमों को प्राथमिकता से चुना जाता है. समान प्राथमिकता वाले कई नियमों के लिए, BUILD फ़ाइल में सबसे पहले दिखने वाले नियमों को चुना जाता है. किसी सोर्स फ़ाइल का रेफ़रंस न देने वाले टारगेट पैटर्न का इस्तेमाल करने से गड़बड़ी हो सकती है.
--save_temps
--save_temps
विकल्प की वजह से, कंपाइलर से कुछ समय के लिए मिलने वाले आउटपुट सेव हो जाते हैं. इनमें .s फ़ाइलें (असेंबलर कोड), .i (पहले से प्रोसेस की गई C) और .ii (पहले से प्रोसेस की गई C++) फ़ाइलें शामिल हैं. ये आउटपुट, अक्सर डीबग करने में मदद करते हैं. तापमान सिर्फ़ कमांड लाइन पर तय किए गए टारगेट के सेट के लिए जनरेट किए जाएंगे.
फ़िलहाल, --save_temps
फ़्लैग सिर्फ़ cc_* नियमों के लिए काम करता है.
यह पक्का करने के लिए कि Bazel अतिरिक्त आउटपुट फ़ाइलों की जगह की जानकारी को प्रिंट करे, देख लें कि
आपकी --show_result n
सेटिंग ज़रूरत के मुताबिक हो.
--build_tag_filters=tag[,tag]*
तय किए जाने पर, Bazel सिर्फ़ ऐसे टारगेट बनाएगा जिनमें कम से कम एक ज़रूरी टैग होगा और उनमें कोई बाहर रखा गया टैग नहीं होगा. बिल्ड टैग फ़िल्टर को टैग कीवर्ड की कॉमा-डीलिमिटेड सूची के तौर पर दिखाया जाता है. वैकल्पिक रूप से, इसके पहले '-' निशान का इस्तेमाल किया जाता है. इसका इस्तेमाल बाहर रखे गए टैग को दिखाने के लिए किया जाता है. ज़रूरी टैग में '+' का निशान पहले से हो सकता है.
टेस्ट चलाते समय, Bazel, टेस्ट टारगेट के लिए --build_tag_filters
को अनदेखा कर देता है. ये ऐसे टारगेट होते हैं जिन्हें बनाया और चलाया जाता है, भले ही वे इस फ़िल्टर से मैच न करते हों. ऐसा न हो, इसके लिए --test_tag_filters
का इस्तेमाल करके या साफ़ तौर पर बाहर रखकर,
टेस्ट टारगेट को फ़िल्टर करें.
--test_size_filters=size[,size]*
अगर बताया गया है, तो Bazel सिर्फ़ दिए गए साइज़ वाले टारगेट की जांच करेगा (या अगर --build_tests_only
बताया गया है, तो बनाएगा). टेस्ट साइज़ फ़िल्टर
को, इस्तेमाल की जा सकने वाली टेस्ट साइज़ वैल्यू (छोटे, मीडियम, बड़ा या बहुत ज़्यादा) की कॉमा डिलिमिटेड लिस्ट के तौर पर बताया गया है. वैकल्पिक रूप से, इसके पहले '-' निशान लगा होता है. उदाहरण के लिए,
% bazel test --test_size_filters=small,medium //foo:all
और
% bazel test --test_size_filters=-large,-enormous //foo:all
//foo के अंदर केवल छोटे और मध्यम परीक्षणों का परीक्षण करेगा.
डिफ़ॉल्ट रूप से, टेस्ट साइज़ को फ़िल्टर करने की सुविधा लागू नहीं होती.
--test_timeout_filters=timeout[,timeout]*
तय किए जाने पर, Bazel सिर्फ़ दिए गए टाइम आउट वाले टारगेट की जांच करेगा (या अगर --build_tests_only
बताया गया है, तो यह बनाएगा). टेस्ट टाइम आउट फ़िल्टर
को, इस्तेमाल किए जा सकने वाले जांच के टाइम आउट की वैल्यू (कम, सामान्य, ज़्यादा या लगातार) की कॉमा से डीलिमिटेड सूची के तौर पर दिखाया जाता है. वैकल्पिक रूप से, इसके पहले '-' निशान लगा होता है. इसका इस्तेमाल करके, टाइम आउट को
शामिल नहीं किया जाता. सिंटैक्स के उदाहरण के लिए --test_size_filters देखें.
डिफ़ॉल्ट रूप से, जांच के टाइम आउट को फ़िल्टर करने की सुविधा लागू नहीं होती.
--test_tag_filters=tag[,tag]*
तय किए जाने पर, Bazel सिर्फ़ उन टारगेट की जांच करेगा (या अगर --build_tests_only
तय किया गया है, तो बना) जिनमें कम से कम एक ज़रूरी टैग मौजूद हो
और उसमें बाहर रखे गए कोई टैग मौजूद न हो. टेस्ट टैग फ़िल्टर को, टैग कीवर्ड की कॉमा से डीलिमिटेड सूची के तौर पर दिखाया जाता है. वैकल्पिक रूप से, इसके पहले '-' निशान का इस्तेमाल किया जाता है. इसका इस्तेमाल बाहर रखे गए टैग को दिखाने के लिए किया जाता है. ज़रूरी टैग में '+' का निशान पहले से हो सकता है.
उदाहरण के लिए,
% bazel test --test_tag_filters=performance,stress,-flaky //myproject:all
उन टारगेट की जांच करेगा जो performance
या
stress
टैग से टैग किए गए हैं, लेकिन flaky
टैग के साथ टैग नहीं किए गए हैं.
डिफ़ॉल्ट रूप से, टेस्ट टैग फ़िल्टर करने की सुविधा लागू नहीं होती. ध्यान दें कि इस तरह से टेस्ट के size
और local
टैग पर भी फ़िल्टर लगाया जा सकता है.
--test_lang_filters=lang[,lang]*
इसमें उन भाषाओं के लिए कॉमा लगाकर अलग की गई भाषाओं की सूची होती है जिनमें आधिकारिक *_test
नियम होता है
(इनकी पूरी सूची देखने के लिए एन्साइक्लोपीडिया बनाएं देखें). बाहर रखी गई भाषाओं के बारे में बताने के लिए, हर भाषा के पहले '-' दिया जा सकता है. हर भाषा के लिए इस्तेमाल किया गया नाम, *_test
नियम में
भाषा के प्रीफ़िक्स से मेल खाना चाहिए. उदाहरण के लिए,
cc
, java
या sh
.
अगर बताया गया है, तो Bazel सिर्फ़ तय की गई भाषा (भाषाओं) के टारगेट की जांच करेगा(अगर --build_tests_only
बताया गया है, तो बना भी देगा).
उदाहरण के लिए,
% bazel test --test_lang_filters=cc,java foo/...
foo/...
में सिर्फ़ C/C++ और Java टेस्ट (क्रमश: cc_test
और java_test
नियमों का इस्तेमाल करके तय किए गए) की जांच करेगा, जबकि
% bazel test --test_lang_filters=-sh,-java foo/...
sh_test
और java_test
टेस्ट को छोड़कर, सभी टेस्ट foo/...
में चलाए जाएंगे.
डिफ़ॉल्ट रूप से, जांच के लिए भाषा को फ़िल्टर करने की सुविधा लागू नहीं होती.
--test_filter=filter-expression
इस फ़िल्टर को इस्तेमाल करता है. टेस्ट रनर इसका इस्तेमाल करके, दौड़ने के लिए टेस्ट का सबसेट चुन सकता है. बातचीत में बताए गए सभी टारगेट बनाए जाते हैं, लेकिन एक्सप्रेशन के आधार पर, उनमें से सिर्फ़ कुछ को ही एक्ज़ीक्यूट किया जा सकता है; कुछ मामलों में, टेस्ट के कुछ ही तरीके चलाए जाते हैं.
filter-expression की खास परिभाषा,
टेस्ट को चलाने वाले टेस्ट फ़्रेमवर्क पर निर्भर करती है. यह ग्लोब, सबस्ट्रिंग या रेगुलर एक्सप्रेशन
हो सकता है. --test_arg
के अलग-अलग फ़िल्टर आर्ग्युमेंट को पास करने पर, --test_filter
का इस्तेमाल किया जा सकता है. हालांकि, सभी फ़्रेमवर्क इस सुविधा के साथ काम नहीं करते.
कितने शब्दों में जानकारी दी जाए
ये विकल्प, Bazel के आउटपुट की वर्बोसिटी को कंट्रोल करते हैं. फिर चाहे, तो टर्मिनल पर या दूसरी लॉग फ़ाइलों पर जाना हो.
--explain=logfile
इस विकल्प के लिए फ़ाइल नाम वाला आर्ग्युमेंट ज़रूरी होता है. इसकी वजह से, bazel build
के एक्ज़ीक्यूशन फ़ेज़ में मौजूद डिपेंडेंसी चेकर, हर बिल्ड चरण के लिए यह बताता है कि इसे एक्ज़ीक्यूट क्यों किया जा रहा है या यह अप-टू-डेट है. इसकी जानकारी logfile
पर लिखी गई है.
अगर आपको अनचाहे तरीके से फिर से बनाया जा रहा है, तो यह विकल्प उसकी वजह समझने में मदद कर सकता है. इसे अपने .bazelrc
में जोड़ें, ताकि बाद के सभी बिल्ड में लॉग इन हो सके. इसके बाद, जब आपको एक्ज़ीक्यूशन चरण अचानक लागू किया गया दिखे, तो लॉग की जांच करें. इस विकल्प से परफ़ॉर्मेंस पर थोड़ी-बहुत कार्रवाई हो सकती है, इसलिए ज़रूरत न होने पर इसे हटा दें.
--verbose_explanations
यह विकल्प, --एक्सप्लेनेशंस के चालू होने पर, जनरेट की गई जानकारी को ज़्यादा शब्दों में दिखाता है.
खास तौर पर, अगर वर्बोस एक्सप्लेनेशंस को चालू किया जाता है और आउटपुट फ़ाइल को फिर से बनाया जाता है, क्योंकि इसे बनाने के लिए इस्तेमाल किए गए कमांड में बदलाव होता है, तो एक्सप्लेनेशन फ़ाइल के आउटपुट में नए कमांड की पूरी जानकारी शामिल होगी (कम से कम ज़्यादातर कमांड के लिए).
इस विकल्प का इस्तेमाल करने से, जनरेट की गई एक्सप्लेनेशन फ़ाइल की लंबाई और --explain
का इस्तेमाल करने पर परफ़ॉर्मेंस पेनल्टी बढ़ सकती है.
अगर --explain
चालू नहीं है, तो
--verbose_explanations
का कोई असर नहीं होगा.
--profile=file
यह विकल्प, जो फ़ाइल नाम वाला आर्ग्युमेंट इस्तेमाल करता है, उसकी वजह से बज़ल एक फ़ाइल में
प्रोफ़ाइलिंग डेटा लिखता है. इसके बाद, bazel analyze-profile
कमांड का इस्तेमाल करके, डेटा का विश्लेषण किया जा सकता है या उसे पार्स किया जा सकता है. बिल्ड प्रोफ़ाइल से यह समझने में मदद मिल सकती है कि Bazel का build
कमांड अपना समय कहां खर्च कर रहा है.
--[no]show_loading_progress
इस विकल्प से Bazel, पैकेज लोड होने की प्रोग्रेस से जुड़े मैसेज दिखाता है. अगर यह सुविधा बंद है, तो मैसेज नहीं दिखाए जाएंगे.
--[no]show_progress
इस विकल्प से प्रोग्रेस मैसेज दिखते हैं; यह डिफ़ॉल्ट रूप से चालू रहता है. बंद होने पर, प्रोग्रेस मैसेज छिपा दिए जाते हैं.
--show_progress_rate_limit=n
इस विकल्प से, bazel हर n
सेकंड में ज़्यादा से ज़्यादा एक प्रोग्रेस का मैसेज दिखाता है. यहां n एक असली संख्या है.
इस विकल्प के लिए डिफ़ॉल्ट वैल्यू 0.02 है. इसका मतलब है कि bazel हर 0.02 सेकंड में, प्रोग्रेस के एक मैसेज को एक तक सीमित कर देगा.
--show_result=n
इस विकल्प से यह कंट्रोल किया जाता है कि bazel build
कमांड के आखिर में, नतीजे की जानकारी को प्रिंट किया जाए या नहीं. डिफ़ॉल्ट रूप से, अगर सिर्फ़ एक बिल्ड टारगेट तय किया गया था, तो Bazel एक मैसेज प्रिंट करता है. इसमें बताया जाता है कि टारगेट अप-टू-डेट हुआ या नहीं. अगर ऐसा है, तो टारगेट से बनाई गई आउटपुट फ़ाइलों की सूची. अगर एक से ज़्यादा टारगेट तय किए गए हैं, तो नतीजे की जानकारी नहीं दिखाई जाती.
हालांकि, नतीजे की जानकारी एक या कुछ टारगेट बनाने के लिए काम की हो सकती है, लेकिन बड़े बिल्ड (जैसे कि पूरा टॉप-लेवल प्रोजेक्ट ट्री) के लिए, यह जानकारी परेशान और ध्यान भटकाने वाली हो सकती है;
इस विकल्प से इसे कंट्रोल किया जा सकता है. --show_result
एक पूर्णांक तर्क लेता है. यह टारगेट की वह ज़्यादा से ज़्यादा संख्या होता है जिसके लिए
नतीजों की पूरी जानकारी प्रिंट की जानी चाहिए. डिफ़ॉल्ट रूप से,
वैल्यू 1 है. इस थ्रेशोल्ड से ऊपर, अलग-अलग टारगेट के लिए
नतीजे की कोई जानकारी नहीं दिखाई जाती है. इस तरह, शून्य नतीजे
की जानकारी को हमेशा छिपा दिया जाता है और
बहुत ज़्यादा वैल्यू की वजह से
नतीजे को हमेशा प्रिंट किया जाता है.
अगर उपयोगकर्ता, टारगेट के छोटे ग्रुप (उदाहरण के लिए, कंपाइल-एडिट-टेस्ट साइकल के दौरान) और टारगेट के बड़े ग्रुप (उदाहरण के लिए, नया फ़ाइल फ़ोल्डर सेट अप करते समय या रिग्रेशन टेस्ट
चलाना) के बीच नियमित तौर पर विकल्प चुनते हैं, तो हो सकता है कि वे इनके बीच में कोई वैल्यू चुनना चाहें. पिछले मामले में, नतीजे की जानकारी बहुत काम की होती है, जबकि बाद वाले मामले में यह कम काम की होती है. सभी विकल्पों की तरह ही, इसे .bazelrc
फ़ाइल की मदद से, बिना किसी अंतर के बताया जा सकता है.
फ़ाइलों को प्रिंट किया जाता है, ताकि बनाए गए एक्ज़ीक्यूटेबल चलाने के लिए, फ़ाइल नाम को कॉपी करके शेल में आसानी से चिपकाया जा सके. हर टारगेट के लिए, "अप-टू-डेट" या "पुष्टि नहीं हो सकी" मैसेज को, स्क्रिप्ट से आसानी से पार्स किया जा सकता है.
--sandbox_debug
इस विकल्प की वजह से सैंडबॉक्सिंग की मदद से काम करने के दौरान, Bazel डीबग करने की ज़्यादा जानकारी प्रिंट करता है. यह विकल्प सैंडबॉक्स डायरेक्ट्री को भी सुरक्षित रखता है, ताकि एक्ज़ीक्यूशन के दौरान कार्रवाइयों को दिखने वाली फ़ाइलों की जांच की जा सके.
--subcommands
(-s
)
इस विकल्प की वजह से, Bazel का एक्ज़ीक्यूशन फ़ेज़, हर कमांड को लागू करने से पहले, उसके लिए पूरी कमांड लाइन प्रिंट कर देता है.
>>>>> # //examples/cpp:hello-world [action 'Linking examples/cpp/hello-world'] (cd /home/johndoe/.cache/bazel/_bazel_johndoe/4c084335afceb392cfbe7c31afee3a9f/bazel && \ exec env - \ /usr/bin/gcc -o bazel-out/local-fastbuild/bin/examples/cpp/hello-world -B/usr/bin/ -Wl,-z,relro,-z,now -no-canonical-prefixes -pass-exit-codes -Wl,-S -Wl,@bazel-out/local_linux-fastbuild/bin/examples/cpp/hello-world-2.params)
जहां भी संभव हो, निर्देश बॉर्न शेल के साथ काम करने वाले सिंटैक्स में प्रिंट किए जाते हैं,
ताकि उन्हें आसानी से कॉपी किया जा सके और शेल कमांड प्रॉम्प्ट में चिपकाया जा सके.
(आस-पास मौजूद ब्रैकेट, आपके शेल को
cd
और exec
कॉल से सुरक्षित रखने के लिए दिए गए हैं; उन्हें कॉपी करना न भूलें!)
हालांकि, कुछ निर्देश Bazel में अंदरूनी तौर पर लागू किए जाते हैं, जैसे कि
सिमलिंक ट्री बनाना. इनके लिए कोई कमांड लाइन नहीं होती.
कमांड के आर्ग्युमेंट को एक लाइन के बजाय, सूची के तौर पर प्रिंट करने के लिए, --subcommands=pretty_print
को पास किया जा सकता है. इससे लंबी कमांड लाइन को पढ़ने में आसान बनाने में मदद मिल सकती है.
नीचे --verbose_failures डालें.
टूल-फ़्रेंडली फ़ॉर्मैट वाली फ़ाइल में सबकमांड लॉग करने के लिए, --execution_log_json_file और --execution_log_binary_file देखें.
--verbose_failures
इस विकल्प की वजह से Bazel का एक्ज़ीक्यूशन फ़ेज़, उन कमांड के लिए पूरी कमांड लाइन प्रिंट करता है जो सफल नहीं होते. फ़ेल हो रहे बिल्ड को डीबग करने के लिए यह ज़रूरी हो सकता है.
काम न करने वाले निर्देश बॉर्न शेल के साथ काम करने वाले सिंटैक्स में प्रिंट किए जाते हैं. इन्हें कॉपी करके शेल प्रॉम्प्ट पर चिपकाया जा सकता है.
वर्कस्पेस की स्थिति
Bazel से बनी बाइनरी को "स्टैंप" करने के लिए, इन विकल्पों का इस्तेमाल करें: अतिरिक्त जानकारी को बाइनरी में एम्बेड करने के लिए, जैसे कि सोर्स कंट्रोल में बदलाव करना या फ़ाइल फ़ोल्डर से जुड़ी अन्य जानकारी. इस तरीके का इस्तेमाल, stamp
एट्रिब्यूट के साथ काम करने वाले नियमों के साथ किया जा सकता है. जैसे, genrule
, cc_binary
वगैरह.
--workspace_status_command=program
इस फ़्लैग से आप एक बाइनरी तय कर सकते हैं, जिसे Bazel हर बिल्ड से पहले चलाता है. यह प्रोग्राम, फ़ाइल फ़ोल्डर की स्थिति के बारे में जानकारी रिपोर्ट कर सकता है, जैसे कि मौजूदा सोर्स कंट्रोल में किया गया बदलाव.
फ़्लैग की वैल्यू, नेटिव प्रोग्राम का पाथ होनी चाहिए. Linux/macOS पर, इसे एक्ज़ीक्यूटेबल किया जा सकता है. Windows पर, यह नेटिव बाइनरी होनी चाहिए. आम तौर पर, इसमें ".exe", ".bat" या ".cmd" फ़ाइल का इस्तेमाल किया जा सकता है.
प्रोग्राम को स्टैंडर्ड आउटपुट में शून्य या उससे ज़्यादा कुंजी/वैल्यू पेयर प्रिंट करने चाहिए. हर लाइन पर एक एंट्री डालें और शून्य के साथ बाहर निकलें. ऐसा न करने पर बिल्ड काम नहीं करेगा. कुंजी के नाम कुछ भी हो सकते हैं, लेकिन उनमें सिर्फ़ अंग्रेज़ी के बड़े अक्षरों और अंडरस्कोर का इस्तेमाल किया जा सकता है. कुंजी के नाम के बाद पहला स्पेस, उसे वैल्यू से अलग करता है. वैल्यू बाकी लाइन है (अतिरिक्त खाली सफ़ेद जगहों के साथ). न तो कुंजी और न ही वैल्यू एक से ज़्यादा लाइनों में हो सकती है. कुंजियों की डुप्लीकेट कॉपी नहीं बनाई जानी चाहिए.
Bazel, कुंजियों को दो बकेट में बांटता है: "स्टेबल" और "वोलाटाइल". ("स्टेबल" और "वोलाटाइल" नाम थोड़ा मुश्किल है. इसलिए, इनके बारे में ज़्यादा न सोचें.)
इसके बाद, Bazel दो फ़ाइलों में की-वैल्यू पेयर को लिखता है:
bazel-out/stable-status.txt
इसमें वे सभी कुंजियां और वैल्यू शामिल होती हैं जहां कुंजी का नामSTABLE_
से शुरू होता हैbazel-out/volatile-status.txt
इसमें बाकी कुंजियां और उनकी वैल्यू शामिल हैं
कानूनी समझौता:
अगर संभव हो, तो "स्टेबल" कुंजियों की वैल्यू कभी-कभार ही बदलनी चाहिए. अगर
bazel-out/stable-status.txt
के कॉन्टेंट में बदलाव होता है, तो Bazel उन कार्रवाइयों को अमान्य कर देता है जो उन पर निर्भर करती हैं. दूसरे शब्दों में, अगर किसी स्टेबल बटन की वैल्यू में बदलाव होता है, तो Bazel फिर से स्टैंप वाली कार्रवाइयां करेगा. इसलिए, स्टेबल स्टेटस में टाइमस्टैंप जैसी चीज़ें नहीं होनी चाहिए, क्योंकि ये हर समय बदलती रहती हैं. साथ ही, इससे Bazel हर बिल्ड के साथ स्टैंप वाली कार्रवाइयों को फिर से चलाएगा.Bazel हमेशा इन स्टेबल बटन का आउटपुट देता है:
BUILD_EMBED_LABEL
:--embed_label
की वैल्यूBUILD_HOST
: उस होस्ट मशीन का नाम जिस पर Bazel चल रहा हैBUILD_USER
: उस उपयोगकर्ता का नाम जिसके तौर पर Bazel चलाया जा रहा है
"वोलाटाइल" कुंजियों की वैल्यू अक्सर बदल सकती हैं. Bazel चाहता है कि वे समय-समय पर बदलते रहें, जैसे कि टाइमस्टैंप में बदलाव होते हैं. साथ ही, वे
bazel-out/volatile-status.txt
फ़ाइल में सही तरीके से बदलाव करते रहते हैं. हालांकि, स्टैंप वाली कार्रवाइयों को हर समय फिर से चलाने से रोकने के लिए, Bazel यह दिखाता है कि बार-बार एक ही तरह की फ़ाइल में बदलाव नहीं होता. दूसरे शब्दों में कहें, तो अगर डेटा बार-बार अपडेट करने वाली फ़ाइल ही वह फ़ाइल है जिसके कॉन्टेंट में बदलाव किए गए हैं, तो Bazel, उस पर निर्भर कार्रवाइयों को अमान्य नहीं करेगा. अगर कार्रवाइयों के दूसरे इनपुट बदल गए हैं, तो Bazel उस कार्रवाई को फिर से करता है. इस कार्रवाई को, अपडेट किया गया वाेलाटाइल स्टेटस दिखेगा. हालांकि, सिर्फ़ अपडेट किया गया स्टेटस बदलने से, कार्रवाई अमान्य नहीं होगी.Bazel हमेशा नीचे दी गई डेटा बार-बार अपडेट होने वाली कुंजियों का आउटपुट देता है:
BUILD_TIMESTAMP
: Unix Epoch के बाद से सेकंड में, बिल्ड होने का समय (System.currentTimeMillis()
की वैल्यू को हज़ार से भाग देने पर मिली वैल्यू)
Linux/macOS पर, फ़ाइल फ़ोल्डर की स्थिति को वापस पाने की सुविधा को बंद करने के लिए, --workspace_status_command=/bin/true
को पास किया जा सकता है. ऐसा इसलिए होता है, क्योंकि true
कुछ नहीं करता है और कोई आउटपुट नहीं प्रिंट करता है (शून्य से बाहर निकल जाता है). Windows पर इसी असर के लिए, MSYS के true.exe
का पाथ पास किया जा सकता है.
अगर किसी वजह से वर्कस्पेस स्टेटस कमांड काम नहीं करता है (शून्य से बाहर निकल जाता है), तो बिल्ड फ़ेल हो जाएगा.
Git का इस्तेमाल करने वाले Linux पर प्रोग्राम का उदाहरण:
#!/bin/bash echo "CURRENT_TIME $(date +%s)" echo "RANDOM_HASH $(cat /proc/sys/kernel/random/uuid)" echo "STABLE_GIT_COMMIT $(git rev-parse HEAD)" echo "STABLE_USER_NAME $USER"
--workspace_status_command
के साथ इस प्रोग्राम का पाथ पास करें. ऐसा करने पर, स्टेबल स्टेटस फ़ाइल में STABLE की लाइनें और वोलाटाइल स्टेटस फ़ाइल में, बाकी लाइनें शामिल होंगी.
--[no]stamp
stamp
नियम एट्रिब्यूट के साथ इस विकल्प से यह कंट्रोल किया जाता है कि बिल्ड की जानकारी को बाइनरी में एम्बेड करना है या नहीं.
हर नियम के आधार पर, स्टैंप को
stamp
एट्रिब्यूट का इस्तेमाल करके चालू या बंद किया जा सकता है. ज़्यादा जानकारी के लिए, बिल्ड एन्साइक्लोपीडिया देखें. जब कोई नियम stamp = -1
(*_binary
नियमों के लिए डिफ़ॉल्ट) सेट करता है, तो इस विकल्प से तय होता है कि स्टैंपिंग चालू है या नहीं.
Bazel उन बाइनरी पर कभी स्टैंप नहीं करता जो होस्ट कॉन्फ़िगरेशन के लिए बनाई गई हों. भले ही, यह विकल्प या stamp
एट्रिब्यूट कुछ भी हो. stamp =
0
(*_test
नियमों के लिए डिफ़ॉल्ट) को सेट करने वाले नियमों के लिए, स्टैंप देने की सुविधा बंद होती है, भले ही --[no]stamp
हो. अगर टारगेट की डिपेंडेंसी नहीं बदली है, तो --stamp
को तय करने से, टारगेट को फिर से बनाने के लिए बाध्य नहीं किया जाता.
आम तौर पर, --nostamp
को सेट करना परफ़ॉर्मेंस को बेहतर बनाने के लिए ज़रूरी होता है, क्योंकि इससे इनपुट के उतार-चढ़ाव की संभावना कम हो जाती है और बिल्ड कैश मेमोरी में बढ़ोतरी होती है.
प्लैटफ़ॉर्म
इन विकल्पों का इस्तेमाल उन होस्ट और टारगेट प्लैटफ़ॉर्म को कंट्रोल करने के लिए करें जो बिल्ड के काम करने के तरीके को कॉन्फ़िगर करते हैं. साथ ही, इनका इस्तेमाल यह कंट्रोल करने के लिए करें कि Bazel नियमों के लिए कौनसे एक्ज़ीक्यूशन प्लैटफ़ॉर्म और टूलचेन उपलब्ध हों.
कृपया प्लैटफ़ॉर्म और टूलचेन के बारे में बैकग्राउंड की जानकारी देखें.
--platforms=labels
प्लैटफ़ॉर्म के नियमों के लेबल, जो मौजूदा कमांड के लिए टारगेट प्लैटफ़ॉर्म के बारे में बताते हैं.
--host_platform=label
प्लैटफ़ॉर्म के नियम का लेबल, जो होस्ट सिस्टम की जानकारी देता है.
--extra_execution_platforms=labels
ऐसे प्लैटफ़ॉर्म जो कार्रवाइयां करने के लिए, एक्ज़ीक्यूशन प्लैटफ़ॉर्म के तौर पर उपलब्ध हैं. प्लैटफ़ॉर्म को सटीक टारगेट या टारगेट पैटर्न के तौर पर बताया जा सकता है. इन प्लैटफ़ॉर्म को WORKSPACE फ़ाइल में register_execution_platforms() के एलान से पहले लागू किया जाएगा.
--extra_toolchains=labels
टूलचेन रिज़ॉल्यूशन के दौरान, टूलचेन नियमों पर ध्यान दिया जाता है. टूलचेन को सटीक टारगेट या टारगेट पैटर्न के हिसाब से तय किया जा सकता है. इन टूलचेन पर register_toolchains() फ़ंक्शन का इस्तेमाल करके, Workspace की फ़ाइल में किए गए एलान से पहले विचार किया जाता है.
--toolchain_resolution_debug=regex
अगर टूलचेन टाइप, रेगुलर एक्सप्रेशन से मैच करता है, तो टूलचेन ढूंढने के दौरान डीबग करने की जानकारी प्रिंट करें. एक से ज़्यादा रेगुलर एक्सप्रेशन को कॉमा लगाकर अलग किया जा सकता है. रेगुलर एक्सप्रेशन को -
का इस्तेमाल करके हटाया जा सकता है. ऐसा करने से, Bazel या Starlark के नियमों के डेवलपर को मदद मिल सकती है. ऐसा, टूलचेन के मौजूद न होने की वजह से डीबग करने में होने वाली गड़बड़ियों की वजह से हो सकता है.
अन्य सूचनाएं
--flag_alias=alias_name=target_path
सुविधा फ़्लैग का इस्तेमाल, Starlark बिल्ड सेटिंग को छोटे नाम से बाइंड करने के लिए किया जाता है. ज़्यादा जानकारी के लिए, Starlark कॉन्फ़िगरेशन देखें.
--symlink_prefix=string
जनरेट किए गए सुविधा सिमलिंक का प्रीफ़िक्स बदलता है. सिमलिंक प्रीफ़िक्स की डिफ़ॉल्ट वैल्यू bazel-
है. इससे सिमलिंक bazel-bin
, bazel-testlogs
, और bazel-genfiles
बनाए जाएंगे.
अगर किसी वजह से सिंबल वाले लिंक नहीं बनाए जा सकते, तो चेतावनी दी जाती है, लेकिन बिल्ड को अब भी सफल माना जाता है. खास तौर पर, इससे आपको रीड-ओनली डायरेक्ट्री या ऐसी डायरेक्ट्री बनाने की अनुमति मिलती है जिसमें लिखने की अनुमति न हो. बिल्ड के आखिर में जानकारी वाले मैसेज में प्रिंट किया गया कोई भी पाथ, सिमलिंक से जुड़े शॉर्ट फ़ॉर्म का इस्तेमाल सिर्फ़ तब करेगा, जब सिमलिंक अनुमानित जगह तक ले जाते हों. दूसरे शब्दों में, आप उन पाथ के सही होने पर भरोसा कर सकते हैं, भले ही आप बनाए जा रहे सिमलिंक पर भरोसा न कर सकें.
इस विकल्प की कुछ सामान्य वैल्यू:
सिमलिंक बनाने की प्रोसेस को रोकना:
--symlink_prefix=/
की वजह से, Bazelbazel-out
औरbazel-<workspace>
सिमलिंक के साथ कोई भी सिमलिंक नहीं बना पाएगा या अपडेट नहीं करेगा. इस विकल्प का इस्तेमाल, सिमलिंक बनाने की प्रोसेस को पूरी तरह से रोकने के लिए करें.ज़रूरी चीज़ें कम करें:
--symlink_prefix=.bazel/
की वजह से Bazel, छिपी हुई डायरेक्ट्री.bazel
मेंbin
(वगैरह) नाम के सिमलिंक बनाएगा.
--platform_suffix=string
कॉन्फ़िगरेशन के छोटे नाम में सफ़िक्स जोड़ता है. इसका इस्तेमाल, आउटपुट डायरेक्ट्री तय करने के लिए किया जाता है. इस विकल्प को अलग-अलग वैल्यू पर सेट करने से फ़ाइलें अलग-अलग डायरेक्ट्री में सेव हो जाती हैं. उदाहरण के लिए, ऐसी बिल्ड के लिए कैश हिट रेट को बेहतर बनाना, जो एक-दूसरे की आउटपुट फ़ाइलों को कॉपी नहीं करता है या तुलना के लिए आउटपुट फ़ाइलों को आस-पास ही रखता है.
--default_visibility=(private|public)
bazel के डिफ़ॉल्ट दिखने की सेटिंग में बदलाव की जांच करने के लिए, अस्थायी फ़्लैग. यह सामान्य इस्तेमाल के लिए नहीं है, बल्कि इसे पूरी तरह से पेश करने के मकसद से तैयार किया गया है.
--[no]use_action_cache
यह विकल्प डिफ़ॉल्ट रूप से चालू होता है. बंद होने पर, Bazel अपने लोकल ऐक्शन कैश मेमोरी का इस्तेमाल नहीं करेगा. लोकल ऐक्शन कैश मेमोरी को बंद करने से, क्लीन बिल्ड के लिए मेमोरी और डिस्क में कम जगह बची होती है. हालांकि, इससे इंक्रीमेंटल बिल्ड धीमा हो जाएगा.
--starlark_cpu_profile=_file_
इस फ़्लैग की वैल्यू फ़ाइल का नाम है. इससे Bazel, Starlark थ्रेड के सभी सीपीयू के इस्तेमाल के बारे में आंकड़े इकट्ठा करता है. साथ ही, नाम वाली फ़ाइल में प्रोफ़ाइल को pprof फ़ॉर्मैट में लिखता है.
इस विकल्प का इस्तेमाल Starlark फ़ंक्शन की पहचान करने में मदद के लिए करें. ये फ़ंक्शन, बहुत ज़्यादा कंप्यूटेशन की वजह से, लोड होने और विश्लेषण करने की प्रोसेस को धीमा कर देते हैं. उदाहरण के लिए:
$ bazel build --nobuild --starlark_cpu_profile=/tmp/pprof.gz my/project/... $ pprof /tmp/pprof.gz (pprof) top Type: CPU Time: Feb 6, 2020 at 12:06pm (PST) Duration: 5.26s, Total samples = 3.34s (63.55%) Showing nodes accounting for 3.34s, 100% of 3.34s total flat flat% sum% cum cum% 1.86s 55.69% 55.69% 1.86s 55.69% sort_source_files 1.02s 30.54% 86.23% 1.02s 30.54% expand_all_combinations 0.44s 13.17% 99.40% 0.44s 13.17% range 0.02s 0.6% 100% 3.34s 100% sorted 0 0% 100% 1.38s 41.32% my/project/main/BUILD 0 0% 100% 1.96s 58.68% my/project/library.bzl 0 0% 100% 3.34s 100% main
एक ही डेटा के अलग-अलग व्यू के लिए, pprof
निर्देश svg
,
web
, और list
आज़माएं.
रिलीज़ के लिए Bazel का इस्तेमाल करना
डेवलपमेंट साइकल के दौरान सॉफ़्टवेयर इंजीनियर, Bazel का इस्तेमाल करते हैं. साथ ही, प्रोडक्शन में डिप्लॉयमेंट के लिए बाइनरी तैयार करते समय, रिलीज़ इंजीनियर भी इसका इस्तेमाल करते हैं. इस सेक्शन में Bazel का इस्तेमाल करने वाले रिलीज़ इंजीनियर के लिए सलाह की सूची दी गई है.
अहम विकल्प
रिलीज़ बिल्ड के लिए Bazel का इस्तेमाल करते समय, ऐसी ही समस्याएं आती हैं जो बिल्ड करने वाली दूसरी स्क्रिप्ट के लिए आती हैं. ज़्यादा जानकारी के लिए, स्क्रिप्ट से Bazel को कॉल करना देखें. खास तौर पर, नीचे दिए गए विकल्पों का सुझाव दिया जाता है:
ये विकल्प भी ज़रूरी हैं:
--package_path
--symlink_prefix
: एक से ज़्यादा कॉन्फ़िगरेशन के बिल्ड मैनेज करने के लिए, हर बिल्ड को "64 बिट" बनाम "32 बिट" जैसे अलग आइडेंटिफ़ायर से अलग करना आसान हो सकता है. यह विकल्पbazel-bin
(वगैरह) सिमलिंक में अंतर करता है.
चल रहे परीक्षण
bazel का इस्तेमाल करके टेस्ट बनाने और चलाने के लिए, bazel test
टाइप करने के बाद,
टेस्ट टारगेट का नाम लिखें.
डिफ़ॉल्ट रूप से, यह निर्देश सभी तय किए गए टारगेट (कमांड लाइन पर बताए गए गैर-टेस्ट टारगेट भी शामिल हैं) को बनाता है. साथ ही, ज़रूरी शर्तें पूरी होते ही *_test
और test_suite
टारगेट की जांच करता है. इसका मतलब है कि टेस्ट एक्ज़ीक्यूशन, बिल्डिंग के साथ खत्म हो जाता है. ऐसा करने से आम तौर पर, साइट की स्पीड
बहुत बढ़ जाती है.
bazel test
के लिए विकल्प
--cache_test_results=(yes|no|auto)
(-t
)
अगर यह विकल्प 'अपने-आप' (डिफ़ॉल्ट) पर सेट है, तो Bazel फिर से जांच तब ही करेगा, जब इनमें से कोई भी शर्त लागू होगी:
- Bazel ने टेस्ट में हुए बदलावों या उसकी डिपेंडेंसी का पता लगाया
- जांच को
external
के तौर पर मार्क किया गया है --runs_per_test
के साथ कई टेस्ट रन का अनुरोध किया गया- जांच नहीं की जा सकी.
अगर 'नहीं' है, तो सभी जांच बिना किसी शर्त के लागू की जाएंगी.
अगर 'हां' है, तो कैश मेमोरी में डेटा सेव करने का तरीका अपने-आप काम करता रहेगा. हालांकि, यह जांच के काम न करने और --runs_per_test
के साथ टेस्ट चलाने को कैश मेमोरी में सेव कर सकता है.
जिन उपयोगकर्ताओं ने अपनी .bazelrc
फ़ाइल में इस विकल्प को डिफ़ॉल्ट रूप से चालू किया है वे किसी खास ब्राउज़र पर डिफ़ॉल्ट रूप से लागू करने के लिए, संक्षिप्त नाम -t
(चालू है) या -t-
(बंद) दिख सकते हैं.
--check_tests_up_to_date
इस विकल्प से Bazel को टेस्ट न करने के लिए, बल्कि सिर्फ़ कैश मेमोरी में सेव किए गए टेस्ट के नतीजों की जांच करने और उसकी शिकायत करने के लिए कहा जाता है. अगर कोई ऐसा टेस्ट मौजूद है जिसे पहले बनाया और चलाया नहीं गया है या जिसके टेस्ट के नतीजे पुराने हैं (उदाहरण के लिए, सोर्स कोड या बिल्ड के विकल्प बदल गए हैं), तो Bazel एक गड़बड़ी का मैसेज ("टेस्ट का नतीजा अप-टू-डेट नहीं है") रिपोर्ट करेगा. यह जांच की स्थिति को "कोई स्थिति नहीं" (अगर रंग आउटपुट चालू है, लाल रंग में) के तौर पर रिकॉर्ड करेगा.
यह विकल्प, [--check_up_to_date](#check-up-to-date)
व्यवहार का भी इस्तेमाल करता है.
यह विकल्प, प्री-सबमिट जांच के लिए फ़ायदेमंद हो सकता है.
--test_verbose_timeout_warnings
अगर टेस्ट का टाइम आउट, टेस्ट के असली समय से ज़्यादा समय का है, तो इस विकल्प की मदद से Bazel उपयोगकर्ता को साफ़ तौर पर चेतावनी देगा. टेस्ट के टाइम आउट को इस तरह सेट किया जाना चाहिए कि उसमें कोई गड़बड़ी न हो. हालांकि, जिस टेस्ट में टाइम आउट की बहुत ज़्यादा गड़बड़ी होती है उससे अचानक दिखने वाली असल समस्याओं को छिपाया जा सकता है.
उदाहरण के लिए, आम तौर पर जो टेस्ट एक या दो मिनट में पूरा होता है उसके लिए ETERNAL या DURATION का टाइम आउट नहीं होना चाहिए, क्योंकि ये बहुत ही बड़े काम हैं.
इस विकल्प से उपयोगकर्ताओं को सही टाइम आउट वैल्यू तय करने या मौजूदा टाइम आउट वैल्यू की जांच करने में मदद मिलती है.
--[no]test_keep_going
डिफ़ॉल्ट रूप से, सभी टेस्ट पूरे होने तक चलाए जाते हैं. अगर यह फ़्लैग बंद है,
तो भी बिल्ड न पास होने वाले टेस्ट से रद्द हो जाता है. बिल्ड के बाद के चरण और
टेस्ट शुरू करने की प्रक्रिया नहीं चलाई जाती है. साथ ही, इन-फ़्लाइट का अनुरोध भी रद्द कर दिया जाता है.
--notest_keep_going
और --keep_going
, दोनों की जानकारी न दें.
--flaky_test_attempts=attempts
इस विकल्प से यह तय होता है कि किसी वजह से जांच में फ़ेल होने पर, ज़्यादा से ज़्यादा कितनी बार जांच की जानी चाहिए. टेस्ट की खास जानकारी में, जो जांच शुरू में काम नहीं करती, लेकिन
आखिर में सफल हो जाती है, उसे FLAKY
के तौर पर रिपोर्ट किया जाता है. हालांकि,
Bzel के एग्ज़िट कोड या पास किए गए टेस्ट की
कुल संख्या की पहचान करते समय इसे पास माना जाता है. सभी संभावित मौकों पर फ़ेल हो जाने वाले टेस्ट को फ़ेल माना जाता है.
डिफ़ॉल्ट रूप से (जब यह विकल्प तय न किया गया हो या जब यह डिफ़ॉल्ट पर सेट हो), सामान्य जांच के लिए सिर्फ़ एक बार कोशिश की जा सकती है. साथ ही, flaky
एट्रिब्यूट सेट वाले जांच के नियमों के लिए, सिर्फ़ एक बार कोशिश की जा सकती है. जांच करने की ज़्यादा से ज़्यादा सीमा को बदलने के लिए, एक पूर्णांक वैल्यू तय की जा सकती है. सिस्टम के गलत इस्तेमाल को रोकने के लिए, Bazel
ज़्यादा से ज़्यादा 10 टेस्ट करने की अनुमति देता है.
--runs_per_test=[regex@]number
इस विकल्प से यह पता चलता है कि हर जांच कितनी बार की जानी चाहिए. सभी टेस्ट के निष्पादनों को अलग-अलग टेस्ट के रूप में माना जाता है (फ़ॉलबैक फ़ंक्शन हर एक पर अलग-अलग लागू होगा).
सफल न होने वाले टारगेट की स्थिति --runs_per_test_detects_flakes
फ़्लैग की वैल्यू के आधार पर तय होती है:
- अगर वह मौजूद नहीं है, तो किसी भी टेस्ट के न चलने की वजह से पूरा टेस्ट फ़ेल हो जाएगा.
- अगर मौजूद है और एक ही शार्ड रिटर्न PASS से और फ़ेल से दो बार चलाया जाता है, तो टेस्ट को अस्थिर की स्थिति मिलेगी (जब तक कि अन्य असफलता की वजह से वह फ़ेल न हो जाए).
अगर कोई एक संख्या बताई जाती है, तो सभी टेस्ट कई बार चलेंगे.
इसके अलावा, regex@number का इस्तेमाल करके, रेगुलर एक्सप्रेशन तय किया जा सकता है. इससे, --runs_per_test
के असर को उन टारगेट पर सीमित कर दिया जाता है
जो रेगुलर एक्सप्रेशन से मैच करते हैं (--runs_per_test=^//pizza:.*@4
, //pizza/
से कम
सभी टेस्ट चार बार चलाता है).
--runs_per_test
के इस फ़ॉर्म को एक से ज़्यादा बार बताया जा सकता है.
--[no]runs_per_test_detects_flakes
अगर यह विकल्प दिया गया है (डिफ़ॉल्ट रूप से ऐसा नहीं होता है), तो Bazel --runs_per_test
के ज़रिए, फ़्लैकी टेस्ट शार्ड का पता लगाएगा. अगर एक शार्ड के लिए एक या उससे ज़्यादा रन फ़ेल होते हैं और एक ही शार्ड पास के लिए एक या उससे ज़्यादा रन हैं, तो फ़्लैग के साथ टारगेट को फ़्लैकी माना जाएगा. अगर इसकी जानकारी नहीं दी गई, तो टारगेट, फ़ेल होने की स्थिति
की रिपोर्ट करेगा.
--test_summary=output_style
इससे पता चलता है कि जांच के नतीजे की खास जानकारी किस तरह दिखनी चाहिए.
- अगर जांच नहीं हो पाती है, तो
short
हर जांच के नतीजों को टेस्ट आउटपुट वाली फ़ाइल के नाम के साथ प्रिंट करता है. यह डिफ़ॉल्ट वैल्यू है. terse
जैसेshort
, लेकिन इससे भी छोटा: सिर्फ़ उन टेस्ट की जानकारी प्रिंट करें जो पास नहीं हुए.detailed
हर उस टेस्ट केस को प्रिंट करता है जो पूरा नहीं हो पाया, न कि सिर्फ़ हर टेस्ट को. टेस्ट आउटपुट फ़ाइलों के नाम को मिटा दिया गया है.none
, जांच की खास जानकारी प्रिंट नहीं करता.
--test_output=output_style
इससे पता चलता है कि टेस्ट आउटपुट कैसे दिखना चाहिए:
summary
यह खास जानकारी दिखाता है कि हर टेस्ट पास हुआ या फ़ेल हुआ. फ़ेल हो चुके टेस्ट के लिए, आउटपुट लॉग फ़ाइल का नाम भी दिखाता है. खास जानकारी को बिल्ड के आखिर में प्रिंट किया जाएगा (बिल्ड के दौरान, टेस्ट शुरू, पास या फ़ेल होने पर आपको बस प्रोग्रेस के आसान मैसेज दिखेंगे). यह डिफ़ॉल्ट व्यवहार है.errors
, टेस्ट पूरा होने के तुरंत बाद, फ़ेल हो चुके टेस्ट से मिला stdout/stderr आउटपुट सिर्फ़ stdout में भेजता है, जिससे यह पक्का होता है कि एक साथ होने वाले टेस्ट के आउटपुट को एक-दूसरे के साथ इंटरलीव न किया जाए. ऊपर दिए गए जवाब के आउटपुट के मुताबिक, बिल्ड पर खास जानकारी को प्रिंट करता है.all
,errors
के समान है, लेकिन सभी परीक्षणों के लिए आउटपुट प्रिंट करता है, इसमें पास होने वाले परीक्षण भी शामिल हैं.streamed
, हर जांच से रीयल-टाइम में stdout/stderr आउटपुट स्ट्रीम करता है.
--java_debug
इस विकल्प की वजह से, Java टेस्ट की Java वर्चुअल मशीन को जांच शुरू करने से पहले,
JDWP का पालन करने वाले डीबगर से कनेक्शन मिलने का इंतज़ार करना पड़ता है. यह विकल्प --test_output=streamed
का मतलब है.
--[no]verbose_test_summary
डिफ़ॉल्ट रूप से यह विकल्प चालू होता है, जिसकी वजह से जांच में लगने वाला समय और अन्य अतिरिक्त जानकारी (जैसे कि जांच की कोशिश) जांच की खास जानकारी में प्रिंट हो जाती है. अगर
--noverbose_test_summary
दिया गया है, तो जांच की खास जानकारी में
सिर्फ़ टेस्ट नाम, जांच का स्टेटस, और कैश मेमोरी में सेव किए गए टेस्ट इंंडिकेटर शामिल होंगे. साथ ही, जहां तक हो सके,
इस फ़ॉर्मैट को 80 वर्णों के अंदर रखने के लिए फ़ॉर्मैट किया जाएगा.
--test_tmpdir=path
स्थानीय तौर पर किए जाने वाले टेस्ट के लिए अस्थायी डायरेक्ट्री तय करता है. हर टेस्ट को इस डायरेक्ट्री के अंदर
एक अलग सबडायरेक्ट्री में चलाया जाएगा. इस डायरेक्ट्री को हर bazel test
निर्देश की शुरुआत में ही मिटाया जाएगा.
डिफ़ॉल्ट रूप से, bazel इस डायरेक्ट्री को Bazel आउटपुट बेस डायरेक्ट्री के तहत रखेगा.
--test_timeout=seconds
या --test_timeout=seconds,seconds,seconds,seconds
सेकंड की तय संख्या का इस्तेमाल करके, सभी जांचों के लिए टाइम आउट वैल्यू को नए टाइम आउट वैल्यू के तौर पर बदल देता है. अगर सिर्फ़ एक वैल्यू दी जाती है, तो उसका इस्तेमाल टेस्ट टाइम आउट की सभी कैटगरी के लिए किया जाएगा.
इसके अलावा, चार कॉमा लगाकर अलग की गई वैल्यू दी जा सकती हैं. इसमें छोटी, सामान्य, लंबी, और हमेशा चलने वाली जांचों के लिए, अलग-अलग टाइम आउट तय किए जा सकते हैं (इस क्रम में). किसी भी रूप में, किसी भी टेस्ट साइज़ की शून्य या नेगेटिव वैल्यू को दी गई टाइम आउट कैटगरी के लिए, डिफ़ॉल्ट टाइम आउट से बदल दिया जाएगा, जैसा कि राइटिंग टेस्ट पेज पर बताया गया है. डिफ़ॉल्ट रूप से, Bazel सभी टेस्ट के लिए, इन टाइम आउट का इस्तेमाल करेगा. ऐसा करने के लिए, वह टेस्ट के साइज़ से टाइम आउट की सीमा का हवाला देगा. भले ही, साइज़ अनुमान के हिसाब से सेट किया गया हो या साफ़ तौर पर सेट किया गया हो.
जो टेस्ट साफ़ तौर पर टाइम आउट कैटगरी को अपने साइज़ से अलग बताते हैं उन्हें वही वैल्यू मिलेगी. जैसे, अगर टाइम आउट साफ़ तौर पर साइज़ टैग से सेट किया गया हो. इसलिए, 'छोटा' साइज़ वाले टेस्ट में टाइम आउट की जानकारी मिलती है. इसका असरदार टाइम आउट वही होगा जो किसी 'बड़े' टेस्ट के लिए साफ़ तौर पर दिया गया होता है.
--test_arg=arg
हर टेस्ट प्रोसेस के लिए कमांड लाइन के विकल्प/फ़्लैग/तर्क पास करता है. कई तर्क पास करने के लिए, इस विकल्प का इस्तेमाल कई बार किया जा सकता है. उदाहरण के लिए,
--test_arg=--logtostderr --test_arg=--v=3
.
--test_env=variable=_value_
या --test_env=variable
इस नीति से ऐसे अतिरिक्त वैरिएबल तय होते हैं जिन्हें हर टेस्ट के लिए, टेस्ट एनवायरमेंट में इंजेक्ट किया जाना चाहिए. अगर value तय नहीं किया गया है, तो इसे bazel test
कमांड को शुरू करने के लिए इस्तेमाल किए जाने वाले शेल एनवायरमेंट से इनहेरिट किया जाएगा.
System.getenv("var")
(Java), getenv("var")
(C या C++), का इस्तेमाल करके एनवायरमेंट को टेस्ट से ऐक्सेस किया जा सकता है
--run_under=command-prefix
इससे एक प्रीफ़िक्स तय किया जाता है, जिसे टेस्ट रनर, टेस्ट कमांड के पहले शामिल करेगा. बर्न शेल टोकनाइज़ेशन नियमों का इस्तेमाल करके, command-prefix को शब्दों में बांटा जाता है. इसके बाद, शब्दों की सूची को उस निर्देश से पहले जोड़ा जाता है जिसे लागू किया जाएगा.
अगर पहला शब्द पूरी तरह क्वालिफ़ाइड लेबल (//
से शुरू होता है) है, तो वह बनाया गया है. इसके बाद लेबल को संबंधित एक्ज़ीक्यूटेबल लोकेशन से बदल दिया जाता है जो कमांड से पहले जोड़ा जाता है. इसे अन्य शब्दों के साथ एक्ज़ीक्यूट किया जाएगा.
कुछ चेतावनियां लागू होती हैं:
- टेस्ट करने के लिए इस्तेमाल किया जाने वाला पाथ, आपके एनवायरमेंट के पाथ से अलग हो सकता है. इसलिए, आपको
--run_under
कमांड (command-prefix का पहला शब्द) के लिए, ऐब्सलूट पाथ का इस्तेमाल करना पड़ सकता है. stdin
कनेक्ट नहीं है, इसलिए--run_under
को इंटरैक्टिव कमांड के लिए इस्तेमाल नहीं किया जा सकता.
उदाहरण:
--run_under=/usr/bin/strace --run_under='/usr/bin/strace -c' --run_under=/usr/bin/valgrind --run_under='/usr/bin/valgrind --quiet --num-callers=20'
टेस्ट के विकल्प को चुनें
जैसा कि आउटपुट चुनने के विकल्पों में बताया गया है, टेस्ट को साइज़, समय खत्म, टैग या भाषा के हिसाब से फ़िल्टर किया जा सकता है. सुविधा सामान्य नाम वाला फ़िल्टर, खास फ़िल्टर आर्ग्युमेंट को टेस्ट रनर पर फ़ॉरवर्ड कर सकता है.
bazel test
के लिए अन्य विकल्प
सिंटैक्स और बाकी विकल्प,
bazel build
जैसे ही हैं.
रनिंग एक्ज़ीक्यूटेबल
bazel run
कमांड, bazel build
की तरह ही है. हालांकि, इसका इस्तेमाल एक ही टारगेट को बनाने और चलाने के लिए किया जाता है. यह एक सामान्य सेशन है:
% bazel run java/myapp:myapp -- --arg1 --arg2 Welcome to Bazel INFO: Loading package: java/myapp INFO: Loading package: foo/bar INFO: Loading complete. Analyzing... INFO: Found 1 target... ... Target //java/myapp:myapp up-to-date: bazel-bin/java/myapp:myapp INFO: Elapsed time: 0.638s, Critical Path: 0.34s INFO: Running command line: bazel-bin/java/myapp:myapp --arg1 --arg2 Hello there $EXEC_ROOT/java/myapp/myapp --arg1 --arg2
Bazel की बनाई गई बाइनरी को सीधे तौर पर शुरू करने के लिए, bazel run
मिलता-जुलता है, लेकिन इसका व्यवहार, इस बात पर निर्भर करता है कि जिस बाइनरी को शुरू किया जाना है वह टेस्ट है या नहीं.
जब बाइनरी कोई टेस्ट नहीं होता है, तो मौजूदा डायरेक्ट्री, बाइनरी का रनफ़ाइल ट्री होगी.
जब बाइनरी कोई टेस्ट होता है, तो मौजूदा वर्किंग डायरेक्ट्री ही exec रूट होगी. साथ ही, एनवायरमेंट टेस्ट को दोहराने की अच्छी भावना से कोशिश की जाती है. हालांकि, एम्युलेटर सही नहीं है और कई शार्ड वाले टेस्ट इस तरह नहीं चलाए जा सकते (इसके लिए, --test_sharding_strategy=disabled
कमांड लाइन विकल्प का इस्तेमाल किया जा सकता है)
बाइनरी के लिए, यहां दिए गए अतिरिक्त एनवायरमेंट वैरिएबल भी उपलब्ध हैं:
BUILD_WORKSPACE_DIRECTORY
: उस फ़ाइल फ़ोल्डर का रूट जहां बिल्ड चलाया गया था.BUILD_WORKING_DIRECTORY
: वह मौजूदा डायरेक्ट्री जहां से Bazel को चलाया गया था.
उदाहरण के लिए, इनका इस्तेमाल कमांड लाइन पर मौजूद फ़ाइल के नामों को समझने के लिए किया जा सकता है. यह मतलब उपयोगकर्ता के लिए आसान है.
bazel run
के लिए विकल्प
--run_under=command-prefix
इसका वही असर होता है जो bazel test
(ऊपर देखें) के लिए --run_under
विकल्प पर लागू होता है. हालांकि, यह bazel test
के टेस्ट पर लागू होने के बजाय, bazel
run
से चलाए जा रहे निर्देश पर लागू होता है. इसे लेबल के तहत नहीं चलाया जा सकता.
Bazel से लॉग इन करने के आउटपुट को फ़िल्टर करना
bazel run
के साथ बाइनरी को शुरू करते समय, Bazel खुद से और बाइनरी को
डालने के आउटपुट को प्रिंट करता है. लॉग का शोर कम करने के लिए, --ui_event_filters
और --noshow_progress
फ़्लैग की मदद से, Bazel के आउटपुट को बंद किया जा सकता है.
उदाहरण के लिए:
bazel run --ui_event_filters=-info,-stdout,-stderr --noshow_progress //java/myapp:myapp
टेस्ट करना
bazel run
, टेस्ट बाइनरी भी एक्ज़ीक्यूट कर सकता है, जिससे टेस्ट को उस माहौल के करीब से चलाने पर असर पड़ता है जिसके बारे में राइटिंग टेस्ट में बताया गया है. ध्यान दें कि इस तरीके से टेस्ट करते समय,
--test_*
आर्ग्युमेंट पर कोई असर नहीं पड़ता. हालांकि,
--test_arg
.
बिल्ड आउटपुट को साफ़ करना
clean
निर्देश
Bazel के पास clean
का निर्देश है, जो कि मेक के नियमों से मिलता-जुलता है.
यह इस Bazel इंस्टेंस से बनाए गए सभी बिल्ड कॉन्फ़िगरेशन के लिए, आउटपुट डायरेक्ट्री मिटाता है और
इंटरनल कैश को रीसेट करता है. अगर किसी भी कमांड-लाइन विकल्प के बिना एक्ज़ीक्यूट किया जाता है, तो सभी कॉन्फ़िगरेशन के लिए आउटपुट डायरेक्ट्री
साफ़ हो जाएगी.
याद रखें कि हर Bazel इंस्टेंस एक ही फ़ाइल फ़ोल्डर से जुड़ा होता है. इसलिए,
clean
कमांड, फ़ाइल फ़ोल्डर में Bazel इंस्टेंस के साथ किए गए आपके सभी बिल्ड के सभी आउटपुट मिटा देगा.
Bazel इंस्टेंस से बनाए गए, काम करने वाले पूरे ट्री को पूरी तरह से हटाने के लिए, --expunge
विकल्प चुना जा सकता है. --expunge
के साथ लागू किए जाने पर, क्लीन कमांड
सिर्फ़ पूरे आउटपुट बेस ट्री को हटा देता है. इसमें बिल्ड आउटपुट के साथ-साथ, Bazel की बनाई गई सभी अस्थायी फ़ाइलें शामिल होती हैं. क्लीन करने के बाद यह Bazel सर्वर भी बंद हो जाता है. यह shutdown
कमांड की तरह काम करता है. उदाहरण के लिए, किसी Bazel इंस्टेंस की
सभी डिस्क और मेमोरी ट्रेस को खाली करने के लिए, आप यह बता सकते हैं:
% bazel clean --expunge
इसके अलावा, आपके पास --expunge_async
का इस्तेमाल करके बैकग्राउंड में डेटा मिटाने का विकल्प है. एसिंक्रोनस रूप से मिटाए जाने के दौरान, उसी क्लाइंट में Bazel कमांड
का इस्तेमाल करना सुरक्षित होता है.
clean
निर्देश मुख्य रूप से, उन फ़ाइल फ़ोल्डर के लिए डिस्क स्टोरेज फिर से पाने के लिए दिया जाता है जिनकी अब ज़रूरत नहीं है.
हो सकता है कि Bazel के इंक्रीमेंटल रीबिल काफ़ी असरदार न हों, इसलिए समस्या आने पर clean
का इस्तेमाल एक जैसा स्थिति बनाए रखने के लिए किया जा सकता है.
Bazel का डिज़ाइन कुछ ऐसा है कि इन समस्याओं को ठीक किया जा सकता है. साथ ही, इन गड़बड़ियों को ठीक करना बहुत प्राथमिकता है. अगर आपको कभी भी कोई गलत इंक्रीमेंटल (बढ़ने वाला) बिल्ड मिलता है, तो clean
का इस्तेमाल करने के बजाय, गड़बड़ी की रिपोर्ट करें और टूल में गड़बड़ियों की शिकायत करें.
डिपेंडेंसी ग्राफ़ के बारे में क्वेरी करना
Bazel में एक क्वेरी लैंग्वेज शामिल है, जिसमें बिल्ड के दौरान इस्तेमाल किए गए डिपेंडेंसी ग्राफ़ के बारे में सवाल पूछे जाते हैं. क्वेरी की भाषा का इस्तेमाल दो निर्देशों से किया जाता है: क्वेरी और cquery. दोनों कमांड के बीच का बड़ा अंतर यह है कि क्वेरी लोडिंग फ़ेज़ के बाद और cquery, विश्लेषण के चरण के बाद चलती है. ये टूल, सॉफ़्टवेयर इंजीनियरिंग से जुड़े कई कामों में मदद करते हैं.
क्वेरी लैंग्वेज ग्राफ़ के ऊपर बीजगणितीय संक्रियाओं पर आधारित है; इसे
Bazel क्वेरी रेफ़रंस. उदाहरण के लिए, रेफ़रंस, और क्वेरी के हिसाब से कमांड लाइन के विकल्पों के लिए, कृपया दस्तावेज़ को देखें.
क्वेरी टूल कई कमांड-लाइन
विकल्प स्वीकार करता है. --output
आउटपुट फ़ॉर्मैट चुनता है.
--[no]keep_going
(डिफ़ॉल्ट रूप से बंद होता है) की वजह से क्वेरी टूल, गड़बड़ियां होने पर भी काम करता रहता है. अगर गड़बड़ी होने पर अधूरा नतीजा स्वीकार नहीं किया जाता, तो यह व्यवहार बंद किया जा सकता है.
--[no]tool_deps
विकल्प, डिफ़ॉल्ट रूप से चालू होता है. इससे नॉन-टारगेट कॉन्फ़िगरेशन के लिए डिपेंडेंसी, उस डिपेंडेंसी ग्राफ़ में शामिल होती है जिस पर क्वेरी काम करती है.
--[no]implicit_deps
विकल्प, डिफ़ॉल्ट रूप से चालू होता है. इसकी वजह से, उस डिपेंडेंसी ग्राफ़ में इंप्लिसिट डिपेंडेंसी शामिल होती है जिस पर क्वेरी काम करती है. इंप्लिसिट डिपेंडेंसी, BUILD फ़ाइल में साफ़ तौर पर नहीं बताई गई होती है, लेकिन bazel के ज़रिए जोड़ी जाती है.
उदाहरण: "PEBL ट्री में सभी टेस्ट बनाने के लिए ज़रूरी, सभी जेन कार्रवाइयों की परिभाषाओं की जगह (BUILD फ़ाइलों में) दिखाएं."
bazel query --output location 'kind(genrule, deps(kind(".*_test rule", foo/bar/pebl/...)))'
ऐक्शन ग्राफ़ के बारे में क्वेरी करना
aquery
निर्देश से, आपको बिल्ड ग्राफ़ में कार्रवाइयों के लिए क्वेरी करने की सुविधा मिलती है.
यह विश्लेषण के बाद कॉन्फ़िगर किए गए टारगेट ग्राफ़ पर काम करता है. साथ ही, कार्रवाइयों, आर्टफ़ैक्ट, और उनके संबंधों के बारे में जानकारी देता है.
यह टूल कई कमांड-लाइन विकल्पों को स्वीकार करता है.
--output
आउटपुट फ़ॉर्मैट चुनता है. डिफ़ॉल्ट आउटपुट फ़ॉर्मैट
(text
) है, जिसे कोई भी व्यक्ति पढ़ सकता है. मशीन से पढ़ने लायक फ़ॉर्मैट के लिए, proto
या textproto
का इस्तेमाल करें.
खास तौर पर, aquery कमांड, सामान्य Bazel बिल्ड के ऊपर चलती है और
बिल्ड के दौरान उपलब्ध विकल्पों के सेट को इनहेरिट करती है.
यह फ़ंक्शन के उन ही सेट के साथ काम करता है जो पारंपरिक
query
के लिए भी उपलब्ध हैं. हालांकि, siblings
, buildfiles
, और
tests
.
ज़्यादा जानकारी के लिए, ऐक्शन ग्राफ़ क्वेरी देखें.
अलग-अलग निर्देश और विकल्प
help
help
निर्देश से ऑनलाइन मदद मिलती है. डिफ़ॉल्ट रूप से, यह उपलब्ध निर्देशों और सहायता विषयों की खास जानकारी दिखाता है, जैसा कि
Bzel के साथ बिल्डिंग में दिखाया गया है.
तर्क तय करने से किसी 'खास विषय के लिए पूरी मदद' दिखती है. ज़्यादातर विषय में Bazel कमांड होते हैं, जैसे कि build
या query
. हालांकि, सहायता के लिए कुछ ऐसे विषय भी हैं जो निर्देशों से मेल नहीं खाते.
--[no]long
(-l
)
डिफ़ॉल्ट रूप से, bazel help [topic]
किसी विषय के लिए काम के विकल्पों की सिर्फ़ खास जानकारी प्रिंट करता है. अगर
--long
विकल्प दिया गया है, तो हर विकल्प का टाइप, डिफ़ॉल्ट वैल्यू,
और पूरी जानकारी भी प्रिंट की जाती है.
shutdown
shutdown
कमांड का इस्तेमाल करके, Bazel सर्वर की प्रोसेस रोकी जा सकती हैं. इस निर्देश की वजह से, Bazel सर्वर बंद होते ही बंद हो जाता है.
उदाहरण के लिए, किसी भी बिल्ड या मौजूदा प्रोसेस के पूरा होने के बाद. ज़्यादा जानकारी के लिए, क्लाइंट/सर्वर लागू करना देखें.
Bazel सर्वर, काम न करने के टाइम आउट के बाद अपने-आप बंद हो जाते हैं. इसलिए, इस निर्देश की ज़रूरत कभी-कभार ही होती है. हालांकि, स्क्रिप्ट में यह तब काम आ सकता है, जब यह पता हो कि दिए गए फ़ाइल फ़ोल्डर में कोई और बिल्ड नहीं होगा.
shutdown
एक विकल्प, --iff_heap_size_greater_than _n_
स्वीकार करता है, जिसके लिए एक पूर्णांक तर्क (एमबी में) ज़रूरी होता है. अगर बताया गया है, तो यह पहले से इस्तेमाल की जा चुकी मेमोरी की सीमा को
बंद कर देता है. यह उन स्क्रिप्ट के लिए फ़ायदेमंद है जो कई बिल्ड शुरू करती हैं. ऐसा इसलिए, क्योंकि Bazel सर्वर में किसी भी तरह की मेमोरी लीक हो सकती है.
यह कई बार क्रैश हो सकता है; कंडिशनल रीस्टार्ट करने से, यह स्थिति पहले से चालू हो जाती है.
info
info
कमांड, Bazel सर्वर इंस्टेंस या किसी खास बिल्ड कॉन्फ़िगरेशन से जुड़ी अलग-अलग वैल्यू को प्रिंट करता है.
(इनका इस्तेमाल बिल्ड बढ़ाने वाली स्क्रिप्ट में किया जा सकता है.)
info
निर्देश एक (वैकल्पिक) तर्क की भी अनुमति देता है, जो नीचे दी गई सूची में दी गई कुंजियों में से किसी एक का नाम है.
इस मामले में, bazel info key
सिर्फ़ उस एक कुंजी
की वैल्यू प्रिंट करेगा. (Bzel स्क्रिप्ट करते समय यह खास तौर पर सुविधाजनक होता है, क्योंकि इससे sed -ne /key:/s/key://p
से नतीजे को पाइप करने की
ज़रूरत नहीं होती:
कॉन्फ़िगरेशन-इंडिपेंडेंट डेटा
release
: इस Bazel इंस्टेंस का रिलीज़ लेबल या अगर यह रिलीज़ किया गया बाइनरी नहीं है, तो “डेवलपमेंट वर्शन”workspace
, बेस फ़ाइल फ़ोल्डर डायरेक्ट्री का ऐब्सलूट पाथ है.install_base
: इंस्टॉलेशन डायरेक्ट्री का ऐब्सलूट पाथ, जिसे मौजूदा उपयोगकर्ता के लिए, इस Bazel इंस्टेंस में इस्तेमाल किया जाता है. Bazel, इस डायरेक्ट्री के नीचे अंदरूनी तौर पर ज़रूरी एक्ज़ीक्यूटेबल इंस्टॉल करता है.output_base
: यह बेस आउटपुट डायरेक्ट्री का पूरा पाथ होता है. इसे Bazel इंस्टेंस में मौजूदा उपयोगकर्ता और Workspace के कॉम्बिनेशन के लिए इस्तेमाल किया जाता है. Bazel अपने सभी स्क्रैच और बिल्ड आउटपुट को इस डायरेक्ट्री में शामिल करता है.execution_root
: out_base में एक्ज़ीक्यूशन रूट डायरेक्ट्री का ऐब्सलूट पाथ. यह डायरेक्ट्री उन सभी फ़ाइलों के लिए रूट है जिन्हें बिल्ड के दौरान चलाए जाने वाले कमांड के साथ ऐक्सेस किया जा सकता है. साथ ही, यह उन कमांड के लिए काम करने वाली डायरेक्ट्री है. अगर फ़ाइल फ़ोल्डर की डायरेक्ट्री लिखी जा सकती है, तोbazel-<workspace>
नाम का एक सिमलिंक इस डायरेक्ट्री को दिखाता है.output_path
: यह बिल्ड कमांड के ज़रिए जनरेट की गई सभी फ़ाइलों के लिए इस्तेमाल किए जाने वाले एक्ज़ीक्यूशन रूट के नीचे मौजूद आउटपुट डायरेक्ट्री का पूरा पाथ होता है. अगर फ़ाइल फ़ोल्डर की डायरेक्ट्री लिखी जा सकती है, तो उसमेंbazel-out
नाम का सिमलिंक मौजूद होगा, जो इस डायरेक्ट्री की ओर इशारा करेगा.server_pid
: Bazel सर्वर की प्रोसेस का आईडी.server_log
: यह Bazel सर्वर की डीबग लॉग फ़ाइल का ऐब्सलूट पाथ है. इस फ़ाइल में, Bazel सर्वर के अब तक के सभी निर्देशों को डीबग करने की जानकारी शामिल है. यह जानकारी Bazel डेवलपर और बिजली इस्तेमाल करने वाले लोगों के इस्तेमाल के लिए है.command_log
: कमांड लॉग फ़ाइल का ऐब्सलूट पाथ; इसमें सबसे हाल के Bazel कमांड की इंटरलीव्ड stdout और stderr स्ट्रीम शामिल हैं. ध्यान दें किbazel info
चलाने पर, इस फ़ाइल का कॉन्टेंट ओवरराइट हो जाएगा. इसके बाद, यह हाल ही का Bazel कमांड बन जाएगा. हालांकि, कमांड लॉग फ़ाइल की जगह तब तक नहीं बदलेगी, जब तक कि--output_base
या--output_user_root
विकल्पों की सेटिंग नहीं बदली जाती.used-heap-size
,committed-heap-size
,max-heap-size
: अलग-अलग जेवीएम हीप साइज़ पैरामीटर की रिपोर्ट करता है. ध्यान दें: मौजूदा समय में इस्तेमाल की जा रही मेमोरी, फ़िलहाल सिस्टम से JVM को उपलब्ध होने की गारंटी दी जा सकती है, जो ज़्यादा से ज़्यादा उपलब्ध कराया जा सकता है.gc-count
,gc-time
: इस Bazel सर्वर के शुरू होने के बाद से लेकर अब तक, कचरे के कलेक्शन की कुल संख्या और उन्हें पूरा करने में लगा समय. ध्यान दें कि ये वैल्यू हर बिल्ड की शुरुआत में रीसेट नहीं होती हैं.package_path
: पाथ की कोलन से अलग की गई सूची, जिसे बाज़ल के ज़रिए पैकेज के लिए खोजा जाएगा. इसका फ़ॉर्मैट,--package_path
बिल्ड कमांड लाइन आर्ग्युमेंट के जैसा ही है.
उदाहरण: Bazel सर्वर का प्रोसेस आईडी.
% bazel info server_pid 1285
कॉन्फ़िगरेशन के हिसाब से डेटा
इस डेटा पर, bazel info
को दिए गए कॉन्फ़िगरेशन के विकल्पों, जैसे कि --cpu
, --compilation_mode
वगैरह का असर पड़ सकता है. info
निर्देश, डिपेंडेंसी के विश्लेषण को कंट्रोल करने वाले सभी विकल्पों को स्वीकार करता है. ऐसा इसलिए होता है, क्योंकि इनमें से कुछ कॉन्फ़िगरेशन, बिल्ड की आउटपुट डायरेक्ट्री, कंपाइलर वगैरह की जगह तय करते हैं.
bazel-bin
,bazel-testlogs
,bazel-genfiles
: उनbazel-*
डायरेक्ट्री का ऐब्सलूट पाथ रिपोर्ट करता है जिनमें बिल्ड से जनरेट हुए प्रोग्राम मौजूद होते हैं. आम तौर पर, यह हमेशा ऐसा नहीं होता, क्योंकि एक सही बिल्ड के बाद बेस वर्कस्पेस डायरेक्ट्री में बनाए गएbazel-*
सिमलिंक एक जैसे होते हैं. हालांकि, अगर फ़ाइल फ़ोल्डर की डायरेक्ट्री सिर्फ़ पढ़ने के लिए है, तोbazel-*
सिमलिंक नहीं बनाए जा सकते. सिमलिंक मौजूद होने का अनुमान लगाने के बजाय,bazel info
की रिपोर्ट की गई वैल्यू का इस्तेमाल करने वाली स्क्रिप्ट ज़्यादा बेहतर होंगी.- पूरा
"बनाएं" एनवायरमेंट. अगर
--show_make_env
फ़्लैग की जानकारी दी गई है, तो मौजूदा कॉन्फ़िगरेशन के "बनाएं" एनवायरमेंट के सभी वैरिएबल भी दिखाए जाते हैं. जैसे,CC
,GLIBC_VERSION
वगैरह. ये वे वैरिएबल हैं जिन्हें BUILD फ़ाइलों के अंदर$(CC)
याvarref("CC")
सिंटैक्स का इस्तेमाल करके ऐक्सेस किया गया है.
उदाहरण: मौजूदा कॉन्फ़िगरेशन के लिए C++ कंपाइलर.
"बनाएं" एनवायरमेंट में यह $(CC)
वैरिएबल है.
इसलिए, --show_make_env
फ़्लैग की ज़रूरत है.
% bazel info --show_make_env -c opt COMPILATION_MODE opt
उदाहरण: मौजूदा कॉन्फ़िगरेशन के लिए, bazel-bin
आउटपुट डायरेक्ट्री. इसके सही होने की गारंटी है, उन मामलों में भी जहां
bazel-bin
सिमलिंक किसी वजह से नहीं बनाया जा सकता
(जैसे, अगर किसी डायरेक्ट्री को रीड-ओनली मोड से बनाया जा रहा हो).
% bazel info --cpu=piii bazel-bin /var/tmp/_bazel_johndoe/fbd0e8a34f61ce5d491e3da69d959fe6/execroot/io_bazel/bazel-out/piii-opt/bin % bazel info --cpu=k8 bazel-bin /var/tmp/_bazel_johndoe/fbd0e8a34f61ce5d491e3da69d959fe6/execroot/io_bazel/bazel-out/k8-opt/bin
version
और --version
वर्शन कमांड, Bazel बाइनरी के वर्शन की जानकारी प्रिंट करता है. इसमें, इसे बनाने की तारीख और बदलाव की सूची भी शामिल होती है. इससे खास तौर पर यह पता करने में मदद मिलती है कि क्या आपके पास नया Bazel है या नहीं. इसके अलावा, अगर आपको किसी गड़बड़ी की शिकायत करनी है, तो इससे भी मदद मिलेगी. कुछ दिलचस्प वैल्यू ये हैं:
changelist
: वह बदलाव सूची जिस पर Bazel का यह वर्शन रिलीज़ हुआ था.label
: इस Bazel इंस्टेंस का रिलीज़ लेबल या अगर यह रिलीज़ किया गया बाइनरी नहीं है, तो “डेवलपमेंट वर्शन” गड़बड़ियों की शिकायत करते समय बहुत मदद मिलती है.
बिना किसी अन्य आर्ग्युमेंट के bazel --version
,
bazel version --gnu_format
जितना ही आउटपुट उत्सर्जित करेगा. हालांकि, इसमें Bazel सर्वर को चालू करने या सर्वर के संग्रह को अनपैक करने से होने वाले खराब असर शामिल नहीं हैं. bazel --version
को कहीं से भी चलाया जा सकता है - इसके लिए फ़ाइल फ़ोल्डर की डायरेक्ट्री की ज़रूरत नहीं होती.
mobile-install
mobile-install
निर्देश, मोबाइल डिवाइसों पर ऐप्लिकेशन इंस्टॉल करता है.
फ़िलहाल, सिर्फ़ ART पर चलने वाले Android डिवाइस ही काम करते हैं.
अधिक जानकारी के लिए bazel मोबाइल-इंस्टॉल देखें.
ये विकल्प इस्तेमाल किए जा सकते हैं:
--incremental
अगर सेट हो, तो Bazel ऐप्लिकेशन को धीरे-धीरे इंस्टॉल करने की कोशिश करता है. इसका मतलब है कि सिर्फ़ उन
हिस्सों को इंस्टॉल करना है जिनमें पिछले बिल्ड के बाद बदलाव हुआ है. इससे, AndroidManifest.xml
, नेटिव कोड या Java रिसॉर्स (जैसे, Class.getResource()
में रेफ़र किए गए संसाधन) से जुड़े संसाधनों को अपडेट नहीं किया जा सकता. अगर इन चीज़ों में बदलाव होता है, तो इस विकल्प को शामिल नहीं करना चाहिए. Bazel की भावना के उलट, और Android प्लैटफ़ॉर्म की सीमाओं की वजह से, यह बताना उपयोगकर्ता की ज़िम्मेदारी है कि यह निर्देश कब काम का है और कब पूरा इंस्टॉल ज़रूरी है.
अगर आपके डिवाइस में Marshmallow या बाद के वर्शन का इस्तेमाल किया जा रहा है, तो
--split_apks
फ़्लैग देखें.
--split_apks
डिवाइस पर ऐप्लिकेशन इंस्टॉल और अपडेट करने के लिए, स्प्लिट apks का इस्तेमाल करना है या नहीं.
यह सुविधा, सिर्फ़ Marshmallow या इसके बाद के डिवाइसों पर काम करती है. ध्यान दें कि --split_apks
का इस्तेमाल करते समय, --incremental
फ़्लैग करना ज़रूरी नहीं है.
--start_app
इंस्टॉल करने के बाद ऐप्लिकेशन को साफ़ स्थिति में शुरू करता है. --start=COLD
के बराबर.
--debug_app
इंस्टॉल करने के बाद ऐप्लिकेशन को साफ़ स्थिति में शुरू करने से पहले, डीबगर के अटैच होने का इंतज़ार करता है.
--start=DEBUG
के बराबर.
--start=_start_type_
इंस्टॉल करने के बाद ऐप्लिकेशन को कैसे शुरू करना चाहिए. इन _start_type_s का इस्तेमाल किया जा सकता है:
NO
ऐप्लिकेशन चालू नहीं करता. यह डिफ़ॉल्ट सेटिंग है.COLD
इंस्टॉल होने के बाद, ऐप्लिकेशन को साफ़ स्थिति से शुरू करता है.WARM
बढ़ते हुए इंस्टॉल होने पर ऐप्लिकेशन की स्थिति को बनाए रखता है और उसे पहले जैसा करता है.DEBUG
इंस्टॉल होने के बाद, ऐप्लिकेशन को साफ़ स्थिति में शुरू करने से पहले, डीबगर का इंतज़ार करता है.
--adb=path
यह बताता है कि adb
बाइनरी का इस्तेमाल किया जाना है.
डिफ़ॉल्ट तौर पर, यह Android SDK में --android_sdk
से तय किए गए adb का इस्तेमाल करता है.
--adb_arg=serial
adb
में और तर्क. ये निर्देश, कमांड लाइन में सब-कमांड से पहले आते हैं. आम तौर पर, इनका इस्तेमाल यह तय करने के लिए किया जाता है कि किस डिवाइस पर इंस्टॉल करना है.
उदाहरण के लिए, जिस Android डिवाइस या एम्युलेटर का इस्तेमाल करना है उसे चुनने के लिए:
% bazel mobile-install --adb_arg=-s --adb_arg=deadbeef
adb
को इस तरह शुरू करता है
adb -s deadbeef install ...
--incremental_install_verbosity=number
इंक्रीमेंटल (बढ़ने वाले) इंस्टॉल के लिए वर्बोसिटी. कंसोल में प्रिंट किए जाने वाले डीबग लॉग को 1 पर सेट करें.
dump
dump
कमांड, Bazel सर्वर की अंदरूनी स्थिति के डंप आउट करने के लिए प्रिंट करता है. यह निर्देश मुख्य रूप से Bazel डेवलपर के इस्तेमाल के लिए है. इसलिए, इस निर्देश का आउटपुट तय नहीं किया गया है और इसमें बदलाव किया जा सकता है.
डिफ़ॉल्ट रूप से, कमांड सिर्फ़ सहायता मैसेज को प्रिंट करेगा. इसमें Bazel राज्य के खास हिस्सों को डंप करने के लिए संभावित विकल्प होंगे. किसी अंदरूनी स्थिति को डंप करने के लिए, कम से कम एक विकल्प तय किया जाना ज़रूरी है.
नीचे दिए गए विकल्प इस्तेमाल किए जा सकते हैं:
--action_cache
, कैश मेमोरी में मौजूद कार्रवाई के कॉन्टेंट को डंप करता है.--packages
, पैकेज की कैश मेमोरी के कॉन्टेंट को डंप करता है.--skyframe
, अंदरूनी Bazel डिपेंडेंसी ग्राफ़ की स्थिति को डंप करता है.--rules
हर नियम और आसपेक्ट क्लास के लिए, नियम की खास जानकारी डंप करता है. इसमें, संख्या और कार्रवाई की संख्या भी शामिल है. इसमें नेटिव और स्टारलार्क, दोनों नियम शामिल हैं. अगर मेमोरी ट्रैकिंग चालू है, तो नियमों की मेमोरी के इस्तेमाल की जानकारी भी प्रिंट की जाती है.--skylark_memory
तय किए गए पाथ पर, pprof काम करने वाली .gz फ़ाइल को डंप करता है. यह सुविधा काम करे, इसके लिए आपको मेमोरी ट्रैकिंग की सुविधा चालू करनी होगी.
मेमोरी ट्रैकिंग
कुछ dump
कमांड के लिए, मेमोरी ट्रैकिंग की ज़रूरत होती है. इसे चालू करने के लिए, आपको Bazel को
स्टार्टअप फ़्लैग पास करने होंगे:
--host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar
--host_jvm_args=-DRULE_MEMORY_TRACKER=1
Java-Agent की जांच Bazel में
third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar
पर की जाती है. इसलिए, पक्का करें कि आपने $BAZEL
को इस हिसाब से अडजस्ट किया हो कि आपको Bazel का डेटा स्टोर करने की जगह के हिसाब से सेट करना है.
हर निर्देश के लिए, Bazel को ये विकल्प पास करते रहना न भूलें. ऐसा न करने पर, सर्वर रीस्टार्ट हो जाएगा.
उदाहरण:
% bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar \ --host_jvm_args=-DRULE_MEMORY_TRACKER=1 \ build --nobuild <targets> # Dump rules % bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar \ --host_jvm_args=-DRULE_MEMORY_TRACKER=1 \ dump --rules # Dump Starlark heap and analyze it with pprof % bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar \ --host_jvm_args=-DRULE_MEMORY_TRACKER=1 \ dump --skylark_memory=$HOME/prof.gz % pprof -flame $HOME/prof.gz
analyze-profile
analyze-profile
कमांड, --profile
विकल्प का इस्तेमाल करके, बिल्ड
में पहले इकट्ठा किए गए डेटा का विश्लेषण करता है. इसमें कई विकल्प मिलते हैं. इनकी मदद से, बिल्ड एक्ज़ीक्यूशन का विश्लेषण किया जा सकता है या किसी खास फ़ॉर्मैट में डेटा एक्सपोर्ट किया जा सकता है.
ये विकल्प इस्तेमाल किए जा सकते हैं:
--dump
, इकट्ठा किए गए सारे डेटा को ऐसे फ़ॉर्मैट में दिखाता है जिसे कोई भी व्यक्ति आसानी से पढ़ सके. हालांकि, यह अभी दूसरे फ़ॉर्मैट के साथ काम नहीं करता.
फ़ॉर्मैट की जानकारी और इस्तेमाल करने से जुड़ी मदद के लिए, प्रोफ़ाइलिंग के ज़रिए परफ़ॉर्मेंस से जुड़ी समस्या हल करना देखें.
canonicalize-flags
canonicalize-flags
कमांड, जिसमें Bazel कमांड के लिए विकल्पों की सूची होती है और उन विकल्पों की सूची होती है जिनका असर एक जैसा होता है. विकल्पों की नई सूची कैननिकल है. उदाहरण के लिए,
एक जैसे इफ़ेक्ट वाले विकल्पों की दो सूचियों को एक ही नई सूची में कैननिकल के तौर पर बदला गया है.
--for_command
विकल्प का इस्तेमाल, अलग-अलग
कमांड में से चुनने के लिए किया जा सकता है. फ़िलहाल, सिर्फ़ build
और test
का इस्तेमाल किया जा सकता है. वे विकल्प जो दिए गए कमांड पर काम नहीं करते, गड़बड़ी पैदा करते हैं.
उदाहरण के लिए:
% bazel canonicalize-flags -- --config=any_name --test_tag_filters="-lint" --config=any_name --test_tag_filters=-lint
स्टार्टअप के विकल्प
इस सेक्शन में दिए गए विकल्प, Bazel सर्वर प्रोसेस के ज़रिए इस्तेमाल किए जाने वाले Java वर्चुअल मशीन के स्टार्टअप पर असर डालते हैं. साथ ही, ये विकल्प उस सर्वर से मैनेज किए जाने वाले सभी बाद के कमांड पर लागू होते हैं. अगर कोई Bazel सर्वर पहले से चल रहा है और शुरू करने के विकल्प मेल नहीं खा रहे हैं, तो यह रीस्टार्ट हो जाएगा.
इस सेक्शन में बताए गए सभी विकल्पों को, --key=value
या --key value
सिंटैक्स का इस्तेमाल करके बताया जाना चाहिए. साथ ही, ये विकल्प Bazel कमांड के नाम से पहले दिखने चाहिए. इन्हें .bazelrc
फ़ाइल में दिखाने के लिए, startup --key=value
का इस्तेमाल करें.
--output_base=dir
इस विकल्प के लिए एक पाथ आर्ग्युमेंट ज़रूरी है, जिसमें एक ऐसी डायरेक्ट्री बताई जानी चाहिए जिसे लिखा जा सके. Bazel अपने सभी आउटपुट लिखने के लिए, इस जगह का इस्तेमाल करेगा. आउटपुट बेस वह कुंजी भी होती है जिसका इस्तेमाल करके क्लाइंट, Bazel सर्वर खोजता है. आउटपुट बेस को बदलकर, सर्वर को बदला जाता है. यह कमांड को हैंडल करेगा.
डिफ़ॉल्ट रूप से, आउटपुट बेस उपयोगकर्ता के लॉगिन नाम और फ़ाइल फ़ोल्डर की डायरेक्ट्री (असल में, इसका MD5 डाइजेस्ट) के नाम से लिया जाता है,
इसलिए सामान्य वैल्यू कुछ इस तरह दिखती है:
/var/tmp/google/_bazel_johndoe/d41d8cd98f00b204e9800998ecf8427e
.
उदाहरण के लिए:
OUTPUT_BASE=/var/tmp/google/_bazel_johndoe/custom_output_base % bazel --output_base ${OUTPUT_BASE}1 build //foo & bazel --output_base ${OUTPUT_BASE}2 build //bar
इस निर्देश में, दो Bazel कमांड एक साथ चलते हैं (शेल &
ऑपरेटर की वजह से). दोनों कमांड एक-साथ, अलग-अलग Bazel सर्वर इंस्टेंस का इस्तेमाल करते हैं. ऐसा अलग-अलग आउटपुट बेस की वजह से होता है.
इसके उलट, अगर दोनों कमांड में डिफ़ॉल्ट आउटपुट बेस का इस्तेमाल किया गया था, तो दोनों अनुरोध एक ही सर्वर पर भेजे जाएंगे. इससे उन्हें एक क्रम में हैंडल किया जाएगा: पहले //foo
बनाना और फिर //bar
का इंक्रीमेंटल बिल्ड.
--output_user_root=dir
उस रूट डायरेक्ट्री पर ले जाता है जहां आउटपुट और इंस्टॉल बेस बनाए जाते हैं. डायरेक्ट्री मौजूद नहीं होनी चाहिए या कॉल करने वाले उपयोगकर्ता के पास होनी चाहिए. पहले इसे अलग-अलग उपयोगकर्ताओं के बीच शेयर की जाने वाली डायरेक्ट्री का इस्तेमाल करने की अनुमति दी जाती थी, लेकिन अब इसकी अनुमति नहीं है. समस्या #11100 के हल होने के बाद, इसकी अनुमति दी जा सकती है.
अगर --output_base
विकल्प दिया गया है, तो आउटपुट बेस की गिनती करने के लिए, --output_user_root
का इस्तेमाल करके ओवरराइड किया जाता है.
Android SDK के इंस्टॉल की जगह का हिसाब, --output_user_root
और Bazel से एम्बेड की गई बाइनरी की MD5 पहचान
के आधार पर किया जाता है.
अगर आपके फ़ाइल सिस्टम के लेआउट में बेहतर जगह मौजूद है, तो Bazel के सभी आउटपुट (इंस्टॉल बेस और आउटपुट बेस) के लिए वैकल्पिक बेस लोकेशन चुनने के लिए, --output_user_root
विकल्प का इस्तेमाल करें.
--server_javabase=dir
इस नीति से, उस Java वर्चुअल मशीन के बारे में पता चलता है जिसमें Bazel खुद चलता है. वैल्यू उस डायरेक्ट्री का पाथ होनी चाहिए जिसमें JDK या JRE शामिल हो. यह कोई लेबल नहीं होना चाहिए. यह विकल्प किसी भी Bazel कमांड से पहले दिखना चाहिए, उदाहरण के लिए:
% bazel --server_javabase=/usr/local/buildtools/java/jdk11 build //foo
यह फ़्लैग उन JVMs पर असर नहीं डालता, जिनका इस्तेमाल Bazel सबप्रोसेस में होता है. जैसे, ऐप्लिकेशन, टेस्ट, टूल वगैरह. इसके बजाय, बिल्ड विकल्प --javabase या --host_javabase का इस्तेमाल करें.
इस फ़्लैग का नाम पहले --host_javabase
था (इसे कभी-कभी 'बाईं ओर का --host_javabase
' भी कहा जाता है), लेकिन बिल्ड फ़्लैग --host_javabase (कभी-कभी इसे 'दाईं ओर' --host_javabase
भी कहा जाता है) से जुड़ी ग़लतफ़हमी से बचने के लिए, इसका नाम बदल दिया गया.
--host_jvm_args=string
यह Java वर्चुअल मशीन को पास किए जाने वाले स्टार्टअप विकल्प के बारे में बताती है. इसमें Bazel खुद चलता है. इसका इस्तेमाल स्टैक का साइज़ सेट करने के लिए किया जा सकता है. उदाहरण के लिए:
% bazel --host_jvm_args="-Xss256K" build //foo
इस विकल्प का इस्तेमाल, अलग-अलग आर्ग्युमेंट के साथ कई बार किया जा सकता है. ध्यान दें कि इस फ़्लैग को सेट करने की ज़रूरत शायद ही कभी पड़ती हो. आपके पास स्ट्रिंग की स्पेस से अलग की गई सूची को भी पास करने का विकल्प है. इसमें से हर एक को अलग JVM आर्ग्युमेंट के तौर पर माना जाएगा. हालांकि, यह सुविधा जल्द ही बंद कर दी जाएगी.
इसका असर ऐसे किसी भी जेवीएम पर नहीं होता है जिसका इस्तेमाल Bazel के सब-प्रोसेस में किया जाता है. जैसे: ऐप्लिकेशन, टेस्ट, टूल वगैरह. जेवीएम के विकल्पों को bazel
run
से चलाए जाने वाले या कमांड लाइन पर चलाए जाने वाले एक्ज़ीक्यूटेबल Java प्रोग्राम में भेजने के लिए, आपको --jvm_flags
आर्ग्युमेंट इस्तेमाल करना होगा. यह सभी java_binary
और java_test
प्रोग्राम के साथ काम करता है. इसके अलावा, जांच के लिए, bazel test --test_arg=--jvm_flags=foo ...
का इस्तेमाल करें.
--host_jvm_debug
इस विकल्प की वजह से Java वर्चुअल मशीन, Bazel के मुख्य तरीके को कॉल करने से पहले, JDWP-अनुपालन डीबगर से कनेक्शन के लिए इंतज़ार करती है. मुख्य रूप से, इसे Bazel डेवलपर इस्तेमाल करने के लिए बनाया गया है.
--autodetect_server_javabase
इस विकल्प से शुरू होने पर Bazel, इंस्टॉल किए गए JDK को अपने-आप खोजता है.
अगर एम्बेड किया गया JRE उपलब्ध नहीं है, तो वह इंस्टॉल किए गए JRE पर वापस चला जाता है.
--explicit_server_javabase
का इस्तेमाल, खास तौर पर एक JRE चुनने के लिए किया जा सकता है,
जिससे Bazel को चलाया जा सकता है.
--batch
बैच मोड की वजह से Bazel, स्टैंडर्ड क्लाइंट/सर्वर मोड का इस्तेमाल नहीं करता है. इसके बजाय, वह एक कमांड के लिए bazel Java प्रोसेस चलाता है. इसका इस्तेमाल सिग्नल हैंडलिंग, जॉब कंट्रोल, और एनवायरमेंट वैरिएबल इनहेरिटेंस के हिसाब से, ज़्यादा अनुमान लगाने लायक सिमैंटिक के लिए किया जाता है. साथ ही, यह क्रोट जेल में bazel चलाने के लिए ज़रूरी है.
बैच मोड, एक हीout_base में, सूची के सही सिमैंटिक बनाए रखता है. इसका मतलब है कि बातचीत को शुरू करने वाली प्रक्रिया, बिना किसी ओवरलैप के क्रम में प्रोसेस की जाएगी. अगर बैच मोड Bazel, क्लाइंट पर चल रहे सर्वर पर चलाया जाता है, तो यह निर्देश को प्रोसेस करने से पहले सर्वर को बंद कर देता है.
Bazel, बैच मोड में या ऊपर बताए गए विकल्पों के साथ धीमा चलेगा. ऐसा इसलिए होता है, क्योंकि दूसरी चीज़ों के अलावा, बिल्ड फ़ाइल कैश मेमोरी में सेव होता है, इसलिए इसे क्रम से चलने वाले बैच को शुरू करने के दौरान सेव नहीं किया जाता. इसलिए, बैच मोड का इस्तेमाल करना अक्सर ऐसे मामलों में ज़्यादा कारगर होता है जहां परफ़ॉर्मेंस की अहमियत कम होती है. जैसे, लगातार बिल्ड करने की प्रोसेस.
--max_idle_secs=n
इस विकल्प से यह तय होता है कि Bazel सर्वर की प्रोसेस, कितने सेकंड में या कितनी देर तक इंतज़ार कर सकती है. इसके बाद, यह प्रोसेस बंद हो सकती है. डिफ़ॉल्ट वैल्यू 10,800 (तीन घंटे) है. --max_idle_secs=0
की वजह से,
Bazel सर्वर की प्रोसेस हमेशा के लिए बनी रहेगी.
इस विकल्प का इस्तेमाल उन स्क्रिप्ट में किया जा सकता है जो Bazel को शुरू करती हैं. इससे यह पक्का किया जाता है कि अगर वे किसी और तरीके से
नहीं चल रहे हैं, तो वे उपयोगकर्ता की मशीन पर Bazel सर्वर की प्रोसेस को नहीं छोड़ेंगे.
उदाहरण के लिए, हो सकता है कि पहले से सबमिट की गई स्क्रिप्ट bazel query
को शुरू करना चाहे, ताकि यह पक्का किया जा सके कि उपयोगकर्ता के बदलावों की वजह से अनचाहे बदलाव न हों. हालांकि, अगर उपयोगकर्ता ने उस फ़ाइल फ़ोल्डर में हाल ही का कोई बिल्ड नहीं किया है, तो प्रीसबमिट स्क्रिप्ट के लिए Bazel सर्वर शुरू करना सही नहीं होगा.
क्वेरी के अनुरोध में --max_idle_secs
की एक छोटी वैल्यू तय करके, स्क्रिप्ट यह पक्का कर सकती है कि if इसकी वजह से कोई नया सर्वर चालू हुआ, तो वह तुरंत बंद हो जाएगा. अगर सर्वर पहले से काम कर रहा था, तो वह तब तक चलता रहेगा, जब तक कि वह हमेशा के लिए इस्तेमाल में नहीं रहता. बेशक, मौजूदा सर्वर का
कुछ समय से इस्तेमाल में न होने का टाइमर रीसेट कर दिया जाएगा.
--[no]shutdown_on_low_sys_mem
अगर यह नीति चालू है और --max_idle_secs
पॉज़िटिव अवधि पर सेट है, तो बिल्ड सर्वर के कुछ समय तक इस्तेमाल न होने पर, सिस्टम की मेमोरी कम होने पर सर्वर को बंद कर दें. सिर्फ़ Linux.
max_idle_secs के हिसाब से इस्तेमाल में न होने पर जांच करने के अलावा, बिल्ड सर्वर कुछ समय के लिए सर्वर का इस्तेमाल न किए जाने पर, उपलब्ध सिस्टम मेमोरी की निगरानी करना भी शुरू कर देगा. अगर उपलब्ध सिस्टम मेमोरी बहुत कम हो जाती है, तो सर्वर बंद हो जाएगा.
--[no]block_for_lock
अगर यह सुविधा चालू की जाती है, तो Bazel प्रक्रिया पूरी होने से पहले, सर्वर लॉक को होल्ड करने वाले दूसरे Bazel कमांड का इंतज़ार करेगा. अगर बंद कर दिया जाता है, तो अगर Bazel तुरंत लॉक नहीं हासिल कर पाएगा और आगे नहीं चलेगा, तो वह गलती से बंद हो जाएगा.
डेवलपर, पहले से सबमिट किए गए पेज की जांच में इसका इस्तेमाल कर सकते हैं. ऐसा इसलिए किया जाता है, ताकि उसी क्लाइंट में दूसरे Bazel कमांड की वजह से ज़्यादा इंतज़ार न हो.
--io_nice_level=n
IO को शेड्यूल करने की बेहतरीन प्रोसेस के लिए, 0-7 तक का लेवल सेट करता है. 0 सबसे ऊंची प्राथमिकता है, 7 सबसे कम है. ऐसा हो सकता है कि शेड्यूलर सिर्फ़ चार प्राथमिकता पर ही काम करे. नेगेटिव वैल्यू को नज़रअंदाज़ कर दिया जाता है.
--batch_cpu_scheduling
Bazel के लिए batch
सीपीयू शेड्यूलिंग का इस्तेमाल करें. यह नीति ऐसे वर्कलोड के लिए फ़ायदेमंद है
जो नॉन-इंटरैक्टिव हैं, लेकिन उनका सही मान कम नहीं करना चाहते.
'पुरुष 2 sched_setscheduler' देखें. इस नीति से Bazel की थ्रूपुट लागत पर, सिस्टम से बेहतर
इंटरैक्टिविटी मिल सकती है.
अन्य विकल्प
--[no]announce_rc
यह नीति कंट्रोल करती है कि क्या Bazel, शुरू करते समय bazelrc फ़ाइल से मिलने वाले कमांड के विकल्पों का एलान करता है. (स्टार्टअप विकल्पों की घोषणा बिना किसी शर्त के की जाती है.)
--color (yes|no|auto)
इस विकल्प से यह तय होता है कि Bazel, स्क्रीन पर अपने आउटपुट को हाइलाइट करने के लिए रंगों का इस्तेमाल करेगा या नहीं.
अगर यह विकल्प yes
पर सेट है, तो कलर आउटपुट चालू हो जाता है.
अगर यह विकल्प auto
पर सेट किया गया है, तो Bazel कलर आउटपुट का इस्तेमाल सिर्फ़ तब करेगा, जब आउटपुट टर्मिनल पर भेजा जा रहा हो और TERM एनवायरमेंट वैरिएबल को dumb
, emacs
या xterm-mono
के अलावा किसी दूसरी वैल्यू पर सेट किया गया हो.
अगर यह विकल्प no
पर सेट किया जाता है, तो कलर आउटपुट बंद है.
इससे कोई फ़र्क़ नहीं पड़ता कि आउटपुट टर्मिनल पर ले जा रहा है या नहीं. साथ ही, TERM के एनवायरमेंट वैरिएबल की सेटिंग पर ध्यान दिए बिना.
--config=name
rc फ़ाइलों से, अन्य कॉन्फ़िगरेशन सेक्शन चुना जाता है. मौजूदा command
के लिए, अगर ऐसा सेक्शन मौजूद होता है, तो यह command:name
से भी विकल्प चुन लेता है. कई कॉन्फ़िगरेशन सेक्शन से फ़्लैग जोड़ने के लिए, कई बार तय किया जा सकता है. एक्सपैंशन, अन्य परिभाषाएं हो सकते हैं (उदाहरण के लिए, एक्सपैंशन को चेन किया जा सकता है).
--curses (yes|no|auto)
इस विकल्प से तय होता है कि Bazel अपने स्क्रीन आउटपुट में
कर्सर कंट्रोल का इस्तेमाल करेगा या नहीं. इससे डेटा को स्क्रोल करने की ज़रूरत कम हो जाती है और Bazel के आउटपुट की,
आसानी से पढ़ने में मदद मिलती है. यह
--color
के साथ बढ़िया काम करता है.
अगर यह विकल्प yes
पर सेट है, तो कर्सर कंट्रोल का इस्तेमाल चालू हो जाएगा.
अगर यह विकल्प no
पर सेट किया जाता है, तो कर्सर कंट्रोल का इस्तेमाल बंद हो जाता है.
अगर इस विकल्प को auto
पर सेट किया जाता है, तो कर्सर कंट्रोल की सुविधा --color=auto
जैसी स्थितियों में चालू होगी.
--[no]show_timestamps
अगर यह बताया गया है, तो Bazel के जनरेट किए गए हर मैसेज के लिए, एक टाइमस्टैंप जोड़ा जाता है. टाइमस्टैंप से यह पता चलता है कि मैसेज किस समय दिखाया गया था.