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

इस पेज पर, Bazel के अलग-अलग कमांड के साथ उपलब्ध विकल्पों के बारे में बताया गया है. जैसे, bazel build, bazel run, और bazel test. यह पेज, Build with Bazel में Bazel की कमांड की सूची के साथ काम करता है.

टारगेट सिंटैक्स

build या test जैसे कुछ निर्देश, टारगेट की सूची पर काम कर सकते हैं. ये लेबल की तुलना में ज़्यादा फ़्लेक्सिबल सिंटैक्स का इस्तेमाल करते हैं. इसके बारे में बनाने के लिए टारगेट तय करना में बताया गया है.

विकल्प

यहां दिए गए सेक्शन में, बिल्ड के दौरान उपलब्ध विकल्पों के बारे में बताया गया है. जब किसी सहायता कमांड पर --long का इस्तेमाल किया जाता है, तो ऑनलाइन सहायता मैसेज में हर विकल्प के मतलब, टाइप, और डिफ़ॉल्ट वैल्यू के बारे में खास जानकारी मिलती है.

ज़्यादातर विकल्पों को सिर्फ़ एक बार तय किया जा सकता है. जब कई बार बताया गया हो, तो आखिरी इंस्टेंस जीतता है. जिन विकल्पों को एक से ज़्यादा बार तय किया जा सकता है उन्हें ऑनलाइन सहायता में 'एक से ज़्यादा बार इस्तेमाल किया जा सकता है' टेक्स्ट के साथ दिखाया गया है.

पैकेज की जगह

--package_path

चेतावनी: --package_path विकल्प के इस्तेमाल पर रोक लगा दी गई है. Bazel, मुख्य रिपॉज़िटरी में मौजूद पैकेज को वर्कस्पेस रूट के नीचे रखने का सुझाव देता है.

इस विकल्प से, डायरेक्ट्री का वह सेट तय होता है जिसमें किसी पैकेज के लिए BUILD फ़ाइल खोजी जाती है.

Bazel, पैकेज के पाथ को खोजकर अपने पैकेज ढूंढता है. यह कोलन से अलग की गई, क्रम से लगाई गई Bazel डायरेक्ट्री की सूची है. इनमें से हर डायरेक्ट्री, सोर्स ट्री के किसी हिस्से की रूट डायरेक्ट्री होती है.

--package_path विकल्प का इस्तेमाल करके, कस्टम पैकेज पाथ तय करने के लिए:

  % bazel build --package_path %workspace%:/some/other/root

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

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

उदाहरण: खाली क्लाइंट से बनाना

  % mkdir -p foo/bazel
  % cd foo/bazel
  % touch MODULE.bazel
  % bazel build --package_path /some/other/path //foo

--deleted_packages

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

गड़बड़ी की जांच करना

इन विकल्पों से, Bazel की गड़बड़ी की जांच और/या चेतावनियों को कंट्रोल किया जाता है.

--[no]check_visibility

अगर इस विकल्प को 'गलत' पर सेट किया जाता है, तो दिखने से जुड़ी जांचों को चेतावनियों में बदल दिया जाता है. इस विकल्प की डिफ़ॉल्ट वैल्यू 'सही' होती है, ताकि डिफ़ॉल्ट रूप से, दिखने से जुड़ी जांच की जा सके.

--output_filter=regex

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

इस विकल्प के लिए, यहां कुछ सामान्य वैल्यू दी गई हैं:

टूल फ़्लैग

इन विकल्पों से यह तय किया जाता है कि Bazel, अन्य टूल को कौनसे विकल्प पास करेगा.

--copt=cc-option

यह विकल्प एक ऐसा आर्ग्युमेंट लेता है जिसे कंपाइलर को पास किया जाना है. जब भी कंपाइलर को C, C++ या असेंबलर कोड की प्रीप्रोसेसिंग, कंपाइलिंग, और/या असेंबलिंग के लिए शुरू किया जाएगा, तब यह तर्क कंपाइलर को पास किया जाएगा. खाता लिंक करते समय, इसे पास नहीं किया जाएगा.

इस विकल्प का इस्तेमाल एक से ज़्यादा बार किया जा सकता है. उदाहरण के लिए:

  % bazel build --copt="-g0" --copt="-fpic" //foo

foo लाइब्रेरी को डीबग टेबल के बिना कंपाइल करेगा. इससे पोज़िशन से अलग कोड जनरेट होगा.

--host_copt=cc-option

इस विकल्प में एक ऐसा आर्ग्युमेंट होता है जिसे सोर्स फ़ाइलों के लिए कंपाइलर को पास किया जाता है. इन फ़ाइलों को exec कॉन्फ़िगरेशन में कंपाइल किया जाता है. यह --copt विकल्प के जैसा ही है, लेकिन यह सिर्फ़ exec कॉन्फ़िगरेशन पर लागू होता है.

--host_conlyopt=cc-option

इस विकल्प में एक ऐसा आर्ग्युमेंट होता है जिसे C सोर्स फ़ाइलों के लिए कंपाइलर को पास किया जाता है. इन फ़ाइलों को exec कॉन्फ़िगरेशन में कंपाइल किया जाता है. यह --conlyopt विकल्प के जैसा ही है, लेकिन यह सिर्फ़ exec कॉन्फ़िगरेशन पर लागू होता है.

--host_cxxopt=cc-option

इस विकल्प में एक ऐसा आर्ग्युमेंट होता है जिसे C++ सोर्स फ़ाइलों के लिए कंपाइलर को पास किया जाता है. इन फ़ाइलों को exec कॉन्फ़िगरेशन में कंपाइल किया जाता है. यह --cxxopt विकल्प के जैसा ही है, लेकिन यह सिर्फ़ exec कॉन्फ़िगरेशन पर लागू होता है.

--host_linkopt=linker-option

यह विकल्प एक ऐसा आर्ग्युमेंट लेता है जिसे उन सोर्स फ़ाइलों के लिए लिंकर को पास किया जाना है जिन्हें exec कॉन्फ़िगरेशन में कंपाइल किया जाता है. यह --linkopt विकल्प के जैसा ही है, लेकिन यह सिर्फ़ exec कॉन्फ़िगरेशन पर लागू होता है.

--conlyopt=cc-option

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

यह --copt से मिलता-जुलता है. हालांकि, यह सिर्फ़ C कंपाइलेशन पर लागू होता है. C++ कंपाइलेशन या लिंकिंग पर नहीं. इसलिए, --conlyopt का इस्तेमाल करके, C के लिए खास विकल्प (जैसे कि -Wno-pointer-sign) पास किए जा सकते हैं.

--cxxopt=cc-option

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

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

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

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

--linkopt=linker-option

इस विकल्प में एक ऐसा आर्ग्युमेंट होता है जिसे लिंक करते समय कंपाइलर को पास किया जाता है.

यह --copt से मिलता-जुलता है, लेकिन यह सिर्फ़ लिंक करने पर लागू होता है, न कि कंपाइल करने पर. इसलिए, --linkopt का इस्तेमाल करके, कंपाइलर के ऐसे विकल्प पास किए जा सकते हैं जो सिर्फ़ लिंक करने के समय काम करते हैं. जैसे, -lssp या -Wl,--wrap,abort. उदाहरण के लिए:

  % bazel build --copt="-fmudflap" --linkopt="-lmudflap" //foo/buggy_code

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

--strip (always|never|sometimes)

यह विकल्प तय करता है कि Bazel, सभी बाइनरी और शेयर की गई लाइब्रेरी से डीबग करने की जानकारी हटाएगा या नहीं. इसके लिए, वह -Wl,--strip-debug विकल्प के साथ लिंकर को चालू करता है. --strip=always का मतलब है कि डीबग करने की जानकारी हमेशा हटा दी जाती है. --strip=never का मतलब है कि डीबग करने की जानकारी को कभी नहीं हटाया जाता. --strip=sometimes की डिफ़ॉल्ट वैल्यू का मतलब है कि अगर --compilation_mode fastbuild है, तो स्ट्रिप करें.

  % bazel build --strip=always //foo:bar

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

Bazel का --strip विकल्प, ld के --strip-debug विकल्प से मेल खाता है: यह सिर्फ़ डीबग करने की जानकारी हटाता है. अगर आपको किसी वजह से, सिर्फ़ डीबग सिंबल नहीं, बल्कि सभी सिंबल हटाने हैं, तो आपको ld के --strip-all विकल्प का इस्तेमाल करना होगा. इसके लिए, Bazel को --linkopt=-Wl,--strip-all पास करें. यह भी ध्यान रखें कि Bazel के --strip फ़्लैग को सेट करने से, --linkopt=-Wl,--strip-all ओवरराइड हो जाएगा. इसलिए, आपको सिर्फ़ एक को सेट करना चाहिए.

अगर आपको सिर्फ़ एक बाइनरी बनानी है और सभी सिंबल हटाने हैं, तो --stripopt=--strip-all पास करके, टारगेट का //foo:bar.stripped वर्शन साफ़ तौर पर बनाया जा सकता है. --stripopt सेक्शन में बताए गए तरीके के मुताबिक, यह फ़ाइनल बाइनरी लिंक होने के बाद स्ट्रिप ऐक्शन लागू करता है. इसके बजाय, यह बिल्ड की सभी लिंक कार्रवाइयों में स्ट्रिपिंग को शामिल करता है.

--stripopt=strip-option

*.stripped बाइनरी जनरेट करते समय, strip कमांड को पास करने के लिए यह एक अतिरिक्त विकल्प है. डिफ़ॉल्ट रूप से, यह -S -p पर सेट होता है. इस विकल्प का इस्तेमाल एक से ज़्यादा बार किया जा सकता है.

--fdo_instrument=profile-output-dir

--fdo_instrument विकल्प, बिल्ट किए गए C/C++ बाइनरी को एक्ज़ीक्यूट करने पर, FDO (फ़ीडबैक डायरेक्टेड ऑप्टिमाइज़ेशन) प्रोफ़ाइल आउटपुट जनरेट करने की सुविधा देता है. GCC के लिए, दिए गए आर्ग्युमेंट का इस्तेमाल .gcda फ़ाइलों के हर ऑब्जेक्ट के लिए फ़ाइल डायरेक्ट्री ट्री के डायरेक्ट्री प्रीफ़िक्स के तौर पर किया जाता है. इन फ़ाइलों में, हर .o फ़ाइल के लिए प्रोफ़ाइल की जानकारी होती है.

प्रोफ़ाइल डेटा ट्री जनरेट होने के बाद, प्रोफ़ाइल ट्री को ज़िप किया जाना चाहिए. साथ ही, इसे --fdo_optimize=profile-zip Bazel विकल्प के तौर पर उपलब्ध कराया जाना चाहिए, ताकि FDO के हिसाब से ऑप्टिमाइज़ किए गए कंपाइलेशन को चालू किया जा सके.

एलएलवीएम कंपाइलर के लिए, यह आर्ग्युमेंट वह डायरेक्ट्री भी है जिसमें रॉ एलएलवीएम प्रोफ़ाइल डेटा फ़ाइलें डंप की जाती हैं. उदाहरण के लिए: --fdo_instrument=/path/to/rawprof/dir/.

--fdo_instrument और --fdo_optimize विकल्पों का इस्तेमाल एक साथ नहीं किया जा सकता.

--fdo_optimize=profile-zip

--fdo_optimize विकल्प, कंपाइल करते समय FDO (फ़ीडबैक के आधार पर ऑप्टिमाइज़ेशन) ऑप्टिमाइज़ेशन करने के लिए, हर ऑब्जेक्ट की फ़ाइल प्रोफ़ाइल की जानकारी का इस्तेमाल करने की सुविधा चालू करता है. GCC के लिए, दिया गया आर्ग्युमेंट एक ज़िप फ़ाइल होती है. इसमें .gcda फ़ाइलों का पहले से जनरेट किया गया फ़ाइल ट्री होता है. इन फ़ाइलों में, हर .o फ़ाइल के लिए प्रोफ़ाइल की जानकारी होती है.

इसके अलावा, दिए गए तर्क में .afdo एक्सटेंशन से पहचानी गई ऑटो प्रोफ़ाइल की ओर इशारा किया जा सकता है.

LLVM कंपाइलर के लिए, दिया गया आर्ग्युमेंट, llvm-profdata टूल से तैयार की गई इंडेक्स की गई LLVM प्रोफ़ाइल आउटपुट फ़ाइल की ओर ले जाना चाहिए. साथ ही, इसका एक्सटेंशन .profdata होना चाहिए.

--fdo_instrument और --fdo_optimize विकल्पों का इस्तेमाल एक साथ नहीं किया जा सकता.

--java_language_version=version

