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

समस्या की शिकायत करेंopen_in_new सोर्स देखेंopen_in_new

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

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

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

विकल्प

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

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

पैकेज की जगह

--package_path

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

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

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

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

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

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

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

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

टूल फ़्लैग

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

--copt=cc-option

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

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

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

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

--host_copt=cc-option

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

--host_conlyopt=cc-option

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

--host_cxxopt=cc-option

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

--host_linkopt=linker-option

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

--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 की तरह, यह सिर्फ़ लिंक करने पर लागू होता है, कंपाइलेशन पर नहीं. इसलिए, कंपाइलर के ऐसे विकल्प पास किए जा सकते हैं जो लिंक के समय ही काम के होते हैं. जैसे, -lssp या -Wl,--wrap,abort) का इस्तेमाल करके, --linkopt. उदाहरण के लिए:

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

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

--strip (always|never|sometimes)

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

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

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

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

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

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

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

--fdo_optimize=profile-zip

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

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

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

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

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

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

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

--tool_java_runtime_version=version

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

--jvmopt=jvm-option

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

  % bazel build --jvmopt="-server -Xms256m" java/com/example/common/foo:all

सभी Java बाइनरी लॉन्च करने के लिए, सर्वर सर्वर वीएम का इस्तेमाल करेगा. साथ ही, वीएम के लिए स्टार्टअप हीप का साइज़ 256 एमबी पर सेट करेगा.

--javacopt=javac-option

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

  % bazel build --javacopt="-g:source,lines" //myprojects:prog

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

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

  -source 8 -target 8 -encoding UTF-8

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

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

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

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

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

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

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

• 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 डालने के लिए, action_listener नियम से मिली जानकारी का इस्तेमाल करने का निर्देश मिलता है.label

--[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 के लिए शेड्यूल करने की प्रोसेस को सीमित किया जाएगा. यह सिर्फ़ उन कार्रवाइयों पर लागू होगा जिनके मालिक के लेबल में '/बार/' शामिल होगा:

% 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++ नियमों पर असर नहीं पड़ता है. उदाहरण के लिए, अगर android_binary नियम और cc_binary नियम के ट्रांज़िटिव deps में cc_library दिखता है, तो cc_library को कम से कम दो बार बनाया जाएगा: android_binary नियम के लिए --fat_apk_cpu के साथ-साथ, हर बार सीपीयू की वैल्यू और cc_binary नियम के लिए --cpu की जानकारी वाले सीपीयू के लिए.

डिफ़ॉल्ट वैल्यू armeabi-v7a होती है.

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

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

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

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

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

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

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

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

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

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

--dynamic_mode=mode

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

मोड:

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

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

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

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

--force_ignore_dash_static

अगर यह फ़्लैग सेट है, तो cc_* BUILD फ़ाइलों के नियम में -static के विकल्पों को अनदेखा कर दिया जाता है. इसका मकसद सिर्फ़ 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

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

--android_crosstool_top=label

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

--compiler=version

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

--android_sdk=label

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

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

--java_toolchain=label

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

--host_java_toolchain=label

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

--javabase=(label)

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

--host_javabase=label

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

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

स्क्रिप्ट रन करने की रणनीति

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

--spawn_strategy=strategy

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

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

--strategy mnemonic=strategy

इस विकल्प से यह तय किया जाता है कि निर्देशों को कहां और कैसे लागू करना है. यह --spawn_strategi (और --genrule_strategi) को हर सीज़न के हिसाब से लागू करता है. इन रणनीतियों और इनके असर के बारे में --spawn_stratege देखें.

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

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

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

• उदाहरण: अगर --strategy_regexp=//foo.*\\.cc,-//foo/bar=local का ब्यौरा //foo.*.cc से मेल खाता है, लेकिन //foo/bar से नहीं, तो local रणनीति का इस्तेमाल करके कार्रवाइयां करें.
• उदाहरण: --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 (-j)

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

--progress_report_interval=n

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

--[no]build_runfile_links

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

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

--[no]check_up_to_date

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

यह भी देखें --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, टेस्ट टारगेट के लिए --build_tag_filters को नज़रअंदाज़ कर देता है, जो इस फ़िल्टर से मैच नहीं होने पर भी बनाए जाते हैं और चलते हैं. उन्हें बनाने से बचने के लिए, --test_tag_filters का इस्तेमाल करके या साफ़ तौर पर उन्हें छोड़कर, टेस्ट टारगेट को फ़िल्टर करें.

--test_size_filters=size[,size]*

अगर बताया गया है, तो Baze--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]*

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

