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

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

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

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

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

विकल्प

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

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

पैकेज की जगह

--package_path

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

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

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

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

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

1. अगर पहला वर्ण / है, तो पाथ की वैल्यू ऐब्सलूट है.
2. अगर पाथ %workspace% से शुरू होता है, तो पाथ को क्लोज़िंग बेज़ेल डायरेक्ट्री के हिसाब से लिया जाता है. उदाहरण के लिए, अगर आपकी वर्क डायरेक्ट्री /home/bob/clients/bob_client/bazel/foo है, तो पैकेज-पाथ में मौजूद %workspace% स्ट्रिंग को /home/bob/clients/bob_client/bazel में बढ़ाया जाएगा.
3. वर्किंग डायरेक्ट्री से जुड़ी किसी भी अन्य चीज़ को लिया जाता है. आम तौर पर, आपका इरादा ऐसा नहीं होता. हालांकि, अगर आप बैजल वर्कस्पेस के नीचे मौजूद डायरेक्ट्री से Bazel का इस्तेमाल करते हैं, तो यह अनचाहे तरीके से काम कर सकता है. उदाहरण के लिए, अगर पैकेज-पाथ एलिमेंट . का इस्तेमाल किया जाता है और फिर इसे /home/bob/clients/bob_client/bazel/foo डायरेक्ट्री में cd किया जाता है, तो पैकेज को /home/bob/clients/bob_client/bazel/foo डायरेक्ट्री से रिज़ॉल्व कर दिया जाएगा.

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

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

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

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

--deleted_packages

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

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

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

--[no]check_visibility

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

--output_filter=regex

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

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

`--output_filter='^//(first/project|second/project):'`	तय किए गए पैकेज के लिए आउटपुट दिखाएं.
`--output_filter='^//((?!(first/bad_project|second/bad_project):).)*$'`	बताए गए पैकेज के लिए आउटपुट न दिखाएं.
`--output_filter=`	सभी कुछ दिखाएं.
`--output_filter=DONT_MATCH_ANYTHING`	कुछ भी न दिखाएं.

टूल फ़्लैग

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

--copt=cc-option

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

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

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

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

--host_copt=cc-option

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

--host_conlyopt=cc-option

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

--host_cxxopt=cc-option

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

--host_linkopt=linker-option

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

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

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

--strip (always|never|sometimes)

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

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

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

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

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

--stripopt=strip-option

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

--fdo_instrument=profile-output-dir

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

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

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

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

--fdo_optimize=profile-zip

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

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

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

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

--java_language_version=version

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

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

यह सिर्फ़ Java 8 स्पेसिफ़िकेशन के साथ काम करने वाले कंस्ट्रक्शन को कंपाइल करता है और उनकी अनुमति देता है. डिफ़ॉल्ट वैल्यू आठ है. --> संभावित वैल्यू ये हैं: 8, 9, 10, 11, 14, 15, और 21. इन वैल्यू को default_java_toolchain का इस्तेमाल करके, कस्टम Java टूलचेन रजिस्टर करके बढ़ाया भी जा सकता है.

--tool_java_language_version=version

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

--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_repository रिपॉज़िटरी के नियमों का इस्तेमाल करके, वैल्यू बढ़ाई जा सकती हैं.

--tool_java_runtime_version=version

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

  -source 8 -target 8 -encoding UTF-8

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

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

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

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

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

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

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

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

--cpu=cpu

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

--action_env=VAR=VALUE

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

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

--experimental_action_listener=label

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

--[no]experimental_extra_action_top_level_only

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

--experimental_extra_action_filter=regex

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

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

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

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

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

--host_cpu=cpu

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

--android_platforms=platform[,platform]*

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

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

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

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

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

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

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

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

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

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

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

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

--dynamic_mode=mode

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

मोड:

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

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

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

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

--force_ignore_dash_static

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

--[no]force_pic

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

--android_resource_shrinking

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

--custom_malloc=malloc-library-target

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

--crosstool_top=label

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

--host_crosstool_top=label

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

--apple_crosstool_top=label

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

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

--javabase=(label)

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

--host_javabase=label

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

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

प्लान लागू करने की रणनीति

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

--spawn_strategy=strategy

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

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

--strategy mnemonic=strategy

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

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

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

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

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

--genrule_strategy=strategy

यह --strategy=Genrule=strategy के लिए अब काम नहीं करता शॉर्ट-हैंड है.

--jobs=n (-j)

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

--progress_report_interval=n

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

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

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

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

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

--[no]build_runfile_links

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

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

--[no]build_runfile_manifests

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

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

--[no]discard_analysis_cache

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

--[no]keep_going (-k)

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

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

--[no]use_ijars

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

--[no]interface_shared_objects

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

आउटपुट चुनना

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

--[no]build

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

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

--[no]build_tests_only

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

--[no]check_up_to_date

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

--check_tests_up_to_date भी देखें.

--[no]compile_one_dependency

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

--save_temps

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

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

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

--build_tag_filters=tag[,tag]*

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

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

--test_size_filters=size[,size]*

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

  % bazel test --test_size_filters=small,medium //foo:all

और

  % bazel test --test_size_filters=-large,-enormous //foo:all

//foo के अंदर सिर्फ़ छोटे और मध्यम टेस्ट की जांच करेगा.

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

--test_timeout_filters=timeout[,timeout]*

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

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

--test_tag_filters=tag[,tag]*

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

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

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

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

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

--test_lang_filters=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/...

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

--test_filter=filter-expression

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

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

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

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