इस विकल्प से, Java सोर्स के वर्शन के बारे में पता चलता है. उदाहरण के लिए:

  % bazel build --java_language_version=8 java/com/example/common/foo:all

यह Java 8 स्पेसिफ़िकेशन के साथ काम करने वाले कंस्ट्रक्ट को कंपाइल करता है और सिर्फ़ उन्हें इस्तेमाल करने की अनुमति देता है. डिफ़ॉल्ट वैल्यू 11 है. --> संभावित वैल्यू ये हैं: 8, 9, 10, 11, 17, और 21. 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 ऐप्लिकेशन चलाता है.

डिफ़ॉल्ट वैल्यू local_jdk है. इसकी ये वैल्यू हो सकती हैं: local_jdk, local_jdk_version, remotejdk_11, remotejdk_17, और remotejdk_21. local_java_repository या remote_java_repository रिपॉज़िटरी के नियमों का इस्तेमाल करके, कस्टम JVM रजिस्टर करके वैल्यू बढ़ाई जा सकती हैं.

--tool_java_runtime_version=version

यह बिल्ड के दौरान ज़रूरी टूल को चलाने के लिए इस्तेमाल किए गए JVM का वर्शन है. डिफ़ॉल्ट वैल्यू remotejdk_11 है.

--jvmopt=jvm-option

इस विकल्प की मदद से, Java VM को विकल्प के आर्ग्युमेंट पास किए जा सकते हैं. इसका इस्तेमाल, एक बड़े आर्ग्युमेंट के साथ किया जा सकता है. इसके अलावा, अलग-अलग आर्ग्युमेंट के साथ कई बार भी इसका इस्तेमाल किया जा सकता है. उदाहरण के लिए:

  % 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

यह java_binary को फिर से बनाएगा. इसमें javac की डिफ़ॉल्ट डीबग जानकारी शामिल होगी. यह जानकारी, Bazel की डिफ़ॉल्ट जानकारी के बजाय इस्तेमाल की जाएगी.

यह विकल्प, javac के लिए Bazel के बिल्ट-इन डिफ़ॉल्ट विकल्पों के बाद और हर नियम के विकल्पों से पहले, javac को पास किया जाता है. javac को दिए गए किसी भी विकल्प का आखिरी स्पेसिफ़िकेशन मान्य होता है. javac के लिए डिफ़ॉल्ट विकल्प ये हैं:

  -source 8 -target 8 -encoding UTF-8

--strict_java_deps (default|strict|off|warn|error)

इस विकल्प से यह कंट्रोल किया जाता है कि javac, सीधे तौर पर इस्तेमाल की जाने वाली डिपेंडेंसी के मौजूद न होने की जांच करे या नहीं. Java टारगेट को, सीधे तौर पर इस्तेमाल किए जाने वाले सभी टारगेट को डिपेंडेंसी के तौर पर साफ़ तौर पर एलान करना होगा. यह फ़्लैग, javac को यह निर्देश देता है कि वह हर Java फ़ाइल के टाइप की जांच करने के लिए, इस्तेमाल किए गए जार का पता लगाए. साथ ही, अगर वे मौजूदा टारगेट की सीधे तौर पर इस्तेमाल की जाने वाली डिपेंडेंसी का आउटपुट नहीं हैं, तो चेतावनी दे या गड़बड़ी का मैसेज दिखाए.

• off का मतलब है कि जांच करने की सुविधा बंद है.
• warn का मतलब है कि javac, सीधे तौर पर मौजूद हर डिपेंडेंसी के लिए, [strict] टाइप की स्टैंडर्ड Java चेतावनियां जनरेट करेगा.
• default, strict, और error सभी का मतलब है कि javac, चेतावनियों के बजाय गड़बड़ियां जनरेट करेगा. इससे अगर कोई डायरेक्ट डिपेंडेंसी मौजूद नहीं है, तो मौजूदा टारगेट को बनाने में गड़बड़ी होगी. अगर फ़्लैग के बारे में नहीं बताया गया है, तो यह डिफ़ॉल्ट व्यवहार भी होता है.

सिमैंटिक बनाना

इन विकल्पों से, बिल्ड कमांड और/या आउटपुट फ़ाइल के कॉन्टेंट पर असर पड़ता है.

--compilation_mode (fastbuild|opt|dbg) (-c)

--compilation_mode विकल्प (इसे अक्सर -c के तौर पर छोटा किया जाता है, खास तौर पर -c opt) fastbuild, dbg या opt का तर्क लेता है. साथ ही, यह C/C++ कोड जनरेट करने के अलग-अलग विकल्पों पर असर डालता है. जैसे, ऑप्टिमाइज़ेशन का लेवल और डीबग टेबल की पूरी जानकारी. Bazel, हर कंपाइलेशन मोड के लिए अलग-अलग आउटपुट डायरेक्ट्री का इस्तेमाल करता है. इसलिए, आपको हर बार पूरे सिस्टम को फिर से बनाने की ज़रूरत नहीं होती.

• fastbuild का मतलब है कि जितनी जल्दी हो सके उतनी जल्दी बनाएं: कम से कम डीबग करने की जानकारी जनरेट करें (-gmlt -Wl,-S) और ऑप्टिमाइज़ न करें. यह डिफ़ॉल्ट विकल्प है. ध्यान दें: -DNDEBUG सेट नहीं होगा.
• dbg का मतलब है कि डीबग करने की सुविधा (-g) चालू करके बिल्ड किया गया है, ताकि gdb (या कोई दूसरा डीबगर) इस्तेमाल किया जा सके.
• opt का मतलब है कि ऑप्टिमाइज़ेशन की सुविधा चालू करके बनाया गया है. साथ ही, इसमें assert() कॉल बंद (-O2 -DNDEBUG) हैं. opt मोड में डीबग करने से जुड़ी जानकारी जनरेट नहीं होगी. ऐसा तब तक होगा, जब तक --copt -g पास नहीं किया जाता.

--cpu=cpu

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

--action_env=VAR=VALUE

यह सभी कार्रवाइयों के एक्ज़ीक्यूशन के दौरान उपलब्ध एनवायरमेंट वैरिएबल का सेट तय करता है. वैरिएबल को नाम से तय किया जा सकता है. ऐसे में, वैल्यू को इनवॉकेशन एनवायरमेंट से लिया जाएगा. इसके अलावा, वैरिएबल को name=value पेयर से भी तय किया जा सकता है. इससे वैल्यू को इनवॉकेशन एनवायरमेंट से अलग सेट किया जा सकेगा.

इस --action_env फ़्लैग को कई बार तय किया जा सकता है. अगर एक ही वैरिएबल को कई --action_env फ़्लैग में असाइन किया जाता है, तो सबसे हाल ही में असाइन की गई वैल्यू का इस्तेमाल किया जाता है.

--experimental_action_listener=label

experimental_action_listener विकल्प, Bazel को label के ज़रिए तय किए गए action_listener नियम से मिली जानकारी का इस्तेमाल करके, बिल्ड ग्राफ़ में extra_actions डालने का निर्देश देता है.

--[no]experimental_extra_action_top_level_only

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

--experimental_extra_action_filter=regex

experimental_extra_action_filter विकल्प, Bazel को उन टारगेट के सेट को फ़िल्टर करने का निर्देश देता है जिनके लिए extra_actions को शेड्यूल करना है.

इस फ़्लैग का इस्तेमाल, सिर्फ़ --experimental_action_listener फ़्लैग के साथ किया जा सकता है.

डिफ़ॉल्ट रूप से, अनुरोध किए गए टारगेट-टू-बिल्ड के ट्रांज़िटिव क्लोज़र में मौजूद सभी extra_actions को लागू करने के लिए शेड्यूल किया जाता है. --experimental_extra_action_filter, शेड्यूल करने की प्रोसेस को उन extra_actions तक सीमित करेगा जिनके मालिक का लेबल, तय किए गए रेगुलर एक्सप्रेशन से मेल खाता है.

यहां दिए गए उदाहरण में, extra_actions को शेड्यूल करने की सुविधा को सीमित किया गया है. यह सुविधा सिर्फ़ उन कार्रवाइयों पर लागू होगी जिनके मालिक के लेबल में '/bar/' शामिल है:

% bazel build --experimental_action_listener=//test:al //foo/... \
  --experimental_extra_action_filter=.*/bar/.*

--host_cpu=cpu

इस विकल्प से, सीपीयू आर्किटेक्चर का वह नाम पता चलता है जिसका इस्तेमाल होस्ट टूल बनाने के लिए किया जाना चाहिए.

--android_platforms=platform[,platform]*

ये ऐसे प्लैटफ़ॉर्म हैं जिन पर android_binary के deps नियमों को बनाया जाता है. खास तौर पर, C++ जैसी नेटिव डिपेंडेंसी के लिए. उदाहरण के लिए, अगर कोई cc_library, android_binary के deps नियम में दिखता है, तो उसे android_binary नियम के लिए --android_platforms के साथ बताए गए हर प्लैटफ़ॉर्म के लिए एक बार बनाया जाएगा. साथ ही, उसे फ़ाइनल आउटपुट में शामिल किया जाएगा.

इस फ़्लैग की कोई डिफ़ॉल्ट वैल्यू नहीं होती: कस्टम Android प्लैटफ़ॉर्म को तय और इस्तेमाल किया जाना चाहिए.

--android_platforms के साथ बताए गए हर प्लैटफ़ॉर्म के लिए, एक .so फ़ाइल बनाई जाती है और उसे APK में पैकेज किया जाता है. .so फ़ाइल के नाम में, android_binary नियम के नाम से पहले "lib" प्रीफ़िक्स होता है. उदाहरण के लिए, अगर android_binary का नाम "foo" है, तो फ़ाइल का नाम libfoo.so होगा.

--per_file_copt=[+-]regex[,[+-]regex]...@option[,option]...

