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

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

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

--host_conlyopt=cc-option

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

--host_cxxopt=cc-option

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

--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 फ़ाइल की प्रोफ़ाइल जानकारी होती है.

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

--tool_java_language_version=version

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

--java_runtime_version=version

यह विकल्प कोड को एक्ज़ीक्यूट करने और टेस्ट चलाने के लिए, JVM का वर्शन तय करता है. जैसे:

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

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

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

--tool_java_runtime_version=version

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

--jvmopt=jvm-option

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

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

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

--javacopt=javac-option

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

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

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

यह विकल्प, javac को पास किया जाता है. ऐसा, Javac के लिए बिल्ट-इन डिफ़ॉल्ट विकल्पों के बाद और हर नियम के विकल्पों से पहले किया जाता है. 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] टाइप की स्टैंडर्ड JavaScript चेतावनियां जनरेट करेगा.
  • 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 विकल्प, बज़ल को बिल्ड ग्राफ़ में 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++ जैसी नेटिव डिपेंडेंसी के लिए). उदाहरण के लिए, अगर किसी android_binary नियम के ट्रांज़िटिव deps में cc_library दिखता है, तो इसे 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++ फ़ाइल का बेस नाम (एक्सटेंशन के साथ) भी शामिल होता है. इसमें प्लैटफ़ॉर्म पर निर्भर करने वाले प्रीफ़िक्स भी शामिल हैं.

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

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

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

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

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

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

--dynamic_mode=mode

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

मोड:

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

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

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

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

--force_ignore_dash_static

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

--[no]force_pic

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

--android_resource_shrinking

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

--custom_malloc=malloc-library-target

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

--crosstool_top=label

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

--host_crosstool_top=label

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

--apple_crosstool_top=label

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

--android_crosstool_top=label

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

--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 "Make" वैरिएबल इस विकल्प से लिए जाते हैं.

--host_javabase=label

यह विकल्प, बेस Java इंस्टॉलेशन का लेबल सेट करता है, ताकि उसे exec कॉन्फ़िगरेशन में इस्तेमाल किया जा सके. उदाहरण के लिए, 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 का मतलब, local रणनीति का इस्तेमाल करके कार्रवाइयां तब चलाना है, जब उनकी जानकारी //foo.*.cc से मेल खाती हो, लेकिन //foo/bar नहीं.
  • उदाहरण: --strategy_regexp='Compiling.*/bar=local' --strategy_regexp=Compiling=sandboxed sandboxed रणनीति के साथ 'Compiling //foo/bar/baz' करता है, लेकिन क्रम में बदलाव करने पर यह local के साथ चलता है.
  • उदाहरण: --strategy_regexp='Compiling.*/bar=local,sandboxed', '//foo/Bar/baz' को local रणनीति के साथ चलाता है और काम न करने पर, sandboxed पर वापस चला जाता है.

--genrule_strategy=strategy

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

--jobs=n (-j)

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

--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 स्थानीय सिस्टम के कॉन्फ़िगरेशन से सीधे रैम की मात्रा और सीपीयू कोर की संख्या का अनुमान लगाता है.

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

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

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

--save_temps

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

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

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

--build_tag_filters=tag[,tag]*

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

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

--test_size_filters=size[,size]*

अगर बारे में बताया गया है, तो 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_filter की मदद से, अलग-अलग --test_arg फ़िल्टर आर्ग्युमेंट को पास किया जा सकता है. हालांकि, सभी फ़्रेमवर्क इस सुविधा के साथ काम नहीं करते.

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

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

--explain=logfile

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

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

--verbose_explanations

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

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

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

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

--profile=file

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

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

--extra_toolchains=labels

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

--toolchain_resolution_debug=regex

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

अन्य सूचनाएं

--flag_alias=alias_name=target_path

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

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

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

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

टेस्ट करना

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

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

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

--test_verbose_timeout_warnings

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

उदाहरण के लिए, आम तौर पर एक या दो मिनट में एक्ज़ीक्यूट होने वाले टेस्ट के लिए, 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

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

--[no]verbose_test_summary

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

--test_tmpdir=path

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

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

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

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

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

--test_arg=arg

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

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

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

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

--run_under=command-prefix

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

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

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

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

उदाहरण:

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

टेस्ट के विकल्प चुनें

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

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

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

एक्ज़ीक्यूटेबल चल रहे हैं

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

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

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

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

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

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

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

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

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

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

--run_under=command-prefix

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

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

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

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

टेस्ट चलाना

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

बिल्ड आउटपुट साफ़ करना

clean निर्देश

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

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

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

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

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

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

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

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

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

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

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

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

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

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

help

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

--[no]long (-l)

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

shutdown

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

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

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

info

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

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

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

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

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

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

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

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

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

% bazel info server_pid
1285

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

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

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

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

  % bazel info --show_make_env -c opt COMPILATION_MODE
  opt

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

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

version और --version

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

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

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

mobile-install

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

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

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

--incremental

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

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

--split_apks

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

--start_app

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

--debug_app

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

--start=_start_type_

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

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

--adb=path

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

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

--adb_arg=serial

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

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

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

adb -s deadbeef install ...

--incremental_install_verbosity=number

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

dump

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

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

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

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

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

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

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

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

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 कमांड एक साथ चलते हैं (शेल &amp; ऑपरेटर की वजह से), और दोनों कमांड में अलग-अलग 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 का इस्तेमाल, बैजल को चलाने के लिए कोई खास JRE चुनने के लिए किया जा सकता है.

--batch

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

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

--batch_cpu_scheduling

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

अन्य विकल्प

--[no]announce_rc

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

--color (yes|no|auto)

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

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

--config=name

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

--curses (yes|no|auto)

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

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

--[no]show_timestamps

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