--explain=logfile

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

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

--verbose_explanations

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

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

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

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

--profile=file

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

--[no]show_loading_progress

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

--[no]show_progress

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

--show_progress_rate_limit=n

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

--show_result=n

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

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

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

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

--sandbox_debug

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

--subcommands (-s)

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

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

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

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

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

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

--verbose_failures

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

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

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

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

--workspace_status_command=program

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

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

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

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

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

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

समझौता:

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

  Bazel हमेशा नीचे दी गई स्टेबल कुंजियां देता है:

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

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

  Bazel हमेशा ये कुंजियां देता है:

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

Linux/macOS पर, फ़ाइल फ़ोल्डर की स्थिति को वापस पाने के लिए --workspace_status_command=/bin/true को पास किया जा सकता है, क्योंकि true कुछ नहीं करता है, शून्य के साथ बंद हो जाता है और कोई आउटपुट प्रिंट नहीं करता. Windows पर इसी तरह के काम के लिए, MSYS के true.exe का पाथ को पास किया जा सकता है.

अगर किसी वजह से वर्कस्पेस का स्टेटस कमांड काम नहीं करता है, तो यह शून्य से बाहर निकल जाता है. ऐसे में, बिल्ड काम नहीं करेगा.

Git का इस्तेमाल करने वाले Linux पर प्रोग्राम का उदाहरण:

#!/bin/bash
echo "CURRENT_TIME $(date +%s)"
echo "RANDOM_HASH $(cat /proc/sys/kernel/random/uuid)"
echo "STABLE_GIT_COMMIT $(git rev-parse HEAD)"
echo "STABLE_USER_NAME $USER"

इस प्रोग्राम का पाथ --workspace_status_command के साथ पास करें और स्टेबल स्टेटस फ़ाइल में STABLE की लाइनें शामिल होंगी और बाकी सभी लाइनें शामिल होंगी.

--[no]stamp

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

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

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

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

प्लैटफ़ॉर्म

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

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

--platforms=labels

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

--host_platform=label

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

--extra_execution_platforms=labels

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

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

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

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

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

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

अहम विकल्प

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

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

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

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

जांच करना

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

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

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

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

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

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

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

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

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

--check_tests_up_to_date

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

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

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

--test_verbose_timeout_warnings

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

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

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

--[no]test_keep_going

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

--flaky_test_attempts=attempts

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

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

--runs_per_test=[regex@]number

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

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

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

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

--[no]runs_per_test_detects_flakes

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

--test_summary=output_style

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

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

--test_output=output_style

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

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

--java_debug

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

--[no]verbose_test_summary

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

--test_tmpdir=path

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

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

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

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

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

--test_arg=arg

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

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

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

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

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

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

--run_under=command-prefix

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

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

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

• जांच करने के लिए इस्तेमाल किया जाने वाला 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 की तरह ही, लेकिन यह एक जैसा नहीं है. यह सीधे तौर पर Bazel की बनाई गई बाइनरी को शुरू करने वाला है. साथ ही, इसका व्यवहार इस बात पर निर्भर करता है कि शुरू की जाने वाली बाइनरी कोई टेस्ट है या नहीं.

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

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

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

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

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

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

--run_under=command-prefix

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

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

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

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

टेस्ट चलाना

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

बिल्ड आउटपुट को मिटाया जा रहा है

clean निर्देश

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

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

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

  % bazel clean --expunge

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

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

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

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

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

क्वेरी भाषा, ग्राफ़ पर बीजगणितीय संक्रियाओं के आइडिया पर आधारित है; इसे इसमें विस्तार से दस्तावेज़ किया गया है:

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

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

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

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

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

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

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

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

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

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

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

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

help

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

--[no]long (-l)

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

shutdown

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

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

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

info

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

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

कॉन्फ़िगरेशन-इंडिपेंडेंट डेटा

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

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

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

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

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

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

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

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

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

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

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

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

% bazel info server_pid
1285

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

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

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

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

  % bazel info --show_make_env -c opt COMPILATION_MODE
  opt

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

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

version और --version

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

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

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

mobile-install

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

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

नीचे दिए गए विकल्प इस्तेमाल किए जा सकते हैं:

--incremental

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

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

--split_apks

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

--start_app

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

--debug_app

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

--start=_start_type_

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

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

--adb=path

इस्तेमाल की जाने वाली adb बाइनरी को दिखाता है.

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

--adb_arg=serial

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

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

adb को इस तौर पर शुरू करता है

adb -s deadbeef install ...

--incremental_install_verbosity=number

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

dump

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

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

नीचे दिए गए विकल्प इस्तेमाल किए जा सकते हैं:

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

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

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

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

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

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

उदाहरण:

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

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

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

analyze-profile

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

canonicalize-flags

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

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

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

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

शुरू करने के विकल्प

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

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

--output_base=dir

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

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

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

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

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

--output_user_root=dir

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

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

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

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

--server_javabase=dir

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

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

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

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

--host_jvm_args=string

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

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

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

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

--host_jvm_debug

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

--autodetect_server_javabase

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

--batch

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

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

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

--max_idle_secs=n

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

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

--[no]shutdown_on_low_sys_mem

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

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

--[no]block_for_lock

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

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

--io_nice_level=n

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

--batch_cpu_scheduling

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

अन्य विकल्प

--[no]announce_rc

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

--color (yes|no|auto)

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

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

--config=name

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

--curses (yes|no|auto)

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

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

--[no]show_timestamps

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