अगर कोई C++ फ़ाइल मौजूद है, तो लेबल या एक्ज़ीक्यूशन पाथ के साथ शामिल करने के लिए दिए गए रेगुलर एक्सप्रेशन में से किसी एक से मैच करने वाली और बाहर रखने के लिए दिए गए रेगुलर एक्सप्रेशन में से किसी से भी मैच न करने वाली फ़ाइल को दिए गए विकल्पों के साथ बनाया जाएगा. लेबल मैच करने के लिए, लेबल के कैननिकल फ़ॉर्म का इस्तेमाल किया जाता है (जैसे, //package:label_name).

एक्ज़ीक्यूशन पाथ, आपकी वर्कस्पेस डायरेक्ट्री का रिलेटिव पाथ होता है. इसमें C++ फ़ाइल का बेस नेम (एक्सटेंशन के साथ) शामिल होता है. इसमें प्लैटफ़ॉर्म पर निर्भर करने वाले प्रीफ़िक्स भी शामिल होते हैं.

जनरेट की गई फ़ाइलों (जैसे, genrule के आउटपुट) से मैच करने के लिए, Bazel सिर्फ़ एक्ज़ीक्यूशन पाथ का इस्तेमाल कर सकता है. इस मामले में, रेगुलर एक्सप्रेशन की शुरुआत '//' से नहीं होनी चाहिए, क्योंकि यह किसी भी एक्ज़ीक्यूशन पाथ से मैच नहीं करता. पैकेज के नामों का इस्तेमाल इस तरह किया जा सकता है: --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/ में मौजूद file.cc को छोड़कर, सभी .cc फ़ाइलों के लिए, C++ कंपाइलर की कमांड लाइन में -O0 और -fprofile-arcs विकल्प जोड़ता है.

--dynamic_mode=mode

इससे यह तय होता है कि C++ बाइनरी को डाइनैमिक तरीके से लिंक किया जाएगा या नहीं. यह बिल्ड के नियमों पर linkstatic एट्रिब्यूट के साथ इंटरैक्ट करता है.

मोड:

• default: इससे Bazel को यह चुनने की अनुमति मिलती है कि डाइनैमिक तरीके से लिंक करना है या नहीं. ज़्यादा जानकारी के लिए, linkstatic देखें.
• fully: सभी टारगेट को डाइनैमिक तरीके से लिंक करता है. इससे लिंक करने में लगने वाला समय कम हो जाएगा और बाइनरी का साइज़ भी कम हो जाएगा.
• off: यह ज़्यादातर स्टैटिक मोड में सभी टारगेट को लिंक करता है. अगर linkopts में -static सेट किया जाता है, तो टारगेट पूरी तरह से स्टैटिक हो जाएंगे.

--fission (yes|no|[dbg][,opt][,fastbuild])

यह Fission को चालू करता है. यह C++ की डीबग जानकारी को .o फ़ाइलों के बजाय, .dwo फ़ाइलों में लिखता है. इससे लिंक के लिए इनपुट का साइज़ काफ़ी कम हो जाता है और लिंक करने में लगने वाला समय भी कम हो सकता है.

[dbg][,opt][,fastbuild] पर सेट होने पर (उदाहरण: --fission=dbg,fastbuild), Fission सिर्फ़ कंपाइल करने के लिए तय किए गए मोड के लिए चालू होता है. यह bazelrc सेटिंग के लिए काम का है. yes पर सेट करने पर, फ़िशन की सुविधा सभी के लिए चालू हो जाती है. no पर सेट होने पर, Fission की सुविधा सभी के लिए बंद हो जाती है. डिफ़ॉल्ट वैल्यू no है.

--force_ignore_dash_static

अगर यह फ़्लैग सेट है, तो cc_* नियमों के BUILD फ़ाइलों के linkopts में मौजूद किसी भी -static विकल्प को अनदेखा कर दिया जाता है. इसका इस्तेमाल सिर्फ़ C++ हार्डनिंग बिल्ड के लिए किया जाता है.

--[no]force_pic

इस विकल्प के चालू होने पर, सभी C++ कंपाइलेशन, पोज़िशन-इंडिपेंडेंट कोड ("-fPIC") जनरेट करते हैं. साथ ही, लिंक, नॉन-पीआईसी लाइब्रेरी के बजाय पीआईसी प्री-बिल्ट लाइब्रेरी को प्राथमिकता देते हैं. इसके अलावा, लिंक, पोज़िशन-इंडिपेंडेंट एक्ज़ीक्यूटेबल ("-pie") जनरेट करते हैं. यह सुविधा डिफ़ॉल्ट रूप से बंद होती है.

--android_resource_shrinking

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

--custom_malloc=malloc-library-target

अगर यह विकल्प चुना जाता है, तो हमेशा दिए गए malloc को लागू करें. साथ ही, सभी malloc="target" एट्रिब्यूट को बदलें. इनमें वे टारगेट भी शामिल हैं जो डिफ़ॉल्ट रूप से (कोई malloc तय न करके) malloc का इस्तेमाल करते हैं.

--crosstool_top=label

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

--host_crosstool_top=label

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

--apple_crosstool_top=label

objc*, ios*, और apple* नियमों के ट्रांज़िटिव deps में C/C++ नियमों को कंपाइल करने के लिए, इस क्रॉसटूल का इस्तेमाल किया जाता है. इन टारगेट के लिए, यह फ़्लैग --crosstool_top को बदल देता है.

--compiler=version

इस विकल्प से, C/C++ कंपाइलर के उस वर्शन (जैसे, gcc-4.1.0) के बारे में पता चलता है जिसका इस्तेमाल बिल्ड के दौरान बाइनरी को कंपाइल करने के लिए किया जाना है. अगर आपको कस्टम क्रॉसटूल का इस्तेमाल करके बनाना है, तो आपको इस फ़्लैग को तय करने के बजाय CROSSTOOL फ़ाइल का इस्तेमाल करना चाहिए.

--android_sdk=label

समर्थन नहीं होना या रुकना. इसे सीधे तौर पर नहीं बताया जाना चाहिए.

इस विकल्प से, Android SDK/प्लैटफ़ॉर्म टूलचेन और Android रनटाइम लाइब्रेरी के बारे में पता चलता है. इनका इस्तेमाल, Android से जुड़े किसी भी नियम को बनाने के लिए किया जाएगा.

अगर WORKSPACE फ़ाइल में कोई android_sdk_repository नियम तय किया गया है, तो Android SDK अपने-आप चुना जाएगा.

--java_toolchain=label

कोई कार्रवाई नहीं. इसे सिर्फ़ पुराने सिस्टम के साथ काम करने की सुविधा के लिए रखा गया है.

--host_java_toolchain=label

कोई कार्रवाई नहीं. इसे सिर्फ़ पुराने सिस्टम के साथ काम करने की सुविधा के लिए रखा गया है.

--javabase=(label)

कोई कार्रवाई नहीं. इसे सिर्फ़ पुराने सिस्टम के साथ काम करने की सुविधा के लिए रखा गया है.

--host_javabase=label

कोई कार्रवाई नहीं. इसे सिर्फ़ पुराने सिस्टम के साथ काम करने की सुविधा के लिए रखा गया है.

रणनीति लागू करना

इन विकल्पों से, Bazel के बिल्ड को एक्ज़ीक्यूट करने के तरीके पर असर पड़ता है. हालांकि, इनसे बिल्ड से जनरेट होने वाली आउटपुट फ़ाइलों पर कोई खास असर नहीं पड़ना चाहिए. आम तौर पर, इनका मुख्य असर बिल्ड की स्पीड पर पड़ता है.

--spawn_strategy=strategy

इस विकल्प से यह कंट्रोल किया जाता है कि कमांड कहां और कैसे एक्ज़ीक्यूट की जाएं.

• standalone की वजह से, कमांड को लोकल सबप्रोसेस के तौर पर एक्ज़ीक्यूट किया जाता है. यह वैल्यू अब काम नहीं करती. इसके बजाय, कृपया local का इस्तेमाल करें.
• sandboxed की वजह से, निर्देश लोकल मशीन पर सैंडबॉक्स में लागू होते हैं. इसके लिए, यह ज़रूरी है कि सभी इनपुट फ़ाइलें, डेटा डिपेंडेंसी, और टूल को srcs, data, और tools एट्रिब्यूट में डायरेक्ट डिपेंडेंसी के तौर पर लिस्ट किया गया हो. Bazel, सैंडबॉक्स किए गए एक्ज़ीक्यूशन की सुविधा देने वाले सिस्टम पर, डिफ़ॉल्ट रूप से लोकल सैंडबॉक्सिंग की सुविधा चालू करता है.
• local की वजह से, कमांड को लोकल सबप्रोसेस के तौर पर एक्ज़ीक्यूट किया जाता है.
• worker उपलब्ध होने पर, लगातार काम करने वाले वर्कर का इस्तेमाल करके कमांड को पूरा करता है.
• docker की वजह से, निर्देश लोकल मशीन पर Docker सैंडबॉक्स में लागू होते हैं. इसके लिए, Docker इंस्टॉल होना ज़रूरी है.
• remote की वजह से, निर्देश किसी दूसरी जगह से लागू किए जाते हैं. यह सुविधा सिर्फ़ तब उपलब्ध होती है, जब रिमोट एक्ज़ीक्यूटर को अलग से कॉन्फ़िगर किया गया हो.

--strategy mnemonic=strategy

इस विकल्प से यह कंट्रोल किया जाता है कि कमांड कहां और कैसे लागू की जाएं. इससे, हर निमोनिक के आधार पर --spawn_strategy और निमोनिक Genrule के साथ --genrule_strategy को बदला जा सकता है. काम करने वाली रणनीतियों और उनके असर के बारे में जानने के लिए, --spawn_strategy देखें.

--strategy_regexp=<filter,filter,...>=<strategy>

इस विकल्प से यह तय किया जाता है कि regex_filter से मेल खाने वाले ब्यौरे वाली कमांड को पूरा करने के लिए, किस रणनीति का इस्तेमाल किया जाना चाहिए. regex_filter मैच करने के बारे में ज़्यादा जानने के लिए, --per_file_copt देखें. सपोर्ट की गई रणनीतियों और उनके असर के बारे में जानने के लिए, --spawn_strategy देखें.

ब्यौरे से मेल खाने वाले आखिरी regex_filter का इस्तेमाल किया जाता है. यह विकल्प, रणनीति तय करने के लिए इस्तेमाल किए जाने वाले अन्य फ़्लैग को बदल देता है.

• उदाहरण: --strategy_regexp=//foo.*\\.cc,-//foo/bar=local का मतलब है कि अगर उनके ब्यौरे //foo.*.cc से मेल खाते हैं, लेकिन //foo/bar से नहीं, तो local रणनीति का इस्तेमाल करके कार्रवाइयां करें.
• उदाहरण: --strategy_regexp='Compiling.*/bar=local' --strategy_regexp=Compiling=sandboxed sandboxed स्ट्रैटजी का इस्तेमाल करके, 'Compiling //foo/bar/baz' को चलाता है. हालांकि, क्रम बदलने पर यह local का इस्तेमाल करके इसे चलाता है.
• उदाहरण: --strategy_regexp='Compiling.*/bar=local,sandboxed', local स्ट्रैटजी का इस्तेमाल करके 'Compiling //foo/bar/baz' को चलाता है. अगर यह काम नहीं करता है, तो sandboxed पर वापस आ जाता है.

--genrule_strategy=strategy

यह --strategy=Genrule=strategy के लिए, इस्तेमाल में नहीं लाया जाने वाला शॉर्ट-हैंड है.

--jobs=n (-j)

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

--progress_report_interval=n

Bazel, समय-समय पर उन कामों की प्रोग्रेस रिपोर्ट प्रिंट करता है जो अब तक पूरे नहीं हुए हैं. जैसे, लंबे समय तक चलने वाले टेस्ट. इस विकल्प से रिपोर्टिंग की फ़्रीक्वेंसी सेट की जाती है. प्रोग्रेस हर n सेकंड में प्रिंट की जाएगी.

डिफ़ॉल्ट वैल्यू 0 होती है. इसका मतलब है कि यह एक इंक्रीमेंटल एल्गोरिदम है: पहली रिपोर्ट 10 सेकंड के बाद, दूसरी 30 सेकंड के बाद प्रिंट होगी. इसके बाद, हर एक मिनट में प्रोग्रेस की रिपोर्ट दी जाएगी.

जब Bazel, कर्सर कंट्रोल का इस्तेमाल कर रहा होता है, तब हर सेकंड में प्रोग्रेस की जानकारी दी जाती है. इसकी जानकारी --curses में दी गई है.

--local_resources resources or resource expression

इन विकल्पों से, स्थानीय संसाधनों (एमबी में रैम और सीपीयू के लॉजिकल कोर की संख्या) की जानकारी मिलती है. Bazel, स्थानीय तौर पर बिल्ड और टेस्ट की गतिविधियों को शेड्यूल करते समय इस जानकारी का इस्तेमाल कर सकता है. ये फ़्लोट या कीवर्ड (HOST_RAM या HOST_CPUS) लेते हैं. इसके बाद, [-|*फ़्लोट] (उदाहरण के लिए, --local_resources=cpu=2, --local_resources=memory=HOST_RAM*.5, --local_resources=cpu=HOST_CPUS-1) का इस्तेमाल किया जा सकता है. फ़्लैग एक-दूसरे से अलग होते हैं. इनमें से एक या दोनों को सेट किया जा सकता है. डिफ़ॉल्ट रूप से, Bazel सीधे लोकल सिस्टम के कॉन्फ़िगरेशन से, रैम और सीपीयू कोर की संख्या का अनुमान लगाता है.

--[no]build_runfile_links

यह विकल्प डिफ़ॉल्ट रूप से चालू होता है. इससे यह तय होता है कि टेस्ट और बाइनरी के लिए, रनफ़ाइल के सिंबल लिंक को आउटपुट डायरेक्ट्री में बनाया जाना चाहिए या नहीं. --nobuild_runfile_links का इस्तेमाल करके, यह पुष्टि की जा सकती है कि सभी टारगेट, रनफ़ाइल ट्री बनाने के लिए ओवरहेड का इस्तेमाल किए बिना कंपाइल होते हैं या नहीं.

जब टेस्ट (या ऐप्लिकेशन) लागू किए जाते हैं, तो उनके रन-टाइम डेटा की डिपेंडेंसी को एक जगह इकट्ठा किया जाता है. Bazel के आउटपुट ट्री में, यह "runfiles" ट्री आम तौर पर, संबंधित बाइनरी या टेस्ट के साथ-साथ रूट किया जाता है. टेस्ट के दौरान, रनफ़ाइलों को $TEST_SRCDIR/canonical_repo_name/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 टारगेट को कंपाइल करने के तरीके में बदलाव होता है. Bazel, डिपेंडेंट java_library टारगेट को कंपाइल करने के लिए, java_library के आउटपुट का इस्तेमाल करने के बजाय, इंटरफ़ेस जार बनाएगा. इनमें सिर्फ़ नॉन-प्राइवेट सदस्यों (पब्लिक, प्रोटेक्टेड, और डिफ़ॉल्ट (पैकेज) ऐक्सेस के तरीके और फ़ील्ड) के सिग्नेचर शामिल होंगे. साथ ही, Bazel डिपेंडेंट टारगेट को कंपाइल करने के लिए, इंटरफ़ेस जार का इस्तेमाल करेगा. इससे, सिर्फ़ किसी क्लास के तरीके या निजी सदस्यों में बदलाव होने पर, फिर से कंपाइल करने से बचा जा सकता है.

--[no]interface_shared_objects

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

आउटपुट चुनने की सुविधा

इन विकल्पों से यह तय किया जाता है कि क्या बनाना है या क्या टेस्ट करना है.

--[no]build

इस विकल्प से, बिल्ड के एक्ज़ीक्यूशन फ़ेज़ को पूरा किया जाता है. यह डिफ़ॉल्ट रूप से चालू होता है. इसे बंद करने पर, एक्ज़ीक्यूशन फ़ेज़ को छोड़ दिया जाता है. इसके बाद, सिर्फ़ पहले दो फ़ेज़, लोडिंग और विश्लेषण होते हैं.

यह विकल्प, BUILD फ़ाइलों की पुष्टि करने और इनपुट में गड़बड़ियों का पता लगाने के लिए मददगार हो सकता है. इसके लिए, कुछ भी बनाने की ज़रूरत नहीं होती.

--[no]build_tests_only

अगर ऐसा किया जाता है, तो Bazel सिर्फ़ उन *_test और test_suite नियमों को बनाएगा जिन्हें फ़िल्टर नहीं किया गया है. ऐसा इसलिए, क्योंकि वे साइज़, टाइमआउट, टैग या भाषा की वजह से फ़िल्टर नहीं किए गए थे. अगर ऐसा किया जाता है, तो Bazel, कमांड लाइन पर तय किए गए अन्य टारगेट को अनदेखा कर देगा. डिफ़ॉल्ट रूप से, यह विकल्प बंद होता है. Bazel, अनुरोध किए गए सभी टारगेट बनाएगा. इनमें *_test और test_suite नियम भी शामिल हैं. इन नियमों को टेस्टिंग से फ़िल्टर किया जाता है. यह इसलिए काम का है, क्योंकि हो सकता है कि bazel test --build_tests_only foo/... चलाने पर, foo ट्री में मौजूद सभी बिल्ड ब्रेक का पता न चले.

--[no]check_up_to_date

इस विकल्प की वजह से, Bazel कोई बिल्ड नहीं बनाता है. हालांकि, यह सिर्फ़ यह जांच करता है कि सभी तय किए गए टारगेट अप-टू-डेट हैं या नहीं. अगर ऐसा है, तो बिल्ड सामान्य तरीके से पूरा हो जाता है. हालांकि, अगर कोई फ़ाइल अप-टू-डेट नहीं है, तो उसे बनाने के बजाय, गड़बड़ी की सूचना दी जाती है और बिल्ड पूरा नहीं हो पाता. इस विकल्प का इस्तेमाल यह पता लगाने के लिए किया जा सकता है कि बिल्ड, सोर्स में बदलाव करने के मुकाबले हाल ही में किया गया है या नहीं. उदाहरण के लिए, सबमिट करने से पहले की जाने वाली जांचों के लिए, बिल्ड बनाने की लागत के बिना ऐसा किया जा सकता है.

--check_tests_up_to_date भी देखें.

--[no]compile_one_dependency

आर्ग्युमेंट फ़ाइलों की एक ही डिपेंडेंसी कंपाइल करता है. यह आईडीई में सोर्स फ़ाइलों के सिंटैक्स की जांच करने के लिए काम आता है. उदाहरण के लिए, सोर्स फ़ाइल पर निर्भर किसी एक टारगेट को फिर से बनाकर, बदलाव/बिल्ड/टेस्ट साइकल में गड़बड़ियों का पता लगाया जा सकता है. इस आर्ग्युमेंट से, फ़्लैग नहीं किए गए सभी आर्ग्युमेंट के मतलब पर असर पड़ता है: हर आर्ग्युमेंट, फ़ाइल टारगेट का लेबल या मौजूदा वर्किंग डायरेक्ट्री के हिसाब से फ़ाइल का सामान्य नाम होना चाहिए. साथ ही, हर सोर्स फ़ाइल के नाम पर निर्भर करने वाला एक नियम बनाया जाता है. C++ और Java सोर्स के लिए, एक ही भाषा के स्पेस में मौजूद नियमों को प्राथमिकता दी जाती है. अगर एक ही प्राथमिकता वाले कई नियम हैं, तो BUILD फ़ाइल में सबसे पहले दिखने वाले नियम को चुना जाता है. अगर किसी टारगेट पैटर्न का नाम साफ़ तौर पर दिया गया है और वह किसी सोर्स फ़ाइल का रेफ़रंस नहीं देता है, तो गड़बड़ी होती है.

--save_temps

--save_temps विकल्प की वजह से, कंपाइलर से मिलने वाले कुछ समय के आउटपुट सेव हो जाते हैं. इनमें .s फ़ाइलें (असेंबलर कोड), .i (प्रीप्रोसेस्ड C), और .ii (प्रीप्रोसेस्ड C++) फ़ाइलें शामिल हैं. ये आउटपुट, डीबग करने के लिए अक्सर काम आते हैं. टेंप सिर्फ़ उन टारगेट के लिए जनरेट किए जाएंगे जिन्हें कमांड लाइन पर तय किया गया है.

फ़िलहाल, --save_temps फ़्लैग सिर्फ़ cc_* नियमों के लिए काम करता है.

यह पक्का करने के लिए कि Bazel, अतिरिक्त आउटपुट फ़ाइलों की जगह प्रिंट करे, जांच करें कि आपकी --show_result n सेटिंग ज़रूरत के हिसाब से है या नहीं.

--build_tag_filters=tag[,tag]*

अगर ऐसा किया जाता है, तो Bazel सिर्फ़ उन टारगेट को बनाएगा जिनमें कम से कम एक ज़रूरी टैग हो (अगर उनमें से कोई भी टैग तय किया गया है) और जिनमें कोई भी शामिल न किया गया टैग न हो. टैग फ़िल्टर बनाने के लिए, टैग कीवर्ड की कॉमा लगाकर अलग की गई सूची तय की जाती है. इसमें शामिल न किए गए टैग को दिखाने के लिए, '-' चिह्न का इस्तेमाल किया जाता है. ज़रूरी टैग में '+' चिह्न भी शामिल हो सकता है.

टेस्ट चलाते समय, Bazel, टेस्ट टारगेट के लिए --build_tag_filters को अनदेखा करता है. ये टारगेट, इस फ़िल्टर से मेल न खाने पर भी बनाए और चलाए जाते हैं. इन्हें बनाने से बचने के लिए, --test_tag_filters का इस्तेमाल करके या उन्हें साफ़ तौर पर बाहर रखकर, टेस्ट टारगेट को फ़िल्टर करें.

--test_size_filters=size[,size]*

अगर यह विकल्प दिया गया है, तो Bazel सिर्फ़ दिए गए साइज़ वाले टेस्ट टारगेट की जांच करेगा. अगर --build_tests_only विकल्प भी दिया गया है, तो Bazel सिर्फ़ दिए गए साइज़ वाले टेस्ट टारगेट बनाएगा. टेस्ट के साइज़ का फ़िल्टर, टेस्ट के साइज़ की मान्य वैल्यू की कॉमा लगाकर अलग की गई सूची के तौर पर तय किया जाता है. जैसे, छोटा, मध्यम, बड़ा या बहुत बड़ा. इसके पहले, '-' का निशान लगाया जा सकता है. इसका इस्तेमाल, टेस्ट के उन साइज़ को दिखाने के लिए किया जाता है जिन्हें शामिल नहीं किया गया है. उदाहरण के लिए,

  % 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 विकल्प भी दिया गया है, तो Bazel उन टेस्ट टारगेट को बनाएगा. टेस्ट टाइम आउट फ़िल्टर को, टेस्ट टाइम आउट की मान्य वैल्यू (कम, सामान्य, ज़्यादा या हमेशा के लिए) की कॉमा लगाकर अलग की गई सूची के तौर पर तय किया जाता है. इसके पहले, '-' चिह्न का इस्तेमाल किया जा सकता है. इसका इस्तेमाल, टेस्ट टाइम आउट को बाहर रखने के लिए किया जाता है. सिंटैक्स के उदाहरण के लिए, --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=string[,string]*

यह सेटिंग, कॉमा लगाकर अलग की गई स्ट्रिंग की सूची तय करती है. यह सूची, टेस्ट रूल क्लास के नामों के बारे में बताती है. नियम क्लास foo_test को रेफ़र करने के लिए, "foo" स्ट्रिंग का इस्तेमाल करें. Bazel, सिर्फ़ रेफ़र किए गए नियम क्लास के टारगेट की जांच करेगा. अगर --build_tests_only भी तय किया गया है, तो Bazel टारगेट बनाएगा. अगर आपको उन टारगेट को शामिल नहीं करना है, तो "-foo" स्ट्रिंग का इस्तेमाल करें. उदाहरण के लिए,

  % bazel test --test_lang_filters=foo,bar //baz/...

सिर्फ़ उन टारगेट की जांच करेगा जो //baz/... में foo_test या bar_test के उदाहरण हैं. वहीं,

  % bazel test --test_lang_filters=-foo,-bar //baz/...

foo_test और bar_test इंस्टेंस को छोड़कर, //baz/... में मौजूद सभी टारगेट की जांच करेगा.

--test_filter=filter-expression

यह एक ऐसा फ़िल्टर तय करता है जिसका इस्तेमाल टेस्ट रनर, टेस्ट के सबसेट को चलाने के लिए कर सकता है. इनवॉकेशन में बताए गए सभी टारगेट बनाए जाते हैं. हालांकि, एक्सप्रेशन के आधार पर उनमें से कुछ ही टारगेट लागू किए जा सकते हैं. कुछ मामलों में, सिर्फ़ कुछ टेस्ट के तरीके लागू किए जाते हैं.

filter-expression की खास व्याख्या, टेस्ट चलाने के लिए ज़िम्मेदार टेस्ट फ़्रेमवर्क पर निर्भर करती है. यह ग्लोब, सबस्ट्रिंग या रेगएक्सप हो सकता है. --test_filter, अलग-अलग --test_arg फ़िल्टर आर्ग्युमेंट पास करने की तुलना में ज़्यादा सुविधाजनक है. हालांकि, सभी फ़्रेमवर्क इसे सपोर्ट नहीं करते.

कितने शब्दों में जानकारी दी जाए

इन विकल्पों से, Bazel के आउटपुट की वर्बोसिटी को कंट्रोल किया जाता है. यह आउटपुट, टर्मिनल या अतिरिक्त लॉग फ़ाइलों में दिखता है.

--explain=logfile

इस विकल्प के लिए, फ़ाइल के नाम का आर्ग्युमेंट ज़रूरी होता है. इससे bazel build के एक्ज़ीक्यूशन फ़ेज़ में, डिपेंडेंसी की जांच करने वाला टूल हर बिल्ड स्टेप के लिए यह बताता है कि उसे क्यों एक्ज़ीक्यूट किया जा रहा है या वह अप-टू-डेट है. इसकी वजह लॉग फ़ाइल में लिखी जाती है.

अगर आपको लगता है कि आपकी अनुमति के बिना ही कोई बदलाव किया गया है, तो इस विकल्प की मदद से इसकी वजह का पता लगाया जा सकता है. इसे अपने .bazelrc में जोड़ें, ताकि इसके बाद किए जाने वाले सभी बदलावों को लॉग किया जा सके. इसके बाद, जब आपको लगे कि आपकी अनुमति के बिना कोई बदलाव किया गया है, तो लॉग की जांच करें. इस विकल्प से परफ़ॉर्मेंस पर थोड़ा असर पड़ सकता है. इसलिए, जब इसकी ज़रूरत न हो, तो इसे हटाया जा सकता है.

--verbose_explanations

इस विकल्प से, --explain विकल्प चालू होने पर जनरेट किए गए जवाबों में ज़्यादा जानकारी मिलती है.

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

इस विकल्प का इस्तेमाल करने से, जनरेट की गई जानकारी वाली फ़ाइल की लंबाई काफ़ी बढ़ सकती है. साथ ही, --explain का इस्तेमाल करने पर परफ़ॉर्मेंस पर लगने वाला जुर्माना भी बढ़ सकता है.

अगर --explain चालू नहीं है, तो --verbose_explanations का कोई असर नहीं होगा.

--profile=file

यह विकल्प, फ़ाइल के नाम का आर्ग्युमेंट लेता है. इससे Bazel, प्रोफ़ाइलिंग डेटा को किसी फ़ाइल में लिखता है. इसके बाद, bazel analyze-profile कमांड का इस्तेमाल करके डेटा का विश्लेषण किया जा सकता है या उसे पार्स किया जा सकता है. Build 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)

