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

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.
किसी समस्या की शिकायत करें स्रोत देखें

इस पेज पर ऐसे कई विकल्प मौजूद हैं जो अलग-अलग बेज़ल कमांड के साथ उपलब्ध होते हैं, जैसे कि bazel build, bazel run, और bazel test. यह पेज Bzel के साथ बनाएं में Bazel के निर्देशों की सूची का साथी है.

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

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

विकल्प

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

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

पैकेज की जगह

--package_path

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

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. काम करने वाली डायरेक्ट्री के मुकाबले बाकी सब कुछ अपने-आप हो जाता है. आम तौर पर, यह वह नहीं है जो आप करना चाहते हैं. अगर आप बेज़ल फ़ाइल फ़ोल्डर के नीचे निर्देशिका से बेज़ल का इस्तेमाल करते हैं, तो वह अचानक काम कर सकता है. उदाहरण के लिए, अगर आप पैकेज-पाथ एलिमेंट . का इस्तेमाल करते हैं और फिर डायरेक्ट्री /home/bob/clients/bob_client/bazel/foo में cd डालते हैं, तो पैकेज /home/bob/clients/bob_client/bazel/foo डायरेक्ट्री से रिज़ॉल्व किए जाएंगे.

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

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

उदाहरण: ऐसे क्लाइंट की प्रॉपर्टी बनाना जो खाली हो

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

--deleted_packages

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

गड़बड़ी की जाँच की जा रही है

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

--[no]check_visibility

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

--output_filter=regex

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

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

`--output_filter='^//(first/project|second/project):'` बताए गए पैकेज के लिए आउटपुट दिखाएं.
`--output_filter='^//((?!(first/bad_project|second/bad_project):)*$'` चुने गए पैकेज के लिए आउटपुट न दिखाएं.
`--आउटपुट_फ़िल्टर=` सब कुछ दिखाएं.
`--आउटपुट_फ़िल्टर=DONT_MATCH_ANYThings` कुछ न दिखाएं.

टूल के झंडे

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

--copt=cc-option

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

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

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

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

--host_copt=cc-option

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

--host_conlyopt=cc-option

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

--host_cxxopt=cc-option

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

--host_linkopt=linker-option

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

--conlyopt=cc-option

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

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

--cxxopt=cc-option

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

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

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

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

--linkopt=linker-option

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

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

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

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

--strip (always|never|sometimes)

यह विकल्प तय करता है कि Ba जुड़े सभी बाइनरी और शेयर की गई लाइब्रेरी से डीबग करने की जानकारी को हटा देगा या नहीं. इसके लिए, लिंकर को -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 विकल्प का इस्तेमाल करना होगा. ऐसा करने के लिए, --linkopt=-Wl,--strip-all को Bazel में पास करें. यह भी ध्यान रखें कि 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++ बाइनरी फ़ाइल एक्ज़ीक्यूट होने पर, एफ़डीओ (सुझाव भेजा गया ऑप्टिमाइज़ेशन) प्रोफ़ाइल जनरेट हो सकती है. GCC के लिए, दिए गए आर्ग्युमेंट का उपयोग .gcda फ़ाइलों के ऑब्जेक्ट ऑब्जेक्ट फ़ाइल डायरेक्ट्री के लिए प्रीफ़िक्स के रूप में किया जाता है, जिसमें हर .o फ़ाइल की प्रोफ़ाइल जानकारी होती है.

प्रोफ़ाइल डेटा ट्री जनरेट होने के बाद, प्रोफ़ाइल ट्री ज़िप किया जाना चाहिए और एफ़डीओ-ऑप्टिमाइज़ की गई कंपोज़िशन को चालू करने के लिए, --fdo_optimize=profile-zip बेज़ल के विकल्प को दिया जाना चाहिए.

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

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

--fdo_optimize=profile-zip

--fdo_optimize विकल्प, कंपाइल करते समय एफ़डीओ (फ़ीडबैक निर्देशित ऑप्टिमाइज़ेशन) ऑप्टिमाइज़ेशन करने के लिए हर ऑब्जेक्ट की फ़ाइल प्रोफ़ाइल जानकारी का इस्तेमाल करने की सुविधा देता है. GCC के लिए, दिया गया आर्ग्युमेंट एक ZIP फ़ाइल है, जिसमें पहले से जनरेट की गई .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, 14, और 15. इसके लिए, आपको default_java_toolchain का इस्तेमाल करके, अपनी पसंद के मुताबिक Java टूल चेन रजिस्टर करनी होंगी.

--tool_java_language_version=version

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

--java_runtime_version=version

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

  % bazel run --java_runtime_version=remotejdk_11 java/com/example/common/foo:java_application

JDK 11 को किसी रिमोट रिपॉज़िटरी (डेटा स्टोर करने की जगह) से डाउनलोड करता है और उसका इस्तेमाल करके Java ऐप्लिकेशन चलाता है.

डिफ़ॉल्ट वैल्यू localjdk है. संभावित वैल्यू ये हैं: localjdk, localjdk_version, remotejdk_11, और remote_jdk17. आप local_java_repository या remote_java_repostory रिपॉज़िटरी नियमों का इस्तेमाल करके, कस्टम JVM को रजिस्टर करके, वैल्यू को बढ़ा सकते हैं.

--tool_java_runtime_version=version

जेवीएम के ऐसे वर्शन का इस्तेमाल किया जाता था जिसे बिल्ड के दौरान ज़रूरी टूल चलाने के लिए इस्तेमाल किया जाता था. डिफ़ॉल्ट वैल्यू 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

javac डिफ़ॉल्ट डीबग जानकारी के साथ एक java_binary फिर से बनाएगा (bazel डिफ़ॉल्ट के बजाय).

यह विकल्प JavaScript के लिए, बेज़ल में पहले से मौजूद डिफ़ॉल्ट विकल्पों के बाद और हर नियम के विकल्पों से पहले, 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] टाइप की जावा की सामान्य चेतावनियां जनरेट करेगा.
  • default, strict, और error सभी मीन javac, चेतावनी के बजाय गड़बड़ियां जनरेट करेंगे. इसकी वजह से, अगर कोई डायरेक्ट डिपेंडेंसी मिलती है, तो मौजूदा टारगेट नहीं बन पाता. जब यह फ़्लैग तय न किया गया हो, तब भी यह डिफ़ॉल्ट तरीका है.

