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

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

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

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

विकल्प

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

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

पैकेज की जगह

--package_path

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

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

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

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

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

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

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

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`	कुछ न दिखाएं.

टूल फ़्लैग

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

--copt=cc-option

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

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

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

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

ध्यान दें: --copt सेटिंग बदलने पर, जिन ऑब्जेक्ट फ़ाइलों पर असर पड़ा है उन्हें फिर से कंपाइल करना ज़रूरी होगा. यह भी ध्यान रखें कि खास cc_library या cc_binary बिल्ड नियमों में दी गई copts वैल्यू, इन विकल्पों के बाद कंपाइलर कमांड लाइन पर डाली जाएंगी.

चेतावनी: C++ के हिसाब से बने विकल्पों (जैसे, -fno-implicit-templates) को --cxxopt में बताया जाना चाहिए, न कि --copt में. इसी तरह, C से जुड़े विकल्पों (जैसे कि -Wstrict-prototypes) को --conlyopt में बताया जाना चाहिए, copt में नहीं. इसी तरह, कंपाइलर के ऐसे विकल्प जिन्हें लिंक करने के समय ही लागू किया जाता है, जैसे कि -l, उन्हें --linkopt में बताया जाना चाहिए, न कि --copt में.

--host_copt=cc-option

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

--host_conlyopt=cc-option

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

--host_cxxopt=cc-option

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

--host_linkopt=linker-option

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

--conlyopt=cc-option

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

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

ध्यान दें: cc_library या cc_binary के खास बिल्ड नियमों में दिए गए copts पैरामीटर, इन विकल्पों के बाद कंपाइलर कमांड लाइन पर डाले जाते हैं.

--cxxopt=cc-option

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

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

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

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

ध्यान दें: इन विकल्पों के बाद, खास cc_library या cc_binary बिल्ड नियमों में दिए गए कॉप्ट पैरामीटर, कंपाइलर कमांड लाइन पर बाद में रखे जाते हैं.

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

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

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

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

ध्यान दें: अगर आपको डीबग करने से जुड़ी जानकारी चाहिए, तो स्ट्रिपिंग की सुविधा बंद करना ही काफ़ी नहीं है. आपको यह भी पक्का करना होगा कि डीबग करने से जुड़ी जानकारी, कंपाइलर ने जनरेट की हो. इसके लिए, -c dbg या --copt -g का इस्तेमाल करें.

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

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

--stripopt=strip-option

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

ध्यान दें: --stripopt, [--strip](#flag--strip)=(always|sometimes) की मदद से मुख्य बाइनरी को छोटा करने पर लागू नहीं होता.

--fdo_instrument=profile-output-dir

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

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

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

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

--fdo_optimize=profile-zip

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

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

ध्यान दें: इस विकल्प में, सोर्स फ़ाइलों पर ले जाने वाले लेबल भी काम करते हैं. ऐसा हो सकता है कि आपको इससे जुड़े पैकेज में exports_files डायरेक्टिव जोड़ना पड़े, ताकि फ़ाइल Basel को दिख सके.

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

--tool_java_runtime_version=version

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

--jvmopt=jvm-option

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

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

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

--javacopt=javac-option

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

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

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

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

  -source 8 -target 8 -encoding UTF-8

ध्यान दें: --javacopt की सेटिंग बदलने पर, उन सभी क्लास को फिर से कंपाइल किया जाएगा जिन पर असर हुआ है. यह भी ध्यान रखें कि खास java_library या java_binary बिल्ड नियमों में दिए गए javacopts पैरामीटर को इन विकल्पों के बाद javac कमांड लाइन पर रखा जाएगा.

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

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

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

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

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

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

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

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

--cpu=cpu

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

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

--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 में बताए गए हर प्लैटफ़ॉर्म के लिए, एक .so फ़ाइल बनाई और पैकेज की जाती है. .so फ़ाइल के नाम के शुरू में android_binary नियम के नाम से पहले "lib" होता है. उदाहरण के लिए, अगर android_binary का नाम "foo" है, तो फ़ाइल libfoo.so है.

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

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

--dynamic_mode=mode

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

मोड:

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

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

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

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

--force_ignore_dash_static

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

--[no]force_pic

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

ध्यान दें: डाइनैमिक तौर पर लिंक की गई बाइनरी (उदाहरण के लिए, --dynamic_mode fully), इस फ़्लैग की सेटिंग के बावजूद PIC कोड जनरेट करती हैं. इसलिए, यह फ़्लैग उन मामलों के लिए है जहां उपयोगकर्ता चाहते हैं कि स्टैटिक लिंक के लिए पीआईसी कोड साफ़ तौर पर जनरेट किया गया हो.

--android_resource_shrinking

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

--custom_malloc=malloc-library-target

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

--crosstool_top=label

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

--host_crosstool_top=label

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

--apple_crosstool_top=label

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

--android_crosstool_top=label

चेतावनी: --android_crosstool_top का इस्तेमाल नहीं किया जा सकता. इसे सेट करने की ज़रूरत नहीं है.

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

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

--javabase=(label)

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

--host_javabase=label

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

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

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

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

--spawn_strategy=strategy

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

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

--strategy mnemonic=strategy

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

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

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

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

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

--genrule_strategy=strategy

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

--jobs=n (-j)

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

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

--progress_report_interval=n

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

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

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

--[no]build_runfile_links

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

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

--[no]build_runfile_manifests

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

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

--[no]discard_analysis_cache

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

--[no]keep_going (-k)

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

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

--[no]use_ijars

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

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

--[no]interface_shared_objects

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

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

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

--[no]build

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

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

--[no]build_tests_only

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

--[no]check_up_to_date

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

--check_tests_up_to_date भी देखें.

--[no]compile_one_dependency

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

--save_temps

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

ध्यान दें: --save_temps को लागू करने में कंपाइलर के -save-temps फ़्लैग का इस्तेमाल नहीं किया जाता है. इसके बजाय, दो पास हैं. पहला -S का है और दूसरा -E का है. इसका नतीजा यह होता है कि अगर आपका बिल्ड फ़ेल हो जाता है, तो हो सकता है कि बैजल ने अब तक ".i" या ".ii" और ".s" फ़ाइलें न बनाई हों. अगर कंपाइल नहीं हो पाने वाली किसी फ़ाइल को डीबग करने के लिए, --save_temps का इस्तेमाल किया जा रहा है, तो आपको --keep_going का भी इस्तेमाल करना पड़ सकता है. ऐसा करने से, कंपाइलेशन फ़ेल होने के बाद भी, पहले से प्रोसेस की गई फ़ाइलों को बनाने की कोशिश की जा सकेगी.

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

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

--build_tag_filters=tag[,tag]*

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

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

--test_size_filters=size[,size]*

अगर बताया गया है, तो Basel, दिए गए साइज़ वाले टारगेट की ही जांच करेगा (या अगर --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]*

अगर तय किया गया है, तो Basel, दिए गए टाइम आउट के हिसाब से टारगेट को टेस्ट करेगा, अगर --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" का इस्तेमाल करें. Baज़ल, सिर्फ़ रेफ़र किए गए नियम क्लास को टारगेट करके टेस्ट करेगा या अगर --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/... में मौजूद सभी टारगेट की जांच करेगा.

सलाह: टारगेट //p:t के नियम क्लास का नाम जानने के लिए, bazel query --output=label_kind "//p:t" का इस्तेमाल किया जा सकता है. साथ ही, bazel query --output=build "//p:t" के आउटपुट में इंस्टैंशिएशन स्टैक के पेयर को देखकर यह पता लगाया जा सकता है कि वह टारगेट, उस नियम क्लास का इंस्टेंस क्यों है.

चेतावनी: "--test_lang_filter" विकल्प का नाम वेस्टिगल है. इसलिए, यह गलत है. इसलिए, नाम के आधार पर सिमैंटिक के बारे में अनुमान न लगाएं.

--test_filter=filter-expression

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

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

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

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

--explain=logfile

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

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

--verbose_explanations

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

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

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

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

--profile=file

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

--[no]show_loading_progress

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

--[no]show_progress

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

--show_progress_rate_limit=n

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

--show_result=n

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

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

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

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

--sandbox_debug

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

--subcommands (-s)

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

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

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

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

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

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

--verbose_failures

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

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

Workspace खाते का स्टेटस

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

--workspace_status_command=program

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

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

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

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

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

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

समझौता:

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

  Bazel हमेशा ये स्टैबल पासकोड दिखाता है:

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

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

  Baज़ल से, हमेशा ये डेटा अपडेट होते हैं:

  • BUILD_TIMESTAMP: Unix Epoch के बाद के वर्शन में बिल्ड का समय सेकंड में (System.currentTimeMillis() की वैल्यू को हज़ार से भाग देने पर मिलने वाली वैल्यू)
  • FORMATTED_DATE: बिल्ड का समय यूटीसी में yyyy MMM d HH mm ss EEEके तौर पर फ़ॉर्मैट किया गया. उदाहरण के लिए, 2 जून, 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 एट्रिब्यूट का इस्तेमाल करके, स्टैंप को हर नियम के हिसाब से चालू या बंद किया जा सकता है. ज़्यादा जानकारी के लिए, कृपया Build Encyclopedia देखें. जब कोई नियम stamp = -1 (*_binary नियमों के लिए डिफ़ॉल्ट) सेट करता है, तो यह विकल्प तय करता है कि स्टैंप लगाने की सुविधा चालू है या नहीं.

Bazel, exec कॉन्फ़िगरेशन के लिए बने बाइनरी को कभी भी स्टैंप नहीं करता. ऐसा इस विकल्प या 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

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

अन्य सूचनाएं

--flag_alias=alias_name=target_path

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

--symlink_prefix=string

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

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

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

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

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

--platform_suffix=string

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

--default_visibility=(private|public)

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

--starlark_cpu_profile=_file_

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

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

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

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

रिलीज़ में Baज़ल का इस्तेमाल करना

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

अहम विकल्प

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

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

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

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

टेस्ट चलाना

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

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

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

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

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

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

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

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

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

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

--check_tests_up_to_date

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

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

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

--test_verbose_timeout_warnings

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

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

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

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

--[no]test_keep_going

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

--flaky_test_attempts=attempts

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

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

--runs_per_test=[regex@]number

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

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

• अगर यह विकल्प मौजूद नहीं है, तो किसी भी टेस्ट के फ़ेल होने पर पूरा टेस्ट फ़ेल हो जाता है.
• अगर यह मौजूद है और एक ही स्HARD से दो रन, पास और फ़ेल के नतीजे देते हैं, तो टेस्ट को 'अमान्य' स्टेटस मिलेगा. ऐसा तब तक होगा, जब तक कि अन्य फ़ेल होने वाले रन की वजह से इसे फ़ेल नहीं कर दिया जाता.

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

--[no]runs_per_test_detects_flakes

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

--test_summary=output_style

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

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

--test_output=output_style

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

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

--java_debug

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

--[no]verbose_test_summary

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

--test_tmpdir=path

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

ध्यान दें: यह डायरेक्ट्री, जांच के लिए इस्तेमाल की जाती है. इसमें जांच के नतीजों को सेव नहीं किया जाता है. इन्हें हमेशा bazel-out डायरेक्ट्री में सेव किया जाता है.

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

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

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

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

--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, --arg1 और --arg2 को Bazel के विकल्पों के तौर पर न समझे, बल्कि बाइनरी को चलाने के लिए कमांड लाइन के हिस्से के तौर पर समझे. (चलाया जा रहा प्रोग्राम सिर्फ़ 'नमस्ते' कहता है और अपने आर्ग प्रिंट करता है.)

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

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

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

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

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

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

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

--run_under=command-prefix

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

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

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

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

टेस्ट चलाना

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

बिल्ड आउटपुट मिटाना

clean निर्देश

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

याद रखें कि हर Ba ज़रिएclean

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

  % bazel clean --expunge

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

ध्यान दें: इससे आईओ कॉन्टेंटशन हो सकता है.

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

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

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

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

क्वेरी भाषा, ग्राफ़ पर ऐल्जेब्रिक ऑपरेशन के आइडिया पर आधारित है. इस बारे में ज़्यादा जानकारी

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

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

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

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

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

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

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

चेतावनी: aquery कमांड अब भी एक्सपेरिमेंट के तौर पर उपलब्ध है और इसका एपीआई बदल जाएगा.

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

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

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

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

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

help

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

--[no]long (-l)

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

shutdown

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

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

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

info

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  % bazel info --show_make_env -c opt COMPILATION_MODE
  opt

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

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

version और --version

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

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

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

mobile-install

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

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

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

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

--incremental

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

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

--split_apks

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

--start_app

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

--debug_app

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

--start=_start_type_

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

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

ध्यान दें: अगर --start=_start_type_, --start_app या --debug_app में से एक से ज़्यादा वैल्यू सेट की जाती हैं, तो आखिरी वैल्यू का इस्तेमाल किया जाता है.

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

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

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

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

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

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

• --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 पर Basel में की जाती है. इसलिए, पक्का करें कि आपने $BAZEL को उस जगह के हिसाब से सेट किया हो जहां आपको Basel का रिपॉज़िटरी (डेटा स्टोर करने की जगह) रखा गया है.

हर कमांड के लिए, Bazel को ये विकल्प देना न भूलें. ऐसा न करने पर, सर्वर फिर से शुरू हो जाएगा.

उदाहरण:

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

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

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

analyze-profile

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

canonicalize-flags

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

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

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

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

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

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

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

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

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

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

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

--output_user_root=dir

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

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

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

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

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

--server_javabase=dir

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

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

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

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

--host_jvm_args=string

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

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

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

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

--host_jvm_debug

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

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

--autodetect_server_javabase

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

--batch

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

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

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

चेतावनी: --batch, स्टैंडर्ड क्लाइंट/सर्वर मोड से काफ़ी धीमा है. इसके अलावा, हो सकता है कि इसमें वे सभी सुविधाएं और ऑप्टिमाइज़ेशन शामिल न हों जिन्हें एक लगातार चलने वाले Basel सर्वर की मदद से संभव बनाया गया है. अगर बिल्ड को अलग-अलग रखने के लिए --batch का इस्तेमाल किया जा रहा है, तो आपको कमांड के विकल्प --nokeep_state_after_build का इस्तेमाल करना चाहिए. इससे यह पक्का होता है कि बिल्ड के बीच में, इन-मेमोरी में कोई इंक्रीमेंटल स्टेटस सेव न किया जाए. बिल्ड के बाद Basel सर्वर और JVM को रीस्टार्ट करने के लिए, कृपया "शटडाउन" कमांड का इस्तेमाल करके साफ़ तौर पर ऐसा करें.

--max_idle_secs=n

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

ध्यान दें: इस फ़्लैग को सिर्फ़ तब पढ़ा जाता है, जब बेज़ल को नया सर्वर शुरू करने की ज़रूरत हो. इस विकल्प को बदलने से सर्वर फिर से शुरू नहीं होगा.

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

--[no]shutdown_on_low_sys_mem

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

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

--[no]block_for_lock

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

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

--io_nice_level=n

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

--batch_cpu_scheduling

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

अन्य विकल्प

--[no]announce_rc

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

--color (yes|no|auto)

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

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

--config=name

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

--curses (yes|no|auto)

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

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

--[no]show_timestamps

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