जहां भी मुमकिन हो, वहां कमांड को Bourne shell के साथ काम करने वाले सिंटैक्स में प्रिंट किया जाता है, ताकि उन्हें आसानी से कॉपी करके शेल कमांड प्रॉम्प्ट में चिपकाया जा सके. (आस-पास के कोष्ठक, आपके शेल को cd और exec कॉल से बचाने के लिए दिए गए हैं; इन्हें कॉपी करना न भूलें!) हालांकि, कुछ निर्देश Bazel में अंदरूनी तौर पर लागू किए जाते हैं. जैसे, सिंबल लिंक ट्री बनाना. इनके लिए, कोई कमांड लाइन नहीं दिखती.

--subcommands=pretty_print को प्रिंट करने के लिए पास किया जा सकता है. इससे कमांड के आर्ग्युमेंट को एक लाइन के बजाय सूची के तौर पर प्रिंट किया जा सकता है. इससे लंबी कमांड लाइन को ज़्यादा आसानी से पढ़ा जा सकता है.

नीचे दिया गया --verbose_failures विकल्प भी देखें.

टूल के हिसाब से फ़ॉर्मैट में किसी फ़ाइल में सब-कमांड लॉग करने के लिए, देखें --execution_log_json_file और --execution_log_binary_file.

--verbose_failures