सिमेंटिक बनाएं

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

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

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

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

--cpu=cpu

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

--action_env=VAR=VALUE

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

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

--experimental_action_listener=label

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

--[no]experimental_extra_action_top_level_only

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

--experimental_extra_action_filter=regex

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

यह फ़्लैग सिर्फ़ --experimental_action_listener फ़्लैग के साथ लागू होता है.

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

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

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

--host_cpu=cpu

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

--fat_apk_cpu=cpu[,cpu]*

android_binary के अस्थायी deps नियमों में, C/C++ लाइब्रेरी बनाने के लिए सीपीयू. इससे, C/C++ के अन्य नियमों पर असर नहीं पड़ता. उदाहरण के लिए, अगर cc_library, android_binary नियम और cc_binary नियम के ट्रांज़िट समय के deps में दिखता है, तो cc_library का इस्तेमाल कम से कम दो बार किया जाएगा: android_binary नियम के लिए --fat_apk_cpu के साथ बताए गए हर सीपीयू के लिए एक बार और cc_binary नियम के लिए --cpu के साथ बताए गए सीपीयू के लिए.

डिफ़ॉल्ट armeabi-v7a है.

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

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

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

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

जनरेट की गई फ़ाइलों (जैसे कि जेनरल आउटपुट) का मिलान करने के लिए, Bazel सिर्फ़ एक्ज़ीक्यूशन पाथ का इस्तेमाल कर सकता है. इस मामले में, रेगुलर एक्सप्रेशन '//' से शुरू नहीं होना चाहिए, क्योंकि यह किसी भी एक्ज़ीक्यूशन पाथ से मेल नहीं खाता. पैकेज के नाम इस तरह इस्तेमाल किए जा सकते हैं: --per_file_copt=base/.*\.pb\.cc@-g0. यह हर .pb.cc फ़ाइल को base नाम की डायरेक्ट्री में जोड़ देता है.

इस विकल्प को कई बार इस्तेमाल किया जा सकता है.

यह विकल्प लागू किए गए कंपाइलेशन मोड पर लागू नहीं होता. उदाहरण के लिए, --compilation_mode=opt के साथ कंपाइल किया जा सकता है. साथ ही, कुछ ऑप्टिमाइज़ेशन के लिए, बेहतर ऑप्टिमाइज़ेशन चालू करके या ऑप्टिमाइज़ेशन की सुविधा बंद होने पर भी ऐसा किया जा सकता है.

चेतावनी: अगर कुछ फ़ाइलों को डीबग के निशान के साथ चुनिंदा तरीके से इकट्ठा किया गया है, तो लिंक करते समय उन चिह्नों को हटाया जा सकता है. इसे --strip=never को सेट करके रोका जा सकता है.

सिंटैक्स: [+-]regex[,[+-]regex]...@option[,option]... जहां regex का मतलब है एक रेगुलर एक्सप्रेशन. इससे + में शामिल पैटर्न की पहचान की जा सकती है. साथ ही, शामिल करने के पैटर्न - से बताया जा सकता है. option एक आर्बिट्रेरी विकल्प है, जो C++ कंपाइलर को पास किया जाता है. अगर किसी विकल्प में , शामिल है, तो उसे इस तरह कोट करना होगा \,. विकल्पों में @ भी हो सकता है, क्योंकि रेगुलर एक्सप्रेशन को विकल्पों से अलग करने के लिए सिर्फ़ पहले @ का इस्तेमाल किया जाता है.

उदाहरण: --per_file_copt=//foo:.*\.cc,-//foo:file\.cc@-O0,-fprofile-arcsfile.cc को छोड़कर, //foo/ में सभी .cc फ़ाइलों के लिए, C++ कंपाइलर की कमांड लाइन में -O0 और -fprofile-arcs विकल्प जोड़ देता है.

--dynamic_mode=mode

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

मोड:

  • auto: प्लैटफ़ॉर्म के हिसाब से मोड में अनुवाद करता है; default linux के लिए और off को gwg.
  • default: बेज़ल को यह चुनने की अनुमति देता है कि डायनैमिक तौर पर लिंक करें या नहीं. ज़्यादा जानकारी के लिए, linkstatic देखें.
  • fully: सभी टारगेट डाइनैमिक तौर पर लिंक करता है. इससे लिंक करने का समय तेज़ हो जाएगा और नतीजे में मिलने वाली बाइनरी का आकार कम हो जाएगा.
  • offसभी टारगेट को ज़्यादातर स्टैटिक मोड में लिंक करता है. अगर -static ऑप्ट-आउट में सेट है, तो टारगेट पूरी तरह स्टैटिक में बदल जाएंगे.

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

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

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

--force_ignore_dash_static

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

--[no]force_pic

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

--android_resource_shrinking

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

--custom_malloc=malloc-library-target

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

--crosstool_top=label

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

--host_crosstool_top=label

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

--apple_crosstool_top=label

obbc*, ios*, और apple* नियमों के स्थायी deps उन लक्ष्यों के लिए, यह फ़्लैग --crosstool_top को ओवरराइट कर देता है.

--android_crosstool_top=label

android_binary में से deps ट्रांज़िट समय में, C/C++ नियमों को कंपाइल करने के लिए, इस्तेमाल किया जाने वाला क्रॉस-टूल. अगर बिल्ड में मौजूद दूसरे टारगेट के लिए अलग क्रॉसटूल की ज़रूरत होती है, तो यह काम आता है. डिफ़ॉल्ट रूप से, Workspace फ़ाइल में android_ndk_repository नियम से जनरेट किए गए क्रॉस-टूल का इस्तेमाल किया जाना चाहिए. यह भी देखें --fat_apk_cpu.

--compiler=version

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

--android_sdk=label

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

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