डिफ़ॉल्ट रूप से, टेस्ट के टाइम आउट फ़िल्टर करने की सुविधा लागू नहीं होती.

--test_tag_filters=tag[,tag]*

अगर (अगर इनमें से कोई भी तय है) बज़ल, टेस्ट करेगा (या तय किया गया होने पर, --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 को छोड़कर, //baz/... में सभी टारगेट की जांच करेगा.bar_test

--test_filter=filter-expression

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

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

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

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

--explain=logfile

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

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

--verbose_explanations

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

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

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

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

--profile=file

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

--[no]show_loading_progress

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

--[no]show_progress

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

--show_progress_rate_limit=n

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

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

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

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

  Bazel, हमेशा इन स्थिर बटन का इस्तेमाल करता है:

  • BUILD_EMBED_LABEL: --embed_label की वैल्यू
  • BUILD_HOST: उस होस्ट मशीन का नाम जिस पर Bazel चल रहा है
  • BUILD_USER: उस उपयोगकर्ता का नाम जिसका नाम Bazel है

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

  Bazel हमेशा, डेटा बार-बार अपडेट करने वाली इन कुंजियों का आउटपुट देता है:

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

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 के साथ पास करें. साथ ही, स्टेटस की फ़ाइल में STABLE लाइनें और अस्थिर वैल्यू की फ़ाइल में बाकी लाइनें शामिल होंगी.

--[no]stamp

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

stamp एट्रिब्यूट का इस्तेमाल करके, हर नियम के हिसाब से स्टैंप को साफ़ तौर पर चालू या बंद किया जा सकता है. ज़्यादा जानकारी के लिए, बिल्ड एनसाइक्लोपीडिया देखें. जब कोई नियम stamp = -1 (*_binary नियमों के लिए डिफ़ॉल्ट) सेट करता है, तो इस विकल्प से यह तय होता है कि स्टैंपिंग चालू है या नहीं.

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

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

प्लैटफ़ॉर्म

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

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

--platforms=labels

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

--host_platform=label

प्लैटफ़ॉर्म सिस्टम का लेबल, जो होस्ट सिस्टम के बारे में बताता है.

--extra_execution_platforms=labels

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

--extra_toolchains=labels

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

--toolchain_resolution_debug=regex

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

अन्य सूचनाएं

--flag_alias=alias_name=target_path

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

--symlink_prefix=string

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

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

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

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

• ग़ैर-ज़रूरी चीज़ें कम करें: --symlink_prefix=.bazel/ की वजह से, Bazel एक छिपी हुई डायरेक्ट्री .bazel में bin (जैसे कि) नाम के सिमलिंक बना देगा.

--platform_suffix=string

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

--default_visibility=(private|public)

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

--starlark_cpu_profile=_file_

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

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

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

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

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

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

जांच की जा रही है

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

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

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

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

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

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

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

अगर 'हां', कैश मेमोरी में सेव किया गया तरीका अपने-आप वैसा ही होगा जब यह टेस्ट के काम न कर पाने की जांच को कैश मेमोरी में सेव करता है और जांच --runs_per_test से होती है.

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

--check_tests_up_to_date

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

यह विकल्प [--check_up_to_date](#check-up-to-date) व्यवहार को भी दिखाता है.

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

--test_verbose_timeout_warnings

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

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

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

--[no]test_keep_going

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

--flaky_test_attempts=attempts

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

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

--runs_per_test=[regex@]number

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

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

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

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

--[no]runs_per_test_detects_flakes

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

--test_summary=output_style

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

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

--test_output=output_style

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

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

--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 run के लिए विकल्प

--run_under=command-prefix

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

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

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

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

टेस्ट चलाना

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

बिल्ड आउटपुट को हटाना

clean निर्देश

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

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

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

  % bazel clean --expunge

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

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

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

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

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

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

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

क्वेरी टूल, कई कमांड-लाइन विकल्प स्वीकार करता है. --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 कमांड से आपको ऑनलाइन मदद मिलती है. डिफ़ॉल्ट रूप से, यह उपलब्ध निर्देशों की खास जानकारी और मदद से जुड़े विषयों को दिखाता है, जैसा कि Bels के साथ बनाना में दिखाया गया है. आर्ग्युमेंट तय करने से किसी खास विषय के बारे में पूरी मदद मिलती है. ज़्यादातर विषय बेज़ल कमांड होते हैं, जैसे कि build या query. हालांकि, सहायता से जुड़े कुछ ऐसे विषय भी होते हैं जो निर्देशों के मुताबिक नहीं होते.

--[no]long (-l)

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

shutdown

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

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

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

info

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

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

कॉन्फ़िगरेशन पर निर्भर डेटा

• release: अगर इस रिलीज़ का रिलीज़ नहीं किया गया है, तो इस Baze Insance का रिलीज़ लेबल या "डेवलपमेंट वर्शन".
• workspace मूल फ़ाइल फ़ोल्डर की डायरेक्ट्री का पूरा पाथ.

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

• output_base Bazel, अपनी पूरी स्क्रैच सूची बनाता है और इस डायरेक्ट्री के नीचे आउटपुट बनाता है.

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

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

• server_pid: Bazel सर्वर प्रोसेस का प्रोसेस आईडी.

• server_log: Bazel सर्वर की डीबग लॉग फ़ाइल का निरपेक्ष पाथ. इस फ़ाइल में Bazel सर्वर के चालू रहने के दौरान, सभी निर्देशों के लिए डीबग करने की जानकारी दी गई है. यह फ़ाइल, Bazel डेवलपर और जानकार उपयोगकर्ताओं के इस्तेमाल के लिए है.

• command_log, कमांड लॉग फ़ाइल का ऐब्सलूट पाथ: इसमें सबसे हाल के Bazzel कमांड का इंटरलेस्ड stdout और stderr स्ट्रीम शामिल है. ध्यान दें कि bazel info चलाने से इस फ़ाइल का कॉन्टेंट बदल जाएगा. ऐसा इसलिए, क्योंकि यह बाद में सबसे नया Bazel कमांड बन जाएगा. हालांकि, कमांड लॉग फ़ाइल की जगह तब तक नहीं बदलेगी, जब तक आप --output_base या --output_user_root के विकल्पों की सेटिंग में बदलाव नहीं करते.

• used-heap-size, committed-heap-size, max-heap-size: अलग-अलग JVM हीप साइज़ के पैरामीटर की रिपोर्ट. उदाहरण के लिए: मौजूदा समय में इस्तेमाल की जाने वाली मेमोरी, सिस्टम से जेवीएम के लिए उपलब्ध होने की गारंटी होती है हो सकता है कि यह सबसे ज़्यादा हो.

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

• 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: अगर इस रिलीज़ का रिलीज़ नहीं किया गया है, तो इस Baze Insance का रिलीज़ लेबल या "डेवलपमेंट वर्शन". गड़बड़ी की शिकायत करते समय बहुत मदद मिलती है.

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

mobile-install

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

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

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

--incremental

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

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

--split_apks

डिवाइस पर ऐप्लिकेशन इंस्टॉल और अपडेट करने के लिए, स्प्लिट APK का इस्तेमाल करना है या नहीं. यह सुविधा, 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

इंक्रीमेंटल इंस्टॉल के लिए कितने शब्दों में जानकारी दी जाए. कंसोल में प्रिंट किए जाने वाले डीबग लॉगिंग के लिए एक पर सेट करें.

dump

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

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

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

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

मेमोरी को ट्रैक करने वाले ऐप्लिकेशन

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

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

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

--output_user_root=dir

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

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

Android SDK के इंस्टॉल की असल जगह को कैलकुलेट करने के लिए, --output_user_root के साथ-साथ एम्बेड की गई बैज़ेल की MD5 पहचान की जाती है.

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

--server_javabase=dir

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

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

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

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

--host_jvm_args=string

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

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

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

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

--host_jvm_debug

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

--autodetect_server_javabase

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

--batch

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

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

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

--max_idle_secs=n

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

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

--io_nice_level=n

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

--batch_cpu_scheduling

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

अन्य विकल्प

--[no]announce_rc

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

--color (yes|no|auto)

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

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

--config=name

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

--curses (yes|no|auto)

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

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

--[no]show_timestamps

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