इस विकल्प की वजह से, Bazel के एक्ज़ीक्यूशन फ़ेज़ में उन निर्देशों के लिए पूरी कमांड लाइन प्रिंट होती है जो पूरे नहीं हो सके. यह विकल्प, बिल्ड से जुड़ी गड़बड़ियों को ठीक करने के लिए बहुत काम का हो सकता है.

काम न करने वाली कमांड को बॉर्न शेल के साथ काम करने वाले सिंटैक्स में प्रिंट किया जाता है. इसे शेल प्रॉम्प्ट में कॉपी करके चिपकाया जा सकता है.

Workspace खाते की स्थिति

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

• "volatile" कुंजियों की वैल्यू अक्सर बदल सकती हैं. Bazel को उम्मीद होती है कि ये हमेशा बदलते रहेंगे. जैसे, टाइमस्टैंप बदलते हैं. साथ ही, यह bazel-out/volatile-status.txt फ़ाइल को अपडेट करता रहता है. हालांकि, स्टैंप की गई कार्रवाइयों को बार-बार चलाने से बचने के लिए, Bazel यह मान लेता है कि अस्थिर फ़ाइल कभी नहीं बदलती. दूसरे शब्दों में कहें, तो अगर सिर्फ़ ऐसी फ़ाइल के कॉन्टेंट में बदलाव हुआ है जिसका स्टेटस बदलता रहता है, तो Bazel उन कार्रवाइयों को अमान्य नहीं करेगा जो इस पर निर्भर करती हैं. अगर कार्रवाइयों के अन्य इनपुट बदल गए हैं, तो Bazel उस कार्रवाई को फिर से चलाता है. साथ ही, कार्रवाई में अपडेट किया गया अस्थिर स्टेटस दिखेगा. हालांकि, सिर्फ़ अस्थिर स्टेटस बदलने से कार्रवाई अमान्य नहीं होगी.

  Bazel हमेशा इन अस्थिर कुंजियों को आउटपुट करता है:

  • BUILD_TIMESTAMP: Unix Epoch के बाद से, बिल्ड का समय सेकंड में (System.currentTimeMillis() की वैल्यू को एक हज़ार से भाग दिया जाता है)
  • FORMATTED_DATE: बिल्ड का समय. इसे यूटीसी में yyyy MMM d HH mm ss EEE के तौर पर फ़ॉर्मैट किया गया है. उदाहरण के लिए, 2 जून, 2023 को सुबह 1:44:29 बजे.

Linux/macOS पर, --workspace_status_command=/bin/true को पास करके, वर्कस्पेस का स्टेटस पाने की सुविधा बंद की जा सकती है. ऐसा इसलिए, क्योंकि --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 एट्रिब्यूट का इस्तेमाल करके, हर नियम के हिसाब से स्टैंपिंग की सुविधा को चालू या बंद किया जा सकता है. ज़्यादा जानकारी के लिए, कृपया Build Encyclopedia देखें. जब कोई नियम stamp = -1 (*_binary नियमों के लिए डिफ़ॉल्ट) सेट करता है, तब यह विकल्प तय करता है कि स्टैंपिंग चालू है या नहीं.

Bazel, एक्ज़ेक कॉन्फ़िगरेशन के लिए बनाए गए बाइनरी को कभी स्टैंप नहीं करता. भले ही, यह विकल्प या stamp एट्रिब्यूट कुछ भी हो. stamp = 0 (*_test नियमों के लिए डिफ़ॉल्ट) सेट करने वाले नियमों के लिए, स्टैंपिंग बंद कर दी जाती है. भले ही, --[no]stamp कुछ भी हो. अगर उनकी डिपेंडेंसी में कोई बदलाव नहीं हुआ है, तो --stamp तय करने से टारगेट को फिर से बनाने के लिए मजबूर नहीं किया जाता.

--nostamp को सेट करना, आम तौर पर बिल्ड परफ़ॉर्मेंस के लिए अच्छा होता है. ऐसा इसलिए, क्योंकि इससे इनपुट में बदलाव कम होता है और बिल्ड कैश मेमोरी का इस्तेमाल ज़्यादा होता है.

प्लैटफ़ॉर्म

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

कृपया प्लैटफ़ॉर्म और टूलचेन के बारे में बुनियादी जानकारी देखें.

--platforms=labels

प्लैटफ़ॉर्म के नियमों के लेबल, मौजूदा कमांड के लिए टारगेट प्लैटफ़ॉर्म के बारे में बताते हैं.

--host_platform=label

होस्ट सिस्टम की जानकारी देने वाले प्लैटफ़ॉर्म के नियम का लेबल.

--extra_execution_platforms=labels

ये ऐसे प्लैटफ़ॉर्म होते हैं जिन पर कार्रवाइयां की जा सकती हैं. प्लैटफ़ॉर्म को सटीक टारगेट या टारगेट पैटर्न के तौर पर तय किया जा सकता है. इन प्लैटफ़ॉर्म को, register_execution_platforms() फ़ंक्शन के ज़रिए MODULE.bazel फ़ाइलों में तय किए गए प्लैटफ़ॉर्म से पहले माना जाएगा. इस विकल्प में, प्राथमिकता के क्रम में प्लैटफ़ॉर्म की कॉमा लगाकर अलग की गई सूची स्वीकार की जाती है. अगर फ़्लैग को कई बार पास किया जाता है, तो सबसे हाल का फ़्लैग लागू होता है.

--extra_toolchains=labels

टूलचेन रिज़ॉल्यूशन के दौरान, टूलचेन के नियमों को ध्यान में रखा जाता है. टूलचेन को सटीक टारगेट या टारगेट पैटर्न के तौर पर तय किया जा सकता है. इन टूलचेन को, MODULE.bazel फ़ाइलों में register_toolchains() फ़ंक्शन के ज़रिए डिक्लेयर की गई टूलचेन से पहले माना जाएगा.

--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 की डिफ़ॉल्ट विज़िबिलिटी में हुए बदलावों को टेस्ट करने के लिए बनाया गया है. इसका इस्तेमाल आम तौर पर नहीं किया जाता है, लेकिन इसे पूरी जानकारी देने के लिए लिखा गया है.

--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: कई कॉन्फ़िगरेशन के लिए बिल्ड मैनेज करने के लिए, हर बिल्ड को अलग-अलग आइडेंटिफ़ायर से पहचानना आसान हो सकता है. जैसे, "64bit" बनाम "32bit". इस विकल्प से, bazel-bin (वगैरह) सिमलंक के बीच अंतर किया जाता है.

टेस्ट चल रहे हैं

Bazel की मदद से टेस्ट बनाने और उन्हें चलाने के लिए, bazel test टाइप करें. इसके बाद, टेस्ट टारगेट के नाम लिखें.

डिफ़ॉल्ट रूप से, यह कमांड एक साथ बिल्ड और टेस्ट करती है. यह कमांड लाइन पर बताए गए सभी टारगेट (इसमें कमांड लाइन पर बताए गए नॉन-टेस्ट टारगेट भी शामिल हैं) को बिल्ड करती है. साथ ही, *_test और test_suite टारगेट को तब टेस्ट करती है, जब उनकी ज़रूरी शर्तें पूरी हो जाती हैं. इसका मतलब है कि टेस्ट का एक्ज़ीक्यूशन, बिल्ड करने के साथ-साथ होता है. ऐसा करने से, आम तौर पर स्पीड में काफ़ी सुधार होता है.

bazel test के लिए विकल्प

--cache_test_results=(yes|no|auto) (-t)

अगर यह विकल्प 'auto' (डिफ़ॉल्ट) पर सेट है, तो Bazel सिर्फ़ तब टेस्ट को फिर से चलाएगा, जब इनमें से कोई शर्त लागू होती है:

• Bazel, टेस्ट या उसकी डिपेंडेंसी में हुए बदलावों का पता लगाता है
• टेस्ट को external के तौर पर मार्क किया गया हो
• --runs_per_test का इस्तेमाल करके, कई टेस्ट रन का अनुरोध किया गया था
• टेस्ट फ़ेल हो गया.

अगर 'no' चुना जाता है, तो सभी टेस्ट बिना किसी शर्त के लागू किए जाएंगे.

अगर 'हां', तो कैश मेमोरी में सेव करने का तरीका, ऑटो मोड जैसा ही होगा. हालांकि, यह --runs_per_test के साथ टेस्ट फ़ेल होने और टेस्ट रन को कैश मेमोरी में सेव कर सकता है.

जिन लोगों ने अपनी .bazelrc फ़ाइल में इस विकल्प को डिफ़ॉल्ट रूप से चालू किया है उन्हें किसी खास रन के लिए डिफ़ॉल्ट सेटिंग को बदलने में, -t (चालू) या -t- (बंद) के तौर पर दिखने वाले छोटे नाम काम के लग सकते हैं.

--check_tests_up_to_date

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

इस विकल्प का मतलब --check_up_to_date भी है.

यह विकल्प, सबमिट करने से पहले की जाने वाली जांचों के लिए मददगार हो सकता है.

--test_verbose_timeout_warnings

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

उदाहरण के लिए, आम तौर पर एक या दो मिनट में पूरा होने वाला टेस्ट, ETERNAL या LONG टाइमआउट वाला नहीं होना चाहिए, क्योंकि ये बहुत ज़्यादा समय वाले टाइमआउट हैं.

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

--[no]test_keep_going

डिफ़ॉल्ट रूप से, सभी टेस्ट पूरे होने तक चलाए जाते हैं. हालांकि, अगर इस फ़्लैग को बंद कर दिया जाता है, तो टेस्ट पास न होने पर बिल्ड बंद हो जाता है. इसके बाद, बिल्ड के चरण और टेस्ट शुरू नहीं किए जाते. साथ ही, चालू टेस्ट रद्द कर दिए जाते हैं. --notest_keep_going और --keep_going, दोनों को एक साथ न डालें.

--flaky_test_attempts=attempts

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

डिफ़ॉल्ट रूप से (जब इस विकल्प को नहीं चुना जाता या इसे डिफ़ॉल्ट पर सेट किया जाता है), सामान्य जांचों के लिए सिर्फ़ एक बार कोशिश करने की अनुमति होती है. साथ ही, flaky एट्रिब्यूट सेट किए गए टेस्ट नियमों के लिए, तीन बार कोशिश करने की अनुमति होती है. टेस्ट के लिए कोशिश करने की ज़्यादा से ज़्यादा सीमा को बदलने के लिए, पूर्णांक वैल्यू तय की जा सकती है. Bazel, सिस्टम के गलत इस्तेमाल को रोकने के लिए, ज़्यादा से ज़्यादा 10 बार टेस्ट करने की अनुमति देता है.

--runs_per_test=[regex@]number

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

जिन टारगेट के रन पूरे नहीं हो पाए हैं उनका स्टेटस, --runs_per_test_detects_flakes फ़्लैग की वैल्यू पर निर्भर करता है:

• अगर यह मौजूद नहीं है, तो किसी भी टेस्ट के फ़ेल होने पर, पूरा टेस्ट फ़ेल हो जाता है.
• अगर एक ही शार्ड से दो रन के नतीजे PASS और FAIL के तौर पर मिलते हैं, तो टेस्ट को फ़्लेकी स्टेटस मिलेगा. हालांकि, अगर अन्य फ़ेल होने वाले रन की वजह से टेस्ट फ़ेल होता है, तो उसे फ़्लेकी स्टेटस नहीं मिलेगा.

अगर एक ही संख्या दी जाती है, तो सभी टेस्ट उतनी बार चलेंगे. इसके अलावा, रेगुलर एक्सप्रेशन को 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 में उन सभी टेस्ट की सूची होती है जो पूरे हो चुके हैं. साथ ही, अगर टेस्ट पूरा नहीं हो सका, तो इसमें टेस्ट के आउटपुट वाली फ़ाइल का नाम भी शामिल होता है. यह डिफ़ॉल्ट वैल्यू होती है.
• short_uncached की तरह है, लेकिन इसमें उन टेस्ट को शामिल नहीं किया जाता जिनके नतीजे कैश मेमोरी में सेव किए गए थे.short
• terse में सिर्फ़ फ़ेल हुए और फ़्लेकी टेस्ट दिखते हैं.
• detailed में उन सभी टेस्ट की सूची होती है जो पूरे हो चुके हैं. साथ ही, इसमें हर टेस्ट केस (पास, छोड़े गए, और फ़ेल हुए) की जानकारी होती है. इसमें टेस्ट आउटपुट फ़ाइलों के नाम शामिल नहीं होते.
• detailed_uncached, detailed की तरह ही होता है. हालांकि, इसमें उन टेस्ट को शामिल नहीं किया जाता जिनके नतीजे कैश मेमोरी में सेव किए गए थे.
• testcase टेस्ट केस के नतीजे की खास जानकारी प्रिंट करता है. इसमें फ़ेल हुए टेस्ट केस के बारे में पूरी जानकारी नहीं होती.
• none टेस्ट की खास जानकारी प्रिंट नहीं करता.

--test_output=output_style

यह तय करता है कि टेस्ट का आउटपुट कैसे दिखाया जाना चाहिए:

• summary से, हर टेस्ट के पास या फ़ेल होने की खास जानकारी मिलती है. साथ ही, इससे फ़ेल हुए टेस्ट के लिए आउटपुट लॉग फ़ाइल का नाम भी दिखता है. खास जानकारी, बिल्ड के आखिर में प्रिंट की जाएगी. बिल्ड के दौरान, टेस्ट शुरू होने, पास होने या फ़ेल होने पर, सिर्फ़ प्रोग्रेस के सामान्य मैसेज दिखेंगे. यह डिफ़ॉल्ट सेटिंग है.
• errors, फ़ेल हुए टेस्ट से stdout/stderr का मिला-जुला आउटपुट सिर्फ़ stdout में भेजता है. ऐसा टेस्ट पूरा होने के तुरंत बाद किया जाता है. इससे यह पक्का किया जाता है कि एक साथ किए गए टेस्ट का आउटपुट, एक-दूसरे के साथ इंटरलीव न हो. यह ऊपर दिए गए जवाब के मुताबिक, बिल्ड के समय खास जानकारी प्रिंट करता है.
• all, errors जैसा ही होता है. हालांकि, यह पास हो चुके टेस्ट के साथ-साथ सभी टेस्ट के लिए आउटपुट प्रिंट करता है.
• streamed हर टेस्ट से stdout/stderr आउटपुट को रीयल-टाइम में स्ट्रीम करता है.

--java_debug

इस विकल्प की वजह से, Java टेस्ट की Java वर्चुअल मशीन, टेस्ट शुरू करने से पहले JDWP के साथ काम करने वाले डीबगर से कनेक्शन का इंतज़ार करती है. इस विकल्प का मतलब --test_output=streamed है.

--[no]verbose_test_summary

डिफ़ॉल्ट रूप से, यह विकल्प चालू होता है. इससे टेस्ट के समय और अन्य अतिरिक्त जानकारी (जैसे कि टेस्ट के प्रयास) को टेस्ट की खास जानकारी में प्रिंट किया जाता है. अगर --noverbose_test_summary को शामिल किया जाता है, तो टेस्ट की खास जानकारी में सिर्फ़ टेस्ट का नाम, टेस्ट की स्थिति, और कैश मेमोरी में सेव किए गए टेस्ट का इंडिकेटर शामिल होगा. साथ ही, इसे इस तरह से फ़ॉर्मैट किया जाएगा कि यह 80 वर्णों से ज़्यादा न हो.

--test_tmpdir=path

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

--test_timeout=seconds या --test_timeout=seconds,seconds,seconds,seconds

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

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

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

--test_arg=arg

यह हर टेस्ट प्रोसेस को कमांड-लाइन विकल्प/फ़्लैग/आर्ग्युमेंट पास करता है. इस विकल्प का इस्तेमाल कई बार किया जा सकता है, ताकि कई आर्ग्युमेंट पास किए जा सकें. उदाहरण के लिए, --test_arg=--logtostderr --test_arg=--v=3.

ध्यान दें कि bazel run कमांड के उलट, bazel test -- target --logtostderr --v=3 की तरह टेस्ट आर्ग्युमेंट सीधे तौर पर पास नहीं किए जा सकते. ऐसा इसलिए है, क्योंकि bazel test को पास किए गए अतिरिक्त आर्ग्युमेंट को अतिरिक्त टेस्ट टारगेट के तौर पर माना जाता है. इसका मतलब है कि --logtostderr और --v=3, दोनों को टेस्ट टारगेट के तौर पर माना जाएगा. bazel run कमांड के लिए यह समस्या नहीं होती, क्योंकि यह सिर्फ़ एक टारगेट स्वीकार करती है.

--test_arg को bazel run कमांड में पास किया जा सकता है. हालांकि, इसे तब तक अनदेखा किया जाता है, जब तक कि टारगेट को टेस्ट टारगेट के तौर पर नहीं चलाया जाता. (किसी अन्य फ़्लैग की तरह, अगर इसे -- टोकन के बाद bazel run कमांड में पास किया जाता है, तो इसे Bazel प्रोसेस नहीं करता. हालांकि, इसे एक्ज़ीक्यूट किए गए टारगेट को उसी तरह फ़ॉरवर्ड कर दिया जाता है.)

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

  % bazel run java/myapp:myapp -- --arg1 --arg2
  INFO: Analyzed target //java/myapp:myapp (13 packages loaded, 27 targets configured).
  INFO: Found 1 target...
  Target //java/myapp:myapp up-to-date:
    bazel-bin/java/myapp/myapp
  INFO: Elapsed time: 14.290s, Critical Path: 5.54s, ...
  INFO: Build completed successfully, 4 total actions
  INFO: Running command line: bazel-bin/java/myapp/myapp <args omitted>
  Hello there
  $EXEC_ROOT/java/myapp/myapp
  --arg1
  --arg2

bazel run, Bazel से बनाए गए बाइनरी को सीधे तौर पर शुरू करने जैसा ही है. हालांकि, यह उससे अलग है. इसका व्यवहार इस बात पर निर्भर करता है कि शुरू की जाने वाली बाइनरी, टेस्ट है या नहीं.

अगर बाइनरी टेस्ट नहीं है, तो मौजूदा वर्किंग डायरेक्ट्री, बाइनरी का रनफ़ाइल ट्री होगी.

अगर बाइनरी एक टेस्ट है, तो मौजूदा वर्किंग डायरेक्ट्री, एक्ज़ेक रूट होगी. साथ ही, उस एनवायरमेंट को दोहराने की पूरी कोशिश की जाएगी जिसमें आम तौर पर टेस्ट चलाए जाते हैं. हालांकि, इम्यूलेशन पूरी तरह से सही नहीं होता. साथ ही, एक से ज़्यादा शार्ड वाले टेस्ट इस तरीके से नहीं चलाए जा सकते. इस समस्या को हल करने के लिए, --test_sharding_strategy=disabled कमांड लाइन विकल्प का इस्तेमाल किया जा सकता है

बाइनरी के लिए, ये अतिरिक्त एनवायरमेंट वैरिएबल भी उपलब्ध हैं:

• BUILD_WORKSPACE_DIRECTORY: यह उस वर्कस्पेस का रूट होता है जहां बिल्ड चलाया गया था.
• BUILD_WORKING_DIRECTORY: यह मौजूदा वर्किंग डायरेक्ट्री है, जहां से Bazel को चलाया गया था.
• BUILD_ID: bazel run को शुरू करने का बिल्ड आईडी. यह आम तौर पर यूनीक होता है. हालांकि, अगर Bazel को --script_path के साथ चलाया गया था और नतीजे वाली स्क्रिप्ट का दोबारा इस्तेमाल किया जाता है, तो ऐसा नहीं होता.
• BUILD_EXECROOT: bazel run को शुरू करने का एक्ज़ीक्यूशन रूट.

उदाहरण के लिए, इनका इस्तेमाल कमांड लाइन पर फ़ाइल के नामों को समझने में आसान तरीके से किया जा सकता है.

bazel run के लिए विकल्प

--run_under=command-prefix

इसका असर, bazel test के लिए --run_under विकल्प (ऊपर देखें) के जैसा ही होता है. हालांकि, यह bazel run से चलाई जा रही कमांड पर लागू होता है, न कि bazel test से चलाए जा रहे टेस्ट पर. साथ ही, इसे लेबल के तहत नहीं चलाया जा सकता.

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 कमांड होती है, जो Make की कमांड के जैसी होती है. यह Bazel इंस्टेंस से किए गए सभी बिल्ड कॉन्फ़िगरेशन के लिए आउटपुट डायरेक्ट्री मिटा देता है. इसके अलावा, यह Bazel इंस्टेंस से बनाए गए पूरे वर्किंग ट्री को मिटा देता है और इंटरनल कैश को रीसेट कर देता है. अगर इसे किसी भी कमांड-लाइन विकल्प के बिना चलाया जाता है, तो सभी कॉन्फ़िगरेशन के लिए आउटपुट डायरेक्ट्री मिट जाएगी.

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

Bazel इंस्टेंस से बनाए गए पूरे वर्किंग ट्री को हटाने के लिए, --expunge विकल्प का इस्तेमाल किया जा सकता है. --expunge विकल्प के साथ इस्तेमाल करने पर, clean कमांड सिर्फ़ पूरे आउटपुट बेस ट्री को हटा देती है. इसमें बिल्ड आउटपुट के साथ-साथ, Bazel से बनाई गई सभी अस्थायी फ़ाइलें भी शामिल होती हैं. यह clean कमांड के बाद Bazel सर्वर को भी बंद कर देती है. यह shutdown कमांड के बराबर है. उदाहरण के लिए, किसी Bazel इंस्टेंस के सभी डिस्क और मेमोरी ट्रेस को हटाने के लिए, यह कमांड इस्तेमाल की जा सकती है:

  % bazel clean --expunge

इसके अलावा, --expunge_async का इस्तेमाल करके, बैकग्राउंड में डेटा मिटाया जा सकता है. Bazel कमांड को उसी क्लाइंट में लागू करना सुरक्षित है. ऐसा तब किया जा सकता है, जब एसिंक्रोनस तरीके से डेटा मिटाने की प्रोसेस जारी हो.

clean कमांड का इस्तेमाल मुख्य रूप से उन वर्कस्पेस के लिए डिस्क स्पेस वापस पाने के लिए किया जाता है जिनकी अब ज़रूरत नहीं है. Bazel के इंक्रीमेंटल रीबिल्ड सही नहीं हो सकते. इसलिए, समस्याएं आने पर clean का इस्तेमाल करके, एक जैसा स्टेटस वापस लाया जा सकता है.

Bazel को इस तरह से डिज़ाइन किया गया है कि इन समस्याओं को ठीक किया जा सकता है. साथ ही, इन बग को ठीक करना हमारी प्राथमिकता है. अगर आपको कभी भी गलत इंक्रीमेंटल बिल्ड मिलता है, तो गड़बड़ी की रिपोर्ट दर्ज करें. साथ ही, clean का इस्तेमाल करने के बजाय, टूल में गड़बड़ियों की शिकायत करें.

डिपेंडेंसी ग्राफ़ के बारे में क्वेरी करना

Bazel में, क्वेरी लैंग्वेज शामिल होती है. इसका इस्तेमाल, बिल्ड के दौरान इस्तेमाल किए गए डिपेंडेंसी ग्राफ़ के बारे में सवाल पूछने के लिए किया जाता है. क्वेरी लैंग्वेज का इस्तेमाल दो कमांड करती हैं: query और cquery. इन दोनों कमांड के बीच मुख्य अंतर यह है कि query, लोडिंग फ़ेज़ के बाद चलती है और cquery, विश्लेषण फ़ेज़ के बाद चलती है. ये टूल, सॉफ़्टवेयर इंजीनियरिंग के कई कामों में बहुत मददगार होते हैं.

क्वेरी लैंग्वेज, ग्राफ़ पर बीजगणितीय कार्रवाइयों के सिद्धांत पर आधारित है. इसके बारे में यहां पूरी जानकारी दी गई है

Bazel क्वेरी का रेफ़रंस देखें. कृपया रेफ़रंस के लिए उस दस्तावेज़ को देखें. इसमें उदाहरण और क्वेरी के हिसाब से कमांड-लाइन के विकल्प दिए गए हैं.

क्वेरी टूल, कई कमांड-लाइन विकल्प स्वीकार करता है. --output आउटपुट फ़ॉर्मैट चुनता है. --[no]keep_going (डिफ़ॉल्ट रूप से बंद होता है) की वजह से, गड़बड़ियों के बावजूद क्वेरी टूल काम करता रहता है. अगर गड़बड़ियों के मामले में अधूरा नतीजा स्वीकार नहीं किया जाता है, तो इस सुविधा को बंद किया जा सकता है.

--[no]tool_deps विकल्प डिफ़ॉल्ट रूप से चालू होता है. इससे, टारगेट नहीं किए गए कॉन्फ़िगरेशन में मौजूद डिपेंडेंसी को डिपेंडेंसी ग्राफ़ में शामिल किया जाता है. क्वेरी इसी ग्राफ़ पर काम करती है.

--[no]implicit_deps विकल्प डिफ़ॉल्ट रूप से चालू होता है. इससे, क्वेरी के लिए इस्तेमाल किए जाने वाले डिपेंडेंसी ग्राफ़ में, इंप्लिसिट डिपेंडेंसी शामिल हो जाती हैं. इंप्लिसिट डिपेंडेंसी ऐसी डिपेंडेंसी होती है जिसे BUILD फ़ाइल में साफ़ तौर पर नहीं बताया जाता, लेकिन Bazel उसे जोड़ देता है.

उदाहरण: "PEBL ट्री में मौजूद सभी टेस्ट बनाने के लिए ज़रूरी सभी जनरूल की परिभाषाओं (BUILD फ़ाइलों में) की जगहें दिखाओ."

  bazel query --output location 'kind(genrule, deps(kind(".*_test rule", foo/bar/pebl/...)))'

ऐक्शन ग्राफ़ से क्वेरी करना

aquery कमांड की मदद से, अपने बिल्ड ग्राफ़ में कार्रवाइयों के लिए क्वेरी की जा सकती है. यह पोस्ट-विश्लेषण के बाद कॉन्फ़िगर किए गए टारगेट ग्राफ़ पर काम करता है. साथ ही, कार्रवाइयों, आर्टफ़ैक्ट, और उनके संबंधों के बारे में जानकारी दिखाता है.

यह टूल, कमांड-लाइन के कई विकल्पों को स्वीकार करता है. --output आउटपुट फ़ॉर्मैट चुनता है. डिफ़ॉल्ट आउटपुट फ़ॉर्मैट (text) ऐसा होता है जिसे कोई भी व्यक्ति आसानी से पढ़ सकता है. मशीन के पढ़ने लायक फ़ॉर्मैट के लिए, proto या textproto का इस्तेमाल करें. खास तौर पर, aquery कमांड, सामान्य Bazel बिल्ड के ऊपर चलती है. साथ ही, यह बिल्ड के दौरान उपलब्ध विकल्पों के सेट को इनहेरिट करती है.

यह उन सभी फ़ंक्शन के साथ काम करता है जो पारंपरिक query के साथ काम करते हैं. हालांकि, siblings, buildfiles, और tests के साथ काम नहीं करता.

ज़्यादा जानकारी के लिए, ऐक्शन ग्राफ़ क्वेरी देखें.

अन्य कमांड और विकल्प

help

help कमांड से ऑनलाइन मदद मिलती है. डिफ़ॉल्ट रूप से, यह उपलब्ध निर्देशों और सहायता विषयों की खास जानकारी दिखाता है. जैसा कि Bazel की मदद से बनाना में दिखाया गया है. आर्ग्युमेंट तय करने पर, किसी विषय के बारे में ज़्यादा जानकारी मिलती है. ज़्यादातर विषय, Bazel कमांड के बारे में हैं. जैसे, build या query. हालांकि, कुछ अन्य सहायता विषय भी हैं जो कमांड से मेल नहीं खाते.

--[no]long (-l)

डिफ़ॉल्ट रूप से, bazel help [topic] किसी विषय के लिए सिर्फ़ काम के विकल्पों की खास जानकारी प्रिंट करता है. अगर --long विकल्प तय किया गया है, तो हर विकल्प का टाइप, डिफ़ॉल्ट वैल्यू, और पूरा ब्यौरा भी प्रिंट किया जाता है.

shutdown

Bazel सर्वर प्रोसेस को shutdown कमांड का इस्तेमाल करके रोका जा सकता है. इस कमांड से Bazel सर्वर बंद हो जाता है. ऐसा तब होता है, जब सर्वर पर कोई काम नहीं चल रहा होता. उदाहरण के लिए, जब कोई बिल्ड या अन्य कमांड पूरी हो जाती है. ज़्यादा जानकारी के लिए, क्लाइंट/सर्वर को लागू करना लेख पढ़ें.

Bazel सर्वर, कुछ समय तक इस्तेमाल न होने पर अपने-आप बंद हो जाते हैं. इसलिए, इस कमांड की ज़रूरत बहुत कम पड़ती है. हालांकि, स्क्रिप्ट में इसका इस्तेमाल तब किया जा सकता है, जब यह पता हो कि किसी वर्कस्पेस में आगे कोई और बिल्ड नहीं होगा.

shutdown में एक विकल्प, --iff_heap_size_greater_than _n_ होता है. इसके लिए, पूर्णांक (एमबी में) के तौर पर आर्ग्युमेंट की ज़रूरत होती है. अगर यह विकल्प चुना जाता है, तो शटडाउन की प्रोसेस इस बात पर निर्भर करती है कि पहले से कितनी मेमोरी इस्तेमाल की जा चुकी है. यह उन स्क्रिप्ट के लिए फ़ायदेमंद है जो कई बिल्ड शुरू करती हैं. ऐसा इसलिए, क्योंकि Bazel सर्वर में मेमोरी लीक होने से, कभी-कभी यह अचानक क्रैश हो सकता है. शर्त के हिसाब से रीस्टार्ट करने पर, इस समस्या से बचा जा सकता है.

info

info कमांड, Bazel सर्वर इंस्टेंस या किसी खास बिल्ड कॉन्फ़िगरेशन से जुड़ी अलग-अलग वैल्यू प्रिंट करती है. (इनका इस्तेमाल उन स्क्रिप्ट से किया जा सकता है जो बिल्ड को ड्राइव करती हैं.)

info कमांड में एक (ज़रूरी नहीं) आर्ग्युमेंट भी दिया जा सकता है. यह आर्ग्युमेंट, यहां दी गई सूची में मौजूद किसी एक कुंजी का नाम होता है. इस मामले में, bazel info key सिर्फ़ उस कुंजी की वैल्यू प्रिंट करेगा. यह खास तौर पर Bazel की स्क्रिप्टिंग के दौरान काम आता है, क्योंकि इससे नतीजे को sed -ne /key:/s/key://p के ज़रिए पाइप करने की ज़रूरत नहीं पड़ती:

कॉन्फ़िगरेशन से अलग डेटा

• release: इस Bazel इंस्टेंस के लिए रिलीज़ लेबल या "development version", अगर यह रिलीज़ किया गया बाइनरी नहीं है.
• workspace बेस वर्कस्पेस डायरेक्ट्री का ऐब्सलूट पाथ.

• install_base: यह मौजूदा उपयोगकर्ता के लिए, Bazel के इस इंस्टेंस के इस्तेमाल की गई इंस्टॉलेशन डायरेक्ट्री का पूरा पाथ है. Bazel, इस डायरेक्ट्री में अंदरूनी तौर पर ज़रूरी एक्ज़ीक्यूटेबल इंस्टॉल करता है.

• output_base: यह मौजूदा उपयोगकर्ता और वर्कस्पेस के कॉम्बिनेशन के लिए, इस Bazel इंस्टेंस की ओर से इस्तेमाल की गई बेस आउटपुट डायरेक्ट्री का ऐब्सलूट पाथ है. Bazel, इस डायरेक्ट्री के नीचे अपने सभी स्क्रैच और बिल्ड आउटपुट रखता है.

• execution_root: यह output_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 हीप साइज़ के बारे में रिपोर्ट करता है पैरामीटर. इनका मतलब यह है: फ़िलहाल इस्तेमाल की जा रही मेमोरी, सिस्टम से JVM को फ़िलहाल उपलब्ध कराई गई मेमोरी, और ज़्यादा से ज़्यादा मेमोरी.

• gc-count, gc-time: इस Bazel सर्वर के शुरू होने के बाद से, कचरा इकट्ठा करने की कुल संख्या और उन्हें पूरा करने में लगा समय. ध्यान दें कि हर बिल्ड की शुरुआत में, इन वैल्यू को रीसेट नहीं किया जाता.

• package_path: यह कोलन से अलग किए गए पाथ की सूची होती है. Bazel, पैकेज ढूंढने के लिए इन पाथ का इस्तेमाल करता है. इसका फ़ॉर्मैट, --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 से मिली वैल्यू का इस्तेमाल करने वाली स्क्रिप्ट ज़्यादा भरोसेमंद होंगी.
• "Make" एनवायरमेंट का पूरा ऐक्सेस. अगर --show_make_env फ़्लैग तय किया गया है, तो मौजूदा कॉन्फ़िगरेशन के "मेक" एनवायरमेंट में मौजूद सभी वैरिएबल भी दिखते हैं. जैसे, CC, GLIBC_VERSION वगैरह. ये ऐसे वैरिएबल होते हैं जिन्हें BUILD फ़ाइलों में $(CC) या varref("CC") सिंटैक्स का इस्तेमाल करके ऐक्सेस किया जाता है.

उदाहरण: मौजूदा कॉन्फ़िगरेशन के लिए C++ कंपाइलर. यह "Make" एनवायरमेंट में $(CC) वैरिएबल है. इसलिए, $(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

version कमांड, बनाए गए Bazel बाइनरी के वर्शन की जानकारी प्रिंट करती है. इसमें वह बदलाव सूची और तारीख शामिल होती है जिस पर इसे बनाया गया था. ये खास तौर पर यह तय करने में मददगार होते हैं कि आपके पास Bazel का नया वर्शन है या नहीं. साथ ही, ये बग की रिपोर्ट करने में भी मददगार होते हैं. कुछ दिलचस्प वैल्यू ये हैं:

• changelist: वह बदलाव सूची जिस पर Bazel का यह वर्शन रिलीज़ किया गया था.
• label: इस Bazel इंस्टेंस के लिए रिलीज़ लेबल या "development version", अगर यह रिलीज़ किया गया बाइनरी नहीं है. गड़बड़ियों की शिकायत करते समय यह बहुत काम आता है.

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

mobile-install

mobile-install कमांड, मोबाइल डिवाइसों पर ऐप्लिकेशन इंस्टॉल करती है. फ़िलहाल, सिर्फ़ ART पर काम करने वाले Android डिवाइसों के साथ इसका इस्तेमाल किया जा सकता है.

ज़्यादा जानकारी के लिए, bazel mobile-install देखें.

ये विकल्प इस्तेमाल किए जा सकते हैं:

--incremental

अगर यह विकल्प सेट किया जाता है, तो Bazel ऐप्लिकेशन को इंक्रीमेंटल तरीके से इंस्टॉल करने की कोशिश करता है. इसका मतलब है कि सिर्फ़ उन हिस्सों को इंस्टॉल किया जाता है जिनमें पिछली बिल्ड के बाद बदलाव हुआ है. इससे AndroidManifest.xml, नेटिव कोड या Java रिसॉर्स (जैसे कि Class.getResource() से रेफ़र किए गए रिसॉर्स) से रेफ़र किए गए रिसॉर्स अपडेट नहीं किए जा सकते. अगर इनमें बदलाव होता है, तो इस विकल्प को हटाना होगा. Bazel के सिद्धांतों के उलट और Android प्लैटफ़ॉर्म की सीमाओं की वजह से, यह उपयोगकर्ता की ज़िम्मेदारी है कि वह यह तय करे कि इस कमांड का इस्तेमाल कब किया जा सकता है और कब पूरा इंस्टॉलेशन ज़रूरी है.

अगर Marshmallow या उसके बाद के वर्शन वाले डिवाइस का इस्तेमाल किया जा रहा है, तो --split_apks फ़्लैग का इस्तेमाल करें.

--split_apks

डिवाइस पर ऐप्लिकेशन को इंस्टॉल और अपडेट करने के लिए, स्प्लिट एपीके का इस्तेमाल करना है या नहीं. यह सुविधा, सिर्फ़ Marshmallow या इसके बाद के वर्शन वाले डिवाइसों पर काम करती है. ध्यान दें कि --split_apks का इस्तेमाल करते समय, --incremental फ़्लैग का इस्तेमाल करना ज़रूरी नहीं है.

--start_app

यह कुकी, ऐप्लिकेशन को इंस्टॉल करने के बाद उसे क्लीन स्टेट में शुरू करती है. --start=COLD के बराबर.

--debug_app

यह कुकी, ऐप्लिकेशन को इंस्टॉल करने के बाद, उसे क्लीन स्टेट में शुरू करने से पहले, डीबगर के अटैच होने का इंतज़ार करती है. --start=DEBUG के बराबर.

--start=_start_type_

ऐप्लिकेशन इंस्टॉल करने के बाद, उसे कैसे शुरू किया जाना चाहिए. इन _start_type_s का इस्तेमाल किया जा सकता है:

• NO इससे ऐप्लिकेशन शुरू नहीं होता. यह डिफ़ॉल्ट विकल्प है.
• COLD इंस्टॉल होने के बाद, ऐप्लिकेशन को नए सिरे से शुरू करता है.
• WARM यह कुकी, इंक्रीमेंटल इंस्टॉल पर ऐप्लिकेशन की स्थिति को सेव करती है और उसे पहले जैसा करती है.
• DEBUG इंस्टॉल करने के बाद, ऐप्लिकेशन को क्लीन स्टेट में शुरू करने से पहले, डीबगर का इंतज़ार करता है.

--adb=path

इससे पता चलता है कि कौनसा adb बाइनरी इस्तेमाल किया जाना है.

डिफ़ॉल्ट रूप से, --android_sdk में बताए गए Android SDK टूल में adb का इस्तेमाल किया जाता है.

--adb_arg=serial

adb में अतिरिक्त आर्ग्युमेंट. ये कमांड लाइन में सब-कमांड से पहले आते हैं. इनका इस्तेमाल आम तौर पर यह तय करने के लिए किया जाता है कि किस डिवाइस पर इंस्टॉल करना है. उदाहरण के लिए, इस्तेमाल करने के लिए Android डिवाइस या एम्युलेटर चुनने के लिए:

% bazel mobile-install --adb_arg=-s --adb_arg=deadbeef

adb को इस तरह ट्रिगर किया जा सकता है

adb -s deadbeef install ...

--incremental_install_verbosity=number

इंक्रीमेंटल इंस्टॉल के लिए वर्बोसिटी. डीबग लॉग को कंसोल पर प्रिंट करने के लिए, इस वैल्यू को 1 पर सेट करें.

dump

dump कमांड, Bazel सर्वर की इंटरनल स्थिति को stdout पर डंप करती है. इस कमांड का इस्तेमाल मुख्य रूप से Bazel डेवलपर करते हैं. इसलिए, इस कमांड के आउटपुट के बारे में नहीं बताया गया है. साथ ही, इसमें बदलाव किया जा सकता है.

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

ये विकल्प इस्तेमाल किए जा सकते हैं:

• --action_cache ऐक्शन कैश मेमोरी में मौजूद कॉन्टेंट को डंप करता है.
• --packages पैकेज की कैश मेमोरी में सेव किए गए कॉन्टेंट को डंप करता है.
• --skyframe Bazel के इंटरनल डिपेंडेंसी ग्राफ़ की स्थिति को डंप करता है.
• --rules हर नियम और पहलू क्लास के लिए, नियम की खास जानकारी डंप करता है. इसमें गिनती और ऐक्शन की गिनती शामिल है. इसमें नेटिव और Starlark, दोनों तरह के नियम शामिल हैं. अगर मेमोरी ट्रैकिंग चालू है, तो नियमों के मेमोरी इस्तेमाल की जानकारी भी प्रिंट की जाती है.
• --skylark_memory, pprof के साथ काम करने वाली .gz फ़ाइल को तय किए गए पाथ पर डंप करता है. इस सुविधा का इस्तेमाल करने के लिए, आपको मेमोरी ट्रैकिंग की सुविधा चालू करनी होगी.

मेमोरी ट्रैकिंग

dump की कुछ कमांड के लिए, मेमोरी ट्रैकिंग की ज़रूरत होती है. इसे चालू करने के लिए, आपको Bazel को स्टार्टअप फ़्लैग पास करने होंगे:

• --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.4.jar
• --host_jvm_args=-DRULE_MEMORY_TRACKER=1

java-agent को Bazel में third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.4.jar पर चेक किया जाता है. इसलिए, पक्का करें कि आपने $BAZEL को उस जगह के हिसाब से अडजस्ट किया हो जहां आपने Bazel रिपॉज़िटरी रखी है.

हर कमांड के लिए, इन विकल्पों को Bazel को पास करना न भूलें. ऐसा न करने पर, सर्वर रीस्टार्ट हो जाएगा.

उदाहरण:

    % bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.4.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.4.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.4.jar \
    --host_jvm_args=-DRULE_MEMORY_TRACKER=1 \
    dump --skylark_memory=$HOME/prof.gz
    % pprof -flame $HOME/prof.gz

analyze-profile

analyze-profile कमांड, JSON ट्रेस प्रोफ़ाइल का विश्लेषण करती है. यह प्रोफ़ाइल, Bazel इनवोकेशन के दौरान पहले इकट्ठा की गई थी.

canonicalize-flags

canonicalize-flags कमांड, जो Bazel कमांड के लिए विकल्पों की सूची लेती है और विकल्पों की ऐसी सूची दिखाती है जिसका असर एक जैसा होता है. विकल्पों की नई सूची कैननिकल होती है. उदाहरण के लिए, एक जैसे असर वाले विकल्पों की दो सूचियों को एक ही नई सूची में कैननिकल किया जाता है.

--for_command विकल्प का इस्तेमाल, अलग-अलग निर्देशों में से किसी एक को चुनने के लिए किया जा सकता है. फ़िलहाल, सिर्फ़ build और test का इस्तेमाल किया जा सकता है. दिए गए निर्देश के साथ काम न करने वाले विकल्पों से गड़बड़ी होती है.

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

  % bazel canonicalize-flags -- --config=any_name --test_tag_filters="-lint"
  --config=any_name
  --test_tag_filters=-lint

स्टार्टअप के विकल्प

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

इस सेक्शन में बताए गए सभी विकल्पों को --key=value या --key value सिंटैक्स का इस्तेमाल करके तय किया जाना चाहिए. साथ ही, ये विकल्प Bazel कमांड के नाम से पहले दिखने चाहिए. इन्हें .bazelrc फ़ाइल में शामिल करने के लिए, startup --key=value का इस्तेमाल करें.

--output_base=dir

इस विकल्प के लिए, पाथ आर्ग्युमेंट की ज़रूरत होती है. इसमें ऐसी डायरेक्ट्री के बारे में बताना होता है जिसमें लिखा जा सकता हो. Bazel इस जगह का इस्तेमाल अपने सभी आउटपुट को लिखने के लिए करेगा. आउटपुट बेस भी वह कुंजी है जिसकी मदद से क्लाइंट, Bazel सर्वर का पता लगाता है. आउटपुट बेस बदलने से, उस सर्वर में बदलाव होता है जो निर्देश को हैंडल करेगा.

डिफ़ॉल्ट रूप से, आउटपुट बेस, उपयोगकर्ता के लॉगिन नाम और वर्कस्पेस डायरेक्ट्री के नाम से मिलता है. हालांकि, यह नाम MD5 डाइजेस्ट होता है. इसलिए, सामान्य वैल्यू इस तरह दिखती है: /var/tmp/google/_bazel_johndoe/d41d8cd98f00b204e9800998ecf8427e.

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

 OUTPUT_BASE=/var/tmp/google/_bazel_johndoe/custom_output_base
% bazel --output_base ${OUTPUT_BASE}1 build //foo  &  bazel --output_base ${OUTPUT_BASE}2 build //bar

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

--output_user_root=dir

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

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

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

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

--server_javabase=dir

यह उस Java वर्चुअल मशीन के बारे में बताता है जिसमें Bazel खुद चलता है. वैल्यू, JDK या JRE वाले डायरेक्ट्री का पाथ होना चाहिए. यह लेबल नहीं होना चाहिए. यह विकल्प, किसी भी Bazel कमांड से पहले दिखना चाहिए. उदाहरण के लिए:

  % bazel --server_javabase=/usr/local/buildtools/java/jdk build //foo

इस फ़्लैग का असर, Bazel सबप्रोसेस के ज़रिए इस्तेमाल किए जाने वाले JVM पर नहीं पड़ता. जैसे, ऐप्लिकेशन, टेस्ट, टूल वगैरह. इसके बजाय, --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 की सबप्रोसेस, जैसे कि ऐप्लिकेशन, टेस्ट, टूल वगैरह के लिए इस्तेमाल किए जाने वाले किसी भी JVM पर असर नहीं पड़ता. bazel run या कमांड-लाइन से चलाए जाने वाले Java के एक्ज़ीक्यूटेबल प्रोग्राम में JVM के विकल्प पास करने के लिए, आपको --jvm_flags आर्ग्युमेंट का इस्तेमाल करना चाहिए. यह आर्ग्युमेंट, सभी java_binary और java_test प्रोग्राम के साथ काम करता है. इसके अलावा, टेस्ट के लिए bazel test --test_arg=--jvm_flags=foo ... का इस्तेमाल करें.

--host_jvm_debug

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

--autodetect_server_javabase

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

--batch

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

बैच मोड, एक ही output_base में सही क्यूइंग सिमैंटिक बनाए रखता है. इसका मतलब है कि एक साथ किए गए अनुरोधों को क्रम से प्रोसेस किया जाएगा. इनमें कोई रुकावट नहीं आएगी. अगर किसी ऐसे क्लाइंट पर बैच मोड Bazel चलाया जाता है जिस पर सर्वर चल रहा है, तो यह कमांड को प्रोसेस करने से पहले सर्वर को बंद कर देता है.

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

--max_idle_secs=n

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

इस विकल्प का इस्तेमाल उन स्क्रिप्ट के लिए किया जा सकता है जो Bazel को चालू करती हैं. इससे यह पक्का किया जा सकता है कि जब स्क्रिप्ट नहीं चल रही हो, तब वे उपयोगकर्ता के मशीन पर Bazel सर्वर प्रोसेस को न छोड़ें. उदाहरण के लिए, कोई प्रीसबमिट स्क्रिप्ट यह पक्का करने के लिए bazel query को कॉल कर सकती है कि उपयोगकर्ता के लंबित बदलाव से अवांछित डिपेंडेंसी न जुड़ें. हालांकि, अगर उपयोगकर्ता ने उस वर्कस्पेस में हाल ही में कोई बिल्ड नहीं किया है, तो प्रीसबमिट स्क्रिप्ट के लिए Bazel सर्वर शुरू करना सही नहीं होगा. ऐसा इसलिए, क्योंकि सर्वर पूरे दिन निष्क्रिय रहेगा. क्वेरी के अनुरोध में --max_idle_secs की छोटी वैल्यू तय करके, स्क्रिप्ट यह पक्का कर सकती है कि अगर इसकी वजह से कोई नया सर्वर शुरू हुआ है, तो वह सर्वर तुरंत बंद हो जाएगा. हालांकि, अगर पहले से कोई सर्वर चल रहा है, तो वह सर्वर तब तक चलता रहेगा, जब तक वह सामान्य समय के लिए बंद नहीं हो जाता. ज़रूर, सर्वर के मौजूदा आइडल टाइमर को रीसेट कर दिया जाएगा.

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

यह सबसे बेहतर कोशिशों के आधार पर, आई/ओ शेड्यूल करने के लिए 0 से 7 तक का लेवल सेट करता है. 0 सबसे ज़्यादा प्राथमिकता और 7 सबसे कम प्राथमिकता है. अनुमानित शेड्यूल करने की सुविधा, सिर्फ़ चौथी प्राथमिकता तक के अनुरोधों को पूरा कर सकती है. नेगेटिव वैल्यू को अनदेखा कर दिया जाता है.

--batch_cpu_scheduling

Bazel के लिए, batch सीपीयू शेड्यूलिंग का इस्तेमाल करें. यह नीति उन वर्कलोड के लिए काम की है जो इंटरैक्टिव नहीं हैं, लेकिन अपनी नाइस वैल्यू को कम नहीं करना चाहते हैं. 'man 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 से जनरेट किए गए हर मैसेज में एक टाइमस्टैंप जोड़ा जाता है. इससे पता चलता है कि मैसेज कब दिखाया गया था.