--java_toolchain=label

यह विकल्प java_toolchain के लेबल के बारे में बताता है, जिसका इस्तेमाल Java स्रोत फ़ाइलें कंपाइल करने में किया जाता है.

--host_java_toolchain=label

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

--javabase=(label)

यह विकल्प Bazel रन, बेज़ल टेस्ट, और java_binary और java_test नियमों से बनाई गई Java बाइनरी के लिए इस्तेमाल करने के लिए, बेस Java इंस्टॉलेशन का लेबल सेट करता है. JAVABASE और JAVA "बनाएं" वैरिएबल इस विकल्प से लिए जाते हैं.

--host_javabase=label

यह विकल्प, होस्ट कॉन्फ़िगरेशन में इस्तेमाल करने के लिए, Java की बुनियादी सुविधाओं के लेबल को सेट करता है. उदाहरण के लिए, JavaBuilder और SingleTracker जैसे होस्ट बिल्ड टूल के लिए.

यह उस Java कंपाइलर को नहीं चुनता है जिसका इस्तेमाल Java स्रोत फ़ाइलों को कंपाइल करने के लिए किया जाता है. कंपाइलर को --java_toolchain सेटिंग में जाकर चुना जा सकता है.

एक्ज़ीक्यूशन की रणनीति

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

--spawn_strategy=strategy

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

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

--strategy mnemonic=strategy

यह विकल्प, --spawn_stratege (और --genrule_strategi को monemonic Genrule के साथ ओवरराइड करते समय) यह कंट्रोल करता है कि कमांड कहां और किस तरह लागू होते हैं. साथ काम करने वाली रणनीतियों और उनके असर के लिए --spawn_stratege देखें.

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

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

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

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

--genrule_strategy=strategy

यह --strategy=Genrule=strategy के लिए बहिष्कृत शॉर्ट-हैंड है.

--jobs=n (-जे)

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

--progress_report_interval=n

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

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

जब बेज़ल कर्सर से कंट्रोल इस्तेमाल करता है, तो उस स्थिति में --curses से बताया जाता है.

--local_{ram,cpu}_resources resources or resource expression

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

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

जब जांच या ऐप्लिकेशन लागू किए जाते हैं, तब उनके रन टाइम डेटा की डिपेंडेंसी एक ही जगह पर इकट्ठा की जाती हैं. बैज़ेल के आउटपुट ट्री में, "रनफ़ाइल" ट्री को आम तौर पर इससे जुड़ी बाइनरी या जांच के प्रतिरूप के रूप में रूट किया जाता है. टेस्ट करते समय, रनफ़ाइल को $TEST_SRCDIR/workspace/packagename/filename के पाथ का इस्तेमाल करके ऐक्सेस किया जा सकता है. रनफ़ाइल ट्री यह पक्का करता है कि टेस्ट के पास उन सभी फ़ाइलों का ऐक्सेस हो जिन पर निर्भरता के बारे में बताया गया है. डिफ़ॉल्ट रूप से, रनफ़ाइल ट्री ज़रूरी फ़ाइलों के सिंबॉलिक लिंक का एक सेट बनाकर लागू किया जाता है. जैसे-जैसे लिंक का सेट बढ़ता जाता है, वैसे-वैसे इस ऑपरेशन की लागत बढ़ती जाती है और कुछ बड़े बिल्ड के लिए यह बिल्ड के समय में बहुत ज़्यादा योगदान दे सकता है. ऐसा खास तौर पर इसलिए होता है क्योंकि हर एक टेस्ट (या ऐप्लिकेशन) का अपना रनफ़ाइल ट्री होना चाहिए.

--[no]build_runfile_manifests

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

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

--[no]discard_analysis_cache

इस विकल्प के चालू होने पर, Bazel विश्लेषण शुरू होने से ठीक पहले विश्लेषण कैश को खारिज कर देगा, जिससे कार्रवाई के चरण के लिए ज़्यादा मेमोरी (करीब 10%) छूट मिलेगी. इसकी कमी यह है कि इससे ज़्यादा इंक्रीमेंटल बिल्ड धीरे-धीरे काम करेंगे. मेमोरी बचाने वाला मोड भी देखें.

--[no]keep_going (-के)

जैसा कि GNU Make में होता है, पहली गड़बड़ी मिलने पर बिल्ड का निष्पादन चरण रुक जाता है. कभी-कभी गड़बड़ियों का सामना करने के दौरान ज़्यादा से ज़्यादा साइट बनाने की कोशिश करना फ़ायदेमंद होता है. इस विकल्प से, इस तरह के व्यवहार को चालू किया जाता है. साथ ही, जब इसकी जानकारी दी जाती है, तब बिल्ड हर टारगेट बनाने की कोशिश करता है. इसकी मदद से, ज़रूरी शर्तें पूरी हो जाती हैं, लेकिन गड़बड़ियों को अनदेखा कर दिया जाता है.

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

--[no]use_ijars

इस विकल्प से, java_library टारगेट टारगेट करने का तरीका बज़ल तैयार करता है. डिपेंडेंट डिपेंडेंट java_library टारगेट इकट्ठा करने के लिए, java_library का इस्तेमाल करने के बजाय, Bazel ऐसा इंटरफ़ेस जार बनाएगा जिसमें सिर्फ़ गैर-निजी सदस्यों (सार्वजनिक, सुरक्षित, और डिफ़ॉल्ट (पैकेज) ऐक्सेस करने के तरीकों और फ़ील्ड) के हस्ताक्षर होंगे. साथ ही, निर्भर टारगेट को कंपाइल करने के लिए, इंटरफ़ेस जार का इस्तेमाल करेंगे. ऐसा करने से, जब किसी मैथड या किसी कक्षा के निजी सदस्यों के लिए बदलाव किए जाते हैं, तो हो सकता है कि उन्हें दोबारा इस्तेमाल न किया जाए.

--[no]interface_shared_objects

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

आउटपुट चुनना

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

--[no]build

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

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

--[no]build_tests_only

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

--[no]check_up_to_date

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

