निर्देश और विकल्प

इस पेज पर उन विकल्पों के बारे में बताया गया है जो 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

पैकेज पाथ के एलिमेंट तीन फ़ॉर्मैट में दिखाए जा सकते हैं:

1. अगर पहला वर्ण / है, तो पाथ की वैल्यू नहीं बताई जाती है.
2. अगर पाथ %workspace% से शुरू होता है, तो पाथ को पास की नज़दीकी बेज़ल डायरेक्ट्री के हिसाब से लिया जाता है. उदाहरण के लिए, अगर आपकी वर्किंग डायरेक्ट्री /home/bob/clients/bob_client/bazel/foo है, तो पैकेज-पाथ में मौजूद स्ट्रिंग %workspace% को /home/bob/clients/bob_client/bazel में बड़ा कर दिया जाएगा.
3. अन्य कोई भी चीज़, वर्किंग डायरेक्ट्री से जुड़ी होती है. आम तौर पर, यह आपकी ज़रूरत से मेल नहीं खाता. अगर 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 लाइब्रेरी को कंपाइल करेगा, ताकि पोज़िशन-इंडिपेंडेंट कोड जनरेट हो सके.

ध्यान दें: --copt की सेटिंग बदलने पर, उन सभी ऑब्जेक्ट फ़ाइलों को फिर से कंपाइल किया जाएगा जिन पर असर पड़ा है. यह भी ध्यान दें कि खास cc_library या cc_binary बिल्ड रूल में लिस्ट की गई कॉप्ट वैल्यू को कंपाइलर कमांड लाइन पर, इन विकल्पों के बाद रखा जाएगा.

चेतावनी: C++ के हिसाब से विकल्प (जैसे -fno-implicit-templates) की वैल्यू --cxxopt में बताई जानी चाहिए, --copt में नहीं. इसी तरह, सी के हिसाब से दिए गए विकल्पों (जैसे कि -Wstrict-prototypes) को copt में नहीं, --conlyopt में बताया जाना चाहिए. इसी तरह, कंपाइलर के ऐसे विकल्प जिनका लिंक समय पर असर पड़ता है (जैसे कि -l), उनकी जानकारी --linkopt में दी जानी चाहिए, --copt में नहीं.

--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) पास किए जा सकते हैं.

ध्यान दें: खास cc_library या cc_binary बिल्ड रूल में बताए गए कॉप पैरामीटर, कंपाइलर कमांड लाइन पर इन विकल्पों के बाद रखे जाते हैं.

--cxxopt=cc-option

इस विकल्प में एक तर्क होता है, जिसे C++ सोर्स फ़ाइलों को कंपाइल करते समय, कंपाइलर को भेजा जाता है.

यह --copt जैसा है. हालांकि, यह सिर्फ़ C++ कंपाइलेशन पर लागू होता है, C कंपाइलेशन या लिंकिंग पर नहीं. इसलिए, --cxxopt का इस्तेमाल करके C++ के खास विकल्प (जैसे कि -fpermissive या -fno-implicit-templates) पास किए जा सकते हैं.

उदाहरण के लिए:

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

ध्यान दें: खास cc_library या cc_binary बिल्ड रूल में बताए गए पैरामीटर को, इन विकल्पों के बाद कंपाइलर कमांड लाइन पर रखा जाता है.

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

जनरेट की गई सभी बाइनरी से डीबग करने की जानकारी हटाकर, टारगेट को कंपाइल करेगा.

ध्यान दें: अगर आपको डीबग करने की जानकारी चाहिए, तो स्ट्रिपिंग को बंद करना ही काफ़ी नहीं है. आपको यह भी पक्का करना होगा कि डीबग करने की जानकारी, कंपाइलर ने जनरेट की हो. ऐसा -c dbg या --copt -g का इस्तेमाल करके किया जा सकता है.

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 है. इस विकल्प का इस्तेमाल एक से ज़्यादा बार किया जा सकता है.

ध्यान दें: --stripopt, [--strip](#flag--strip)=(always|sometimes) के साथ मुख्य बाइनरी को अलग करने पर लागू नहीं होता.

--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 एक्सटेंशन से पहचानी गई ऑटो प्रोफ़ाइल की तरफ़ इशारा कर सकता है.

ध्यान दें: यह विकल्प उन लेबल को भी स्वीकार करता है जो सोर्स फ़ाइलों में सेव होते हैं. फ़ाइल को Bazel को दिखाने के लिए, आपको इससे जुड़े पैकेज में exports_files डायरेक्टिव जोड़ना पड़ सकता है.

एलएलवीएम कंपाइलर के लिए दिया गया तर्क, 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

ध्यान दें: --javacopt की सेटिंग में बदलाव करने पर, उन सभी क्लास को फिर से कंपाइल किया जाएगा जिन पर असर पड़ा है. यह भी ध्यान रखें कि इन विकल्पों के बाद, खास java_library या java_binary बिल्ड रूल में शामिल javacopts पैरामीटर को javac कमांड लाइन पर रखा जाएगा.

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

यह विकल्प बिल्ड के दौरान बाइनरी के कंपाइलेशन के लिए इस्तेमाल किए जाने वाले टारगेट सीपीयू आर्किटेक्चर को तय करता है.

ध्यान दें: क्रॉसटूल वर्शन, कंपाइलर वर्शन, और टारगेट सीपीयू के किसी खास कॉम्बिनेशन की अनुमति सिर्फ़ तब दी जाती है, जब उनकी जानकारी, मौजूदा समय में इस्तेमाल की जाने वाली CROSSTOOL फ़ाइल में दी गई हो.

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

चेतावनी: अतिरिक्त कार्रवाइयां अब काम नहीं करतीं. इसके बजाय, aspects का इस्तेमाल करें.

अगर यह विकल्प 'सही' पर सेट है, तो --experimental_action_listener कमांड लाइन विकल्प से तय की गई अतिरिक्त कार्रवाइयां, सिर्फ़ टॉप लेवल टारगेट के लिए शेड्यूल की जाएंगी.

--experimental_extra_action_filter=regex

चेतावनी: अतिरिक्त कार्रवाइयां अब काम नहीं करतीं. इसके बजाय, aspects का इस्तेमाल करें.

यह 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 होगी.

ध्यान दें: Android के साथ काम करने वाला क्रॉसटूल चुनना ज़रूरी है. अगर Workspace की फ़ाइल में android_ndk_repository नियम बताया गया है, तो Android के साथ काम करने वाले क्रॉसटूल को अपने-आप चुन लिया जाता है. इसके अलावा, --android_crosstool_top या --crosstool_top फ़्लैग का इस्तेमाल करके भी क्रोस्टूल को चुना जा सकता है.

--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") बनाते हैं. डिफ़ॉल्ट रूप से यह बंद रहता है.

ध्यान दें: डाइनैमिक तौर पर लिंक की गई बाइनरी (उदाहरण के लिए, --dynamic_mode fully) पीआईसी कोड जनरेट करती हैं, चाहे इस फ़्लैग की सेटिंग कुछ भी हो. यह फ़्लैग उन मामलों के लिए है जहां उपयोगकर्ता चाहते हैं कि स्टैटिक लिंक के लिए, साफ़ तौर पर पीआईसी कोड जनरेट किया जाए.

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

एक पूर्णांक तर्क वाला यह विकल्प, उन जॉब की संख्या की सीमा तय करता है जिन्हें बिल्ड के एक्ज़ीक्यूट होने के चरण के दौरान एक साथ चलाया जाना चाहिए.

ध्यान दें: Bazel के लिए एक साथ चलाए जाने वाले जॉब की संख्या, न सिर्फ़ --jobs सेटिंग से तय होती है, बल्कि Bazel का शेड्यूलर भी तय करता है. Bazel का शेड्यूलर, उपलब्ध संसाधनों से ज़्यादा संसाधनों (रैम या सीपीयू) का इस्तेमाल करने से बचने की कोशिश करता है. शेड्यूलर के व्यवहार को --local_ram_resources विकल्प से कंट्रोल किया जा सकता है.

--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 ऐसे इंटरफ़ेस जार बनाएगा जिनमें सिर्फ़ गैर-निजी सदस्यों (सार्वजनिक, सुरक्षित, और डिफ़ॉल्ट (पैकेज) ऐक्सेस करने के तरीकों और फ़ील्ड के हस्ताक्षर शामिल होंगे. साथ ही, डिपेंडेंट टारगेट को कंपाइल करने के लिए इंटरफ़ेस जार का इस्तेमाल करेंगे. इसकी मदद से, सिर्फ़ मेथड बॉडी या क्लास के निजी सदस्यों में किए जाने वाले बदलावों को दोबारा कंपाइल करने से बचा जा सकता है.

ध्यान दें: --use_ijars का इस्तेमाल करने पर, आपको गलती से किसी दूसरी क्लास के ऐसे सदस्य के बारे में बताने पर गड़बड़ी का अलग मैसेज मिल सकता है जो नहीं दिखता है: सदस्य नहीं दिख रहा है, तो आपको गड़बड़ी का यह मैसेज मिलेगा कि सदस्य मौजूद नहीं है. --use_ijars की सेटिंग में बदलाव करने पर, उन सभी क्लास को फिर से कंपाइल किया जाएगा जिन पर असर पड़ा है.

--[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 को लागू करने में, कंपाइलर के -save-temps फ़्लैग का इस्तेमाल नहीं किया जाता. इसके बजाय, आपके पास दो पास हैं, एक -S और दूसरा -E वाला है. इसके नतीजे के तौर पर, अगर आपका बिल्ड काम नहीं करता, तो हो सकता है कि Bazel ने अभी तक ".i" या ".ii" और ".s" फ़ाइलें न बनाई हों. अगर आपने कंपाइलेशन न कर पाने वाली फ़ाइलों को डीबग करने के लिए, --save_temps का इस्तेमाल किया है, तो आपको --keep_going का भी इस्तेमाल करना पड़ सकता है. इससे, कंपाइलेशन पूरा न होने पर भी Bazel, पहले से प्रोसेस की गई फ़ाइलें बनाने की कोशिश करेगा.

फ़िलहाल, --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=/ की वजह से, Bazel bazel-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 को कॉल करना देखें. खास तौर पर, नीचे दिए गए विकल्पों का सुझाव दिया जाता है:

• --bazelrc=/dev/null
• --nokeep_state_after_build

ये विकल्प भी ज़रूरी हैं:

• --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 के साथ टेस्ट चलाने को कैश मेमोरी में सेव कर सकता है.

ध्यान दें: टेस्ट के नतीजे, Bazel के आउटपुट ट्री में हमेशा सेव रहते हैं. इससे कोई फ़र्क़ नहीं पड़ता कि यह विकल्प चालू है या नहीं. इसलिए, कैश हिट पाने के लिए, आपको bazel test के पहले वाले रन पर --cache_test_results का इस्तेमाल नहीं करना होगा. इस विकल्प का असर सिर्फ़ इस बात पर होता है कि Bazel पहले से सेव किए गए नतीजों का इस्तेमाल करेगा या नहीं. हालांकि, यह इस बात पर निर्भर नहीं करेगा कि वह मौजूदा क्वेरी के नतीजों को सेव करेगा या नहीं.

जिन उपयोगकर्ताओं ने अपनी .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 का टाइम आउट नहीं होना चाहिए, क्योंकि ये बहुत ही बड़े काम हैं.

इस विकल्प से उपयोगकर्ताओं को सही टाइम आउट वैल्यू तय करने या मौजूदा टाइम आउट वैल्यू की जांच करने में मदद मिलती है.

ध्यान दें: हर टेस्ट शार्ड को पूरे XX_test टारगेट का टाइम आउट दिया जाता है. इस विकल्प का इस्तेमाल करने से, टेस्ट के टाइम आउट की वैल्यू पर कोई असर नहीं पड़ता. यह सिर्फ़ तब चेतावनी देता है, जब Bazel को लगता है कि टाइम आउट को और सीमित किया जा सकता है.

--[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 आउटपुट बेस डायरेक्ट्री के तहत रखेगा.

ध्यान दें: यह डायरेक्ट्री, टेस्ट करने के लिए है. इसमें, टेस्ट के नतीजों को सेव नहीं किया जाता (उन्हें हमेशा bazel-out डायरेक्ट्री में सेव किया जाता है).

--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, --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 कमांड का इस्तेमाल करना सुरक्षित होता है.

ध्यान दें: इससे IO के लिए विवाद हो सकता है.

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 कमांड अब भी एक्सपेरिमेंट के तौर पर उपलब्ध है और उसका एपीआई बदल जाएगा.

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 मोबाइल-इंस्टॉल देखें.

ध्यान दें: यह निर्देश उस चीज़ को इंस्टॉल नहीं करता है जो bazel build बनाती है: 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 इंस्टॉल होने के बाद, ऐप्लिकेशन को साफ़ स्थिति में शुरू करने से पहले, डीबगर का इंतज़ार करता है.

ध्यान दें: अगर --start=_start_type_, --start_app या --debug_app में से एक से ज़्यादा को सेट किया गया है, तो आखिरी वैल्यू का इस्तेमाल किया जाता है.

--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 यह पक्का नहीं कर सकता कि इफ़ेक्ट एक जैसा है. यह भी ध्यान रखें कि यह निर्देश --config से मिलने वाले फ़्लैग को बड़ा नहीं करता.

उदाहरण के लिए:

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

ध्यान दें: क्लाइंट, Bazel सर्वर इंस्टेंस ढूंढने के लिए आउटपुट बेस का इस्तेमाल करता है. इसलिए, अगर Bazel कमांड में कोई दूसरा आउटपुट बेस तय किया जाता है, तो अनुरोध को हैंडल करने के लिए एक अलग सर्वर मिलेगा (या शुरू किया जाएगा). आउटपुट बेस में बदलाव करके, एक ही फ़ाइल फ़ोल्डर डायरेक्ट्री में दो एक साथ बनाए जा सकते हैं.

उदाहरण के लिए:

 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 का इंक्रीमेंटल बिल्ड.

ध्यान दें: हमारा सुझाव है कि आप रूट डायरेक्ट्री के लिए, NFS या उससे मिलते-जुलते नेटवर्क वाले फ़ाइल सिस्टम का इस्तेमाल न करें. ऐसा इसलिए, क्योंकि जब इंतज़ार का समय ज़्यादा होगा, तो बिल्ड की प्रोसेस धीमी हो जाएगी.

--output_user_root=dir

उस रूट डायरेक्ट्री पर ले जाता है जहां आउटपुट और इंस्टॉल बेस बनाए जाते हैं. डायरेक्ट्री मौजूद नहीं होनी चाहिए या कॉल करने वाले उपयोगकर्ता के पास होनी चाहिए. पहले इसे अलग-अलग उपयोगकर्ताओं के बीच शेयर की जाने वाली डायरेक्ट्री का इस्तेमाल करने की अनुमति दी जाती थी, लेकिन अब इसकी अनुमति नहीं है. समस्या #11100 के हल होने के बाद, इसकी अनुमति दी जा सकती है.

अगर --output_base विकल्प दिया गया है, तो आउटपुट बेस की गिनती करने के लिए, --output_user_root का इस्तेमाल करके ओवरराइड किया जाता है.

Android SDK के इंस्टॉल की जगह का हिसाब, --output_user_root और Bazel से एम्बेड की गई बाइनरी की MD5 पहचान के आधार पर किया जाता है.

अगर आपके फ़ाइल सिस्टम के लेआउट में बेहतर जगह मौजूद है, तो Bazel के सभी आउटपुट (इंस्टॉल बेस और आउटपुट बेस) के लिए वैकल्पिक बेस लोकेशन चुनने के लिए, --output_user_root विकल्प का इस्तेमाल करें.

ध्यान दें: हमारा सुझाव है कि आप रूट डायरेक्ट्री के लिए, NFS या उससे मिलते-जुलते नेटवर्क वाले फ़ाइल सिस्टम का इस्तेमाल न करें. ऐसा इसलिए, क्योंकि जब इंतज़ार का समय ज़्यादा होगा, तो बिल्ड की प्रोसेस धीमी हो जाएगी.

--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 डेवलपर इस्तेमाल करने के लिए बनाया गया है.

ध्यान दें: इसका असर ऐसे किसी भी JVM पर नहीं होता है जिसका इस्तेमाल Bazel के सब-प्रोसेस में किया जाता है: ऐप्लिकेशन, टेस्ट, टूल वगैरह

--autodetect_server_javabase

इस विकल्प से शुरू होने पर Bazel, इंस्टॉल किए गए JDK को अपने-आप खोजता है. अगर एम्बेड किया गया JRE उपलब्ध नहीं है, तो वह इंस्टॉल किए गए JRE पर वापस चला जाता है. --explicit_server_javabase का इस्तेमाल, खास तौर पर एक JRE चुनने के लिए किया जा सकता है, जिससे Bazel को चलाया जा सकता है.

--batch

बैच मोड की वजह से Bazel, स्टैंडर्ड क्लाइंट/सर्वर मोड का इस्तेमाल नहीं करता है. इसके बजाय, वह एक कमांड के लिए bazel Java प्रोसेस चलाता है. इसका इस्तेमाल सिग्नल हैंडलिंग, जॉब कंट्रोल, और एनवायरमेंट वैरिएबल इनहेरिटेंस के हिसाब से, ज़्यादा अनुमान लगाने लायक सिमैंटिक के लिए किया जाता है. साथ ही, यह क्रोट जेल में bazel चलाने के लिए ज़रूरी है.

बैच मोड, एक हीout_base में, सूची के सही सिमैंटिक बनाए रखता है. इसका मतलब है कि बातचीत को शुरू करने वाली प्रक्रिया, बिना किसी ओवरलैप के क्रम में प्रोसेस की जाएगी. अगर बैच मोड Bazel, क्लाइंट पर चल रहे सर्वर पर चलाया जाता है, तो यह निर्देश को प्रोसेस करने से पहले सर्वर को बंद कर देता है.

Bazel, बैच मोड में या ऊपर बताए गए विकल्पों के साथ धीमा चलेगा. ऐसा इसलिए होता है, क्योंकि दूसरी चीज़ों के अलावा, बिल्ड फ़ाइल कैश मेमोरी में सेव होता है, इसलिए इसे क्रम से चलने वाले बैच को शुरू करने के दौरान सेव नहीं किया जाता. इसलिए, बैच मोड का इस्तेमाल करना अक्सर ऐसे मामलों में ज़्यादा कारगर होता है जहां परफ़ॉर्मेंस की अहमियत कम होती है. जैसे, लगातार बिल्ड करने की प्रोसेस.

चेतावनी: --batch, स्टैंडर्ड क्लाइंट/सर्वर मोड की तुलना में काफ़ी धीमा है. इसके अलावा, हो सकता है कि इसमें वे सभी सुविधाएं और ऑप्टिमाइज़ेशन काम न करें जो एक स्थायी Bazel सर्वर से संभव हुए हैं. अगर --batch का इस्तेमाल आइसोलेशन के लिए किया जा रहा है, तो आपको कमांड विकल्प --nokeep_state_after_build का इस्तेमाल करना चाहिए. इससे यह पक्का किया जाता है कि बिल्ड के बीच मेमोरी में बढ़ोतरी वाली स्थिति को सेव न किया जाए. बिल्ड के बाद Bazel सर्वर और JVM को रीस्टार्ट करने के लिए, कृपया "शटडाउन" कमांड का इस्तेमाल करके, साफ़ तौर पर ऐसा करें.

--max_idle_secs=n

इस विकल्प से यह तय होता है कि Bazel सर्वर की प्रोसेस, कितने सेकंड में या कितनी देर तक इंतज़ार कर सकती है. इसके बाद, यह प्रोसेस बंद हो सकती है. डिफ़ॉल्ट वैल्यू 10,800 (तीन घंटे) है. --max_idle_secs=0 की वजह से, Bazel सर्वर की प्रोसेस हमेशा के लिए बनी रहेगी.

ध्यान दें: यह फ़्लैग सिर्फ़ तब पढ़ा जाता है, जब 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 के जनरेट किए गए हर मैसेज के लिए, एक टाइमस्टैंप जोड़ा जाता है. टाइमस्टैंप से यह पता चलता है कि मैसेज किस समय दिखाया गया था.