यह भी देखें --check_tests_up_to_date.

--[no]compile_one_dependency

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

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

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

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

  % bazel test --test_size_filters=small,medium //foo:all
और
  % bazel test --test_size_filters=-large,-enormous //foo:all

//foo में केवल छोटे और मीडियम टेस्ट की जांच करेगा.

डिफ़ॉल्ट रूप से, टेस्ट साइज़ फ़िल्टर लागू नहीं होता.

--test_timeout_filters=timeout[,timeout]*

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

डिफ़ॉल्ट तौर पर, टेस्ट का समय खत्म होने से जुड़े फ़िल्टर लागू नहीं किए जाते.

--test_tag_filters=tag[,tag]*

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

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

  % bazel test --test_tag_filters=performance,stress,-flaky //myproject:all

उन टारगेट की जांच करेगा जिन्हें performance या stress टैग से टैग किया गया है, लेकिन flaky टैग से नहीं.

डिफ़ॉल्ट रूप से, टेस्ट टैग को फ़िल्टर करने की सुविधा लागू नहीं होती. ध्यान रखें कि इस तरीके से भी टेस्ट के size और local टैग को फ़िल्टर किया जा सकता है.

--test_lang_filters=string[,string]*

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

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

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

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

//baz/... और foo_test को छोड़कर, बाकी सभी टारगेट की जांच करेगा.

--test_filter=filter-expression

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

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

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

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

--explain=logfile

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

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

--verbose_explanations

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

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

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

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

--profile=file

यह विकल्प, फ़ाइल नाम के आर्ग्युमेंट का इस्तेमाल करता है. इससे, बेज़ल किसी फ़ाइल में प्रोफ़ाइल बना सकता है. इसके बाद, bazel analyze-profile निर्देश का इस्तेमाल करके, डेटा का विश्लेषण किया जा सकता है या उसे पार्स किया जा सकता है. बिल्ड प्रोफ़ाइल से यह समझने में मदद मिल सकती है कि Bazel का build निर्देश, कहां काम कर रहा है.

--[no]show_loading_progress

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

--[no]show_progress

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

--show_progress_rate_limit=n

इस विकल्प से बेज़ल हर n सेकंड में ज़्यादा से ज़्यादा एक प्रगति मैसेज दिखाता है, जहां n एक वास्तविक संख्या होती है. इस विकल्प का डिफ़ॉल्ट मान 0.02 है. इसका मतलब है कि bazel हर 0.02 सेकंड के बाद एक मैसेज को सीमित कर देगा.

--show_result=n

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

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

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

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

--sandbox_debug

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

--subcommands (-s)

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

  >>>>> # //examples/cpp:hello-world [action 'Linking examples/cpp/hello-world']
  (cd /home/johndoe/.cache/bazel/_bazel_johndoe/4c084335afceb392cfbe7c31afee3a9f/bazel && \
    exec env - \
    /usr/bin/gcc -o bazel-out/local-fastbuild/bin/examples/cpp/hello-world -B/usr/bin/ -Wl,-z,relro,-z,now -no-canonical-prefixes -pass-exit-codes -Wl,-S -Wl,@bazel-out/local_linux-fastbuild/bin/examples/cpp/hello-world-2.params)

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

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

नीचे --verbose_failures भी देखें.

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

--verbose_failures

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

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

फ़ाइल फ़ोल्डर की स्थिति

Bazel की बनाई गई बाइनरी को "स्टैंप" करने के लिए, इन विकल्पों का इस्तेमाल करें: बाइनरी में ज़्यादा जानकारी एम्बेड करने के लिए, जैसे कि सोर्स कंट्रोल के बदलाव या फ़ाइल फ़ोल्डर से जुड़ी दूसरी जानकारी. इस तरीके का इस्तेमाल उन नियमों के साथ किया जा सकता है जो stamp एट्रिब्यूट के साथ काम करते हैं, जैसे कि genrule, cc_binary वगैरह.

--workspace_status_command=program

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

फ़्लैग का मान नेटिव प्रोग्राम का पाथ होना चाहिए. Linux/macOS पर यह एक्ज़ीक्यूटेबल हो सकता है. Windows पर यह नेटिव बाइनरी होना चाहिए, जो आम तौर पर ".exe", ".bat" या ".cmd" फ़ाइल होती है.

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

बेज़ल कुंजियों को दो बकेट में बांट देता है: "स्टेबल" और "वाॅटाइल". ("स्टेबल" और "वाेलाटाइल" के नाम थोड़े मुश्किल होते हैं, इसलिए इनके बारे में ज़्यादा न सोचें.)

इसके बाद, बैज़ल की-वैल्यू पेयर को दो फ़ाइलों में लिखता है:

  • bazel-out/stable-status.txt इसमें ऐसी सभी कुंजियां और वैल्यू शामिल होती हैं जिनमें कुंजी का नाम STABLE_ से शुरू होता है
  • bazel-out/volatile-status.txt इसमें बाकी कुंजियां और उनके मान शामिल होते हैं

यह अनुबंध है:

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

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

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

    Bazel हमेशा डेटा को बदलने की इन कुंजियों का इस्तेमाल करता है:

    • BUILD_TIMESTAMP: Unix Epoch के बाद से सेकंड में बिल्ड का समय (System.currentTimeMillis() के मान को हज़ार से भाग दिया जाता है)

Linux/macOS पर, --workspace_status_command=/bin/true की मदद से फ़ाइल फ़ोल्डर की स्थिति को वापस पाना बंद किया जा सकता है, क्योंकि true कुछ भी नहीं करता है, शून्य से बाहर निकल जाता है, और कोई आउटपुट नहीं देता है. Windows पर, आप एमएसवाईएस के 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 से पास करें. साथ ही, स्टेबल स्टेटस फ़ाइल में Sटेबल लाइनें शामिल होंगी और डेटा बार-बार अपडेट होने वाली स्टेटस फ़ाइल में बाकी की लाइनें भी शामिल होंगी.

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

वे प्लैटफ़ॉर्म जो एक्ज़ीक्यूशन प्लैटफ़ॉर्म के तौर पर काम करते हैं. प्लैटफ़ॉर्म सटीक टारगेट या टारगेट पैटर्न के रूप में बताए जा सकते हैं. WORKSPACE की फ़ाइल में बताए गए इन प्लैटफ़ॉर्म को record_execution_platforms() से पहले स्वीकार किया जाएगा.

--extra_toolchains=labels

टूलचेन समाधान के दौरान विचार किए जाने वाले टूलचेन नियम. टूल चेन, सटीक टारगेट या टारगेट पैटर्न के तौर पर दिए जा सकते हैं. WORKSPACE की फ़ाइल में इनका एलान करने से पहले, इन टूलचेन पर विचार किया जाएगा. इसके लिए, रजिस्टर_टूलचेन() का इस्तेमाल किया जाएगा.

--toolchain_resolution_debug=regex

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

अन्य सूचनाएं

--flag_alias=alias_name=target_path

सुविधा फ़्लैग का इस्तेमाल, Starlark की लंबे बिल्ड सेटिंग को छोटे नाम देने के लिए किया जाता है. ज़्यादा जानकारी के लिए, Starlark के कॉन्फ़िगरेशन देखें.

जनरेट किए गए सुविधा सिमलिंक के प्रीफ़िक्स को बदलता है. सिमलिंक प्रीफ़िक्स की डिफ़ॉल्ट वैल्यू bazel- है. इससे सिमलिंक bazel-bin, bazel-testlogs, और bazel-genfiles बन जाएंगे.

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

इस विकल्प की कुछ सामान्य वैल्यू:

  • सिमलिंक बनाने पर रोक लगाएं: --symlink_prefix=/ की वजह से, बेज़ल कोई भी सिमलिंक नहीं बनाएगा या उन्हें अपडेट नहीं करेगा. इनमें bazel-out और bazel-<workspace> सिमलिंक भी शामिल हैं. इस विकल्प का इस्तेमाल करके, सिमलिंक बनाने की प्रोसेस को पूरी तरह से रोक दें.

  • अव्यवस्थितता कम करें: --symlink_prefix=.bazel/, की वजह से बेज़ल, छिपे हुए डायरेक्ट्री .bazel में bin (उदाहरण) नाम के सिमलिंक बना देगा.

--platform_suffix=string

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

--default_visibility=(private|public)

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

--starlark_cpu_profile=_file_

इस फ़्लैग का मान किसी फ़ाइल के नाम पर होता है. इस वजह से बज़ेल, Starstark की सभी थ्रेड में सीपीयू के इस्तेमाल से जुड़े आंकड़े इकट्ठा करते हैं और नाम वाली फ़ाइल में pprof फ़ॉर्मैट में प्रोफ़ाइल लिखते हैं.

Starlark के ऐसे फ़ंक्शन की पहचान करने के लिए इस विकल्प का इस्तेमाल करें जो बहुत ज़्यादा कंप्यूटेशन की वजह से, लोड होने और विश्लेषण करने की प्रोसेस को धीमा कर देते हैं. उदाहरण के लिए:

$ bazel build --nobuild --starlark_cpu_profile=/tmp/pprof.gz my/project/...
$ pprof /tmp/pprof.gz
(pprof) top
Type: CPU
Time: Feb 6, 2020 at 12:06pm (PST)
Duration: 5.26s, Total samples = 3.34s (63.55%)
Showing nodes accounting for 3.34s, 100% of 3.34s total
      flat  flat%   sum%        cum   cum%
     1.86s 55.69% 55.69%      1.86s 55.69%  sort_source_files
     1.02s 30.54% 86.23%      1.02s 30.54%  expand_all_combinations
     0.44s 13.17% 99.40%      0.44s 13.17%  range
     0.02s   0.6%   100%      3.34s   100%  sorted
         0     0%   100%      1.38s 41.32%  my/project/main/BUILD
         0     0%   100%      1.96s 58.68%  my/project/library.bzl
         0     0%   100%      3.34s   100%  main

एक ही डेटा के अलग-अलग व्यू के लिए, pprof निर्देश svg, web, और list आज़माएं.

रिलीज़ के लिए Bazel का इस्तेमाल करना

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

ज़रूरी विकल्प

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

ये विकल्प भी अहम हैं:

  • --package_path
  • --symlink_prefix: एक से ज़्यादा कॉन्फ़िगरेशन के लिए बिल्ड मैनेज करने के लिए, "64 बिट" बनाम "32 बिट" जैसे अलग-अलग आइडेंटिफ़ायर में अंतर करना आसान होता है. यह विकल्प, bazel-bin वगैरह वाले सिमलिंक को अलग करता है.

चल रहे टेस्ट

बेज़ल के साथ टेस्ट बनाने और चलाने के लिए, bazel test के बाद टेस्ट टारगेट का नाम लिखें.

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

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

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

अगर यह विकल्प 'अपने-आप' (डिफ़ॉल्ट) पर सेट है, तो नीचे दिया गया कोई भी शर्त लागू होने पर ही बैजल फिर से टेस्ट करेगा:

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

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

अगर यह 'हां' है, तो कैश मेमोरी में सेव किया गया डेटा, अपने-आप {0/} जैसा ही होगा. हालांकि, इसमें कैश मेमोरी में सेव किए गए पेज की जांच में गड़बड़ी हो सकती है और टेस्ट को --runs_per_test से जांचा जा सकता है.

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

--check_tests_up_to_date

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

यह विकल्प [--check_up_to_date](#check-up-to-date) के व्यवहार के बारे में भी बताता है.

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

--test_verbose_timeout_warnings

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

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

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

--[no]test_keep_going

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

--flaky_test_attempts=attempts

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

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

--runs_per_test=[regex@]number

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

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

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

अगर एक ही नंबर दिया गया है, तो सभी टेस्ट कई बार किए जाएंगे. इसके अलावा, रेगुलर एक्सप्रेशन सिंटैक्स regex@number का इस्तेमाल करके एक रेगुलर एक्सप्रेशन दिया जा सकता है. इससे --runs_per_test का असर उन टारगेट पर लागू होता है जो रेगुलर एक्सप्रेशन से मेल खाते हैं (--runs_per_test=^//pizza:.*@4 सभी जांच //pizza/ से कम बार करता है). --runs_per_test के इस फ़ॉर्म को एक से ज़्यादा बार बताया जा सकता है.

--[no]runs_per_test_detects_flakes

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

--test_summary=output_style

इससे पता चलता है कि जांच के नतीजे की खास जानकारी कैसे दिखाई जानी चाहिए.

  • short अगर जांच में कोई गड़बड़ी होती है, तो वह जांच के नतीजे वाली फ़ाइल के नाम के साथ-साथ, हर जांच के नतीजों को प्रिंट करता है. यह डिफ़ॉल्ट मान है.
  • terse को short पसंद है, लेकिन इससे कम भी: सिर्फ़ ऐसे टेस्ट की जानकारी प्रिंट करें जो पास नहीं हुई हैं.
  • detailed हर जांच केस को अलग-अलग करता है, न कि सिर्फ़ हर जांच केस को. टेस्ट आउटपुट फ़ाइलों के नाम हटा दिए गए हैं.
  • none, टेस्ट की खास जानकारी प्रिंट नहीं करता.

--test_output=output_style

इससे पता चलता है कि टेस्ट आउटपुट को कैसे दिखाना चाहिए:

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

--java_debug

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

--[no]verbose_test_summary

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

--test_tmpdir=path

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

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

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

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

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

--test_arg=arg

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

--test_env=variable=_value_ या --test_env=variable

हर वैरिएबल के लिए अतिरिक्त वैरिएबल तय करता है, जिसे टेस्ट एनवायरमेंट में इंजेक्ट किया जाना चाहिए. अगर value तय नहीं किया गया है, तो यह bazel test कमांड शुरू करने के लिए इस्तेमाल किए गए शेल एनवायरमेंट से इनहेरिट किया जाएगा.

System.getenv("var") (Java), getenv("var") (C या C++) का इस्तेमाल करके, एनवायरमेंट को टेस्ट से ऐक्सेस किया जा सकता है

--run_under=command-prefix

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

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

कुछ चेतावनियां लागू होती हैं:

  • परीक्षण करने के लिए उपयोग किया जाने वाला PATH आपके परिवेश में PATH से अलग हो सकता है, इसलिए आपको --run_under कमांड के लिए निरपेक्ष पथ (command-prefix में पहला शब्द) का उपयोग करना पड़ सकता है.
  • stdin कनेक्ट नहीं है, इसलिए --run_under इंटरैक्टिव कमांड के लिए इस्तेमाल नहीं किया जा सकता.

उदाहरण:

        --run_under=/usr/bin/strace
        --run_under='/usr/bin/strace -c'
        --run_under=/usr/bin/valgrind
        --run_under='/usr/bin/valgrind --quiet --num-callers=20'

टेस्ट चुनना

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

bazel test के लिए अन्य विकल्प

सिंटैक्स और बचे हुए विकल्प, बिल्कुल bazel build जैसे हैं.

एक्ज़ीक्यूटेबल चलाना

bazel run निर्देश bazel build जैसा ही है. हालांकि, इसका इस्तेमाल एक टारगेट बनाने और उसे चलाने के लिए किया जाता है. यह एक सामान्य सेशन है:

  % bazel run java/myapp:myapp -- --arg1 --arg2
  Welcome to Bazel
  INFO: Loading package: java/myapp
  INFO: Loading package: foo/bar
  INFO: Loading complete.  Analyzing...
  INFO: Found 1 target...
  ...
  Target //java/myapp:myapp up-to-date:
    bazel-bin/java/myapp:myapp
  INFO: Elapsed time: 0.638s, Critical Path: 0.34s

  INFO: Running command line: bazel-bin/java/myapp:myapp --arg1 --arg2
  Hello there
  $EXEC_ROOT/java/myapp/myapp
  --arg1
  --arg2

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

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

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

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

  • BUILD_WORKSPACE_DIRECTORY: उस फ़ाइल फ़ोल्डर का रूट जहां बिल्ड चलाया गया था.
  • BUILD_WORKING_DIRECTORY: वह मौजूदा वर्किंग डायरेक्ट्री जहां Bazel से चलाया गया था.

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

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

--run_under=command-prefix

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

Bazel से लॉग आउटपुट को फ़िल्टर करना

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

उदाहरण के लिए: bazel run --ui_event_filters=-info,-stdout,-stderr --noshow_progress //java/myapp:myapp

टेस्ट चलाना

bazel run में टेस्ट बाइनरी भी लागू की जा सकती हैं. इस जांच का असर, टेस्ट लिखने में बताए गए माहौल के करीब होता है. ध्यान दें कि इस तरीके से टेस्ट करने पर, --test_arg के अलावा, किसी भी --test_* आर्ग्युमेंट का असर नहीं होता.

बिल्ड आउटपुट की सफ़ाई

clean निर्देश

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

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

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

  % bazel clean --expunge

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

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

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

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

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

क्वेरी की भाषा ग्राफ़ पर बीजगणितीय संचालन के विचारों पर आधारित होती है; इसे

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

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

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

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

अलग-अलग तरह के निर्देश और विकल्प

help

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

--[no]long (-l)

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

shutdown

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

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

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

info

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

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

कॉन्फ़िगरेशन-स्वतंत्र डेटा

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

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

  • execution_root: आउटपुट_बेस के तहत एक्ज़ीक्यूशन रूट डायरेक्ट्री का पूरा पाथ. यह डायरेक्ट्री उन सभी फ़ाइलों का रूट है जो बिल्ड के दौरान एक्ज़ीक्यूट किए जा सकने वाले कमांड को ऐक्सेस कर सकती हैं. साथ ही, यह डायरेक्ट्री उन कमांड के लिए काम करने वाली डायरेक्ट्री भी होती है. अगर फ़ाइल फ़ोल्डर की डायरेक्ट्री में लिखा जा सकने वाला लिंक है, तो उस लिंक को 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: यह कई जेवीएम हीप साइज़ पैरामीटर की रिपोर्ट करता है. सम्मान के साथ: इस समय मेमोरी का इस्तेमाल किया जाता है. फ़िलहाल, मेमोरी को सिस्टम से जेवीएम के लिए उपलब्ध होने की गारंटी दी जाती है.

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

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

उदाहरण: Bazel सर्वर का प्रोसेस आईडी.

% bazel info server_pid
1285

कॉन्फ़िगरेशन के हिसाब से डेटा

इस डेटा पर, bazel info को भेजे गए कॉन्फ़िगरेशन के विकल्पों का असर पड़ सकता है. जैसे, --cpu, --compilation_mode वगैरह. info निर्देश, डिपेंडेंसी को कंट्रोल करने वाले सभी विकल्प स्वीकार करता है. ऐसा इसलिए होता है, क्योंकि इनमें से कुछ कॉन्फ़िगरेशन, बिल्ड की आउटपुट डायरेक्ट्री की जगह, कंपाइलर के विकल्प वगैरह को तय करते हैं.

  • bazel-bin, bazel-testlogs, bazel-genfiles: bazel-* डायरेक्ट्री का पूरा पाथ रिपोर्ट करता है. इस डायरेक्ट्री में, बिल्ड से जनरेट होने वाले प्रोग्राम की जगह की जानकारी दी जाती है. आम तौर पर, हमेशा नहीं, जैसा कि एक कामयाब बिल्ड के बाद, बेस फ़ाइल फ़ोल्डर की डायरेक्ट्री में बनाया गया bazel-* सिमलिंक होता है. हालांकि, अगर फ़ाइल फ़ोल्डर की डायरेक्ट्री सिर्फ़ पढ़ी जा सकती है, तो कोई भी bazel-* सिमलिंक नहीं बनाए जा सकते. जो स्क्रिप्ट, bazel info के ज़रिए रिपोर्ट की गई वैल्यू का इस्तेमाल करती हैं उनके लिए, सिमलिंक के मौजूद होने का अनुमान न लगाया जाए.
  • पूरा "बनाएं" एनवायरमेंट. अगर --show_make_env फ़्लैग के बारे में बताया गया है, तो मौजूदा कॉन्फ़िगरेशन के "बनाएं" एनवायरमेंट में मौजूद सभी वैरिएबल भी दिखाए जाते हैं (जैसे कि CC, GLIBC_VERSION वगैरह). इन वैरिएबल को BUILD फ़ाइलों में, $(CC) या varref("CC") सिंटैक्स का इस्तेमाल करके ऐक्सेस किया जाता है.

उदाहरण: मौजूदा कॉन्फ़िगरेशन के लिए C++ कंपाइलर. यह "बनाएं" एनवायरमेंट में $(CC) वैरिएबल है, इसलिए --show_make_env फ़्लैग की ज़रूरत है.

  % bazel info --show_make_env -c opt COMPILATION_MODE
  opt

उदाहरण: मौजूदा कॉन्फ़िगरेशन के लिए bazel-bin आउटपुट डायरेक्ट्री. इस बात की गारंटी है कि कुछ मामलों में bazel-bin सिमलिंक नहीं बनाया जा सकता, जैसे कि रीड-ओनली डायरेक्ट्री से साइन किया जा सकता है.

% bazel info --cpu=piii bazel-bin
/var/tmp/_bazel_johndoe/fbd0e8a34f61ce5d491e3da69d959fe6/execroot/io_bazel/bazel-out/piii-opt/bin
% bazel info --cpu=k8 bazel-bin
/var/tmp/_bazel_johndoe/fbd0e8a34f61ce5d491e3da69d959fe6/execroot/io_bazel/bazel-out/k8-opt/bin

version और --version

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

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

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

mobile-install

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

ज़्यादा जानकारी के लिए, bazel मोबाइल-इंस्टॉल देखें.

ये विकल्प काम करते हैं:

--incremental

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

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

--split_apks

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

--start_app

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

--debug_app

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

--start=_start_type_

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

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

--adb=path

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

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

--adb_arg=serial

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

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

adb को इस तारीख से लागू किया जाएगा

adb -s deadbeef install ...

--incremental_install_verbosity=number

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

dump

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

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

ये विकल्प काम करते हैं:

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

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

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

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

third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar में Bazel में Java-एजेंट की जांच की जाती है, इसलिए Bazel डेटा स्टोर करने की जगह को सेव करने के लिए, $BAZEL में बदलाव करें.

हर विकल्प के लिए Bazel को ये विकल्प पास करने का ध्यान रखें, नहीं तो सर्वर फिर से चालू हो जाएगा.

उदाहरण:

    % bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar \
    --host_jvm_args=-DRULE_MEMORY_TRACKER=1 \
    build --nobuild <targets>

    # Dump rules
    % bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar \
    --host_jvm_args=-DRULE_MEMORY_TRACKER=1 \
    dump --rules

    # Dump Starlark heap and analyze it with pprof
    % bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar \
    --host_jvm_args=-DRULE_MEMORY_TRACKER=1 \
    dump --skylark_memory=$HOME/prof.gz
    % pprof -flame $HOME/prof.gz

analyze-profile

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

ये विकल्प काम करते हैं:

  • --dump इकट्ठा किए गए सारे डेटा को इंसान के पढ़ने लायक फ़ॉर्मैट में दिखाता है. हालांकि, फ़िलहाल, यह दूसरे फ़ॉर्मैट में काम नहीं करता.

फ़ॉर्मैट की जानकारी और इस्तेमाल के बारे में मदद पाने के लिए, प्रोफ़ाइलिंग करके परफ़ॉर्मेंस की समस्या हल करना देखें.

canonicalize-flags

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

--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 वाले सिंटैक्स का इस्तेमाल करके बताया जाना चाहिए. इसके अलावा, इन विकल्पों को बेज़ल कमांड के नाम से पहले दिखाना होगा. इन्हें .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 कमांड एक साथ चलते हैं (शेल &amp; ऑपरेटर के कारण), जिनमें से हर एक अलग Bazel सर्वर इंस्टेंस का इस्तेमाल करता है (अलग-अलग आउटपुट बेस के कारण). इसके उलट, अगर डिफ़ॉल्ट आउटपुट बेस का इस्तेमाल दोनों कमांड में किया जाता है, तो दोनों अनुरोध एक ही सर्वर पर भेजे जाएंगे, जो क्रम से उन्हें हैंडल करेंगे: पहले //foo बनाना, और उसके बाद //bar का इंक्रीमेंटल बिल्ड.

--output_user_root=dir

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

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

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

अगर आपके फ़ाइल सिस्टम के लेआउट में जगह की जानकारी बेहतर है, तो --output_user_root

--server_javabase=dir

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

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

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

इस फ़्लैग का नाम पहले --host_javabase रखा गया था. इसे कभी-कभी 'बाईं ओर मौजूद' --host_javabase कहा जाता था. हालांकि, इसे फ़्लैग --host_javabase के नाम से जोड़ा गया था, ताकि भ्रम की स्थिति न पैदा हो. कभी-कभी इसे दाईं ओर मौजूद फ़्लैग भी कहा जाता है.

--host_jvm_args=string

Java वर्चुअल मशीन में भेजे जाने वाले स्टार्टअप का विकल्प सेट करता है, जिसमें Bazel चलता है. इसका इस्तेमाल स्टैक साइज़ को सेट करने के लिए किया जा सकता है, उदाहरण के लिए:

  % bazel --host_jvm_args="-Xss256K" build //foo

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

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

--host_jvm_debug

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

--autodetect_server_javabase

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

--batch

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

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

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

--max_idle_secs=n

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

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

--[no]shutdown_on_low_sys_mem

अगर --max_idle_secs को सेट किया गया है और कुछ समय के लिए बिल्ड सर्वर कुछ समय से इस्तेमाल में नहीं है, तो सर्वर को बंद कर दें. ऐसा तब करें, जब सिस्टम की मेमोरी कम हो. सिर्फ़ Linux.

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

--[no]block_for_lock

अगर यह सुविधा चालू है, तो आगे बढ़ने से पहले, Bazel, सर्वर लॉक की सेटिंग के पूरा होने तक इंतज़ार करेगा. अगर नीति को 'बंद है' पर सेट नहीं किया जाता है, तो बैज को गलती से हटा दिया जाएगा. ऐसा तब होगा, जब तुरंत लॉक को हासिल करना शुरू न हो जाए.

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

--io_nice_level=n

बेहतर कोशिश के लिए, IO शेड्यूल के लिए 0 से 7 के बीच कोई लेवल सेट करें. 0 उच्चतम प्राथमिकता है, 7 सबसे कम है. हो सकता है कि शेड्यूल करने वाले व्यक्ति को प्राथमिकता 4 में ही शामिल किया जाए. नेगेटिव वैल्यू को नज़रअंदाज़ कर दिया जाता है.

--batch_cpu_scheduling

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

अन्य चीज़ें

--[no]announce_rc

इससे यह तय होता है कि Bazelrc फ़ाइल में शुरू होने पर, Bazel ने निर्देश दिए हैं या नहीं. (स्टार्टअप विकल्पों की शर्त के बिना घोषणा की गई है.)

--color (yes|no|auto)

यह विकल्प तय करता है कि Bazel स्क्रीन पर अपना आउटपुट हाइलाइट करने के लिए रंगों का इस्तेमाल करेगा या नहीं.

अगर यह विकल्प yes पर सेट है, तो कलर आउटपुट चालू होता है. अगर यह विकल्प auto पर सेट है, तो Bazel कलर आउटपुट का इस्तेमाल सिर्फ़ तब करेगा, जब आउटपुट टर्मिनल पर भेजा जा रहा हो और TERM एनवायरमेंट वैरिएबल dumb, emacs या xterm-mono के अलावा किसी दूसरी वैल्यू पर सेट हो. अगर यह विकल्प no पर सेट है, तो कलर आउटपुट बंद कर दिया जाता है, चाहे आउटपुट टर्मिनल पर जा रहा हो या नहीं. भले ही, TERM एनवायरमेंट वैरिएबल की सेटिंग कुछ भी हो.

--config=name

आरसी फ़ाइलों से अतिरिक्त कॉन्फ़िगरेशन सेक्शन चुनता है; मौजूदा command के लिए, अगर ऐसा सेक्शन मौजूद है, तो यह command:name से विकल्प भी लेता है. कॉन्फ़िगरेशन के कई सेक्शन से फ़्लैग जोड़ने के लिए, उन्हें कई बार बताया जा सकता है. एक्सपैंशन दूसरी परिभाषाओं के बारे में जानकारी दे सकते हैं (उदाहरण के लिए, एक्सपैंशन को कई चेन में बांटा जा सकता है).

--curses (yes|no|auto)

यह विकल्प तय करता है कि Bazel अपने स्क्रीन आउटपुट में कर्सर कंट्रोल का इस्तेमाल करेगा या नहीं. इससे, कम स्क्रोल करने वाला डेटा मिलता है. साथ ही, Bazel से इकट्ठा किया गया आउटपुट, छोटा और पढ़ने में आसान होता है. यह --color के साथ अच्छे से काम करता है.

अगर यह विकल्प yes पर सेट है, तो कर्सर के कंट्रोल इस्तेमाल करने की सुविधा चालू होती है. अगर यह विकल्प no पर सेट है, तो कर्सर कंट्रोल का इस्तेमाल नहीं किया जा सकता. अगर इस विकल्प को auto पर सेट किया जाता है, तो --color=auto के लिए कर्सर कंट्रोल का इस्तेमाल किन स्थितियों में किया जा सकेगा.

--[no]show_timestamps

अगर इस बारे में बताया जाता है, तो हर मैसेज में एक टाइमस्टैंप जोड़ा जाता है. इस मैसेज में, Bazel से जनरेट हुए मैसेज को दिखाने का समय बताया जाता है.