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

7.3 · 7.2 · 7.1 · 7.0 · 6.5

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

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

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

विकल्प

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

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

पैकेज की जगह

--package_path

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

Baze, पैकेज पाथ को खोजकर अपने पैकेज ढूंढता है. यह कोलन से अलग की गई, क्रम में लगाई गई 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 का इस्तेमाल किया जाता है, तो हो सकता है कि यह अनचाहे तरीके से काम करे. उदाहरण के लिए, अगर package-path एलिमेंट . का इस्तेमाल करने के बाद, डायरेक्ट्री /home/bob/clients/bob_client/bazel/foo में cd किया जाता है, तो पैकेज /home/bob/clients/bob_client/bazel/foo डायरेक्ट्री से हल किए जाएंगे.

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

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

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

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

--deleted_packages

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

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

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

--[no]check_visibility

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

--output_filter=regex

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

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

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

टूल फ़्लैग

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

--copt=cc-option

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

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

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

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

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

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

--host_copt=cc-option

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

--host_conlyopt=cc-option

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

--host_cxxopt=cc-option

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

--host_linkopt=linker-option

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

--conlyopt=cc-option

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

यह --copt से मिलता-जुलता है, लेकिन सिर्फ़ C कंपाइलेशन पर लागू होता है, न कि C++ कंपाइलेशन या लिंकिंग पर. इसलिए, --conlyopt का इस्तेमाल करके 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 बिल्ड नियमों में दिए गए copts पैरामीटर, इन विकल्पों के बाद कंपाइलर कमांड लाइन पर डाले जाते हैं.

--linkopt=linker-option

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

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

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

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

--strip (always|never|sometimes)

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

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

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

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

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

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

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

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

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

--fdo_optimize=profile-zip

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

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

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

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

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

--[no]output_symbol_counts

अगर यह सुविधा चालू है, तो C++ एक्सीक्यूटेबल बाइनरी के हर ऐसे लिंक से सिंबल की संख्या वाली फ़ाइल जनरेट होगी जिसे --print-symbol-counts गोल्ड विकल्प के ज़रिए शुरू किया गया है. लिंक करने वाले हर इनपुट के लिए, फ़ाइल तय किए गए सिंबल की संख्या और बाइनरी में इस्तेमाल किए गए सिंबल की संख्या लॉग करती है. इस जानकारी का इस्तेमाल, ग़ैर-ज़रूरी लिंक डिपेंडेंसी को ट्रैक करने के लिए किया जा सकता है. सिंबल की संख्या वाली फ़ाइल को [targetname].sc नाम के साथ, बाइनरी के आउटपुट पाथ में लिखा जाता है.

यह विकल्प डिफ़ॉल्ट रूप से बंद होता है.

--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 ऐप्लिकेशन चलाता है.

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

--tool_java_runtime_version=version

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

--jvmopt=jvm-option

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

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

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

--javacopt=javac-option

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

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

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

यह विकल्प, javac के लिए Bazel के डिफ़ॉल्ट विकल्पों के बाद और हर नियम के विकल्पों से पहले 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) (-c)

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

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

--cpu=cpu

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

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

--action_env=VAR=VALUE

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

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

--experimental_action_listener=label

चेतावनी: अतिरिक्त कार्रवाइयों का इस्तेमाल नहीं किया जा सकता. इसके बजाय, aspects का इस्तेमाल करें.

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

--[no]experimental_extra_action_top_level_only

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

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

--experimental_extra_action_filter=regex

चेतावनी: अन्य कार्रवाइयों के इस्तेमाल पर रोक लगा दी गई है. इसके बजाय, aspects का इस्तेमाल करें.

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

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

--fat_apk_cpu=cpu[,cpu]*

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

डिफ़ॉल्ट रूप से, यह armeabi-v7a पर सेट होता है.

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

ध्यान दें: Android के साथ काम करने वाला क्रॉसटूल चुनना ज़रूरी है. अगर WORKSPACE फ़ाइल में android_ndk_repository नियम तय किया गया है, तो Android के साथ काम करने वाला क्रॉसटूल अपने-आप चुन लिया जाता है. इसके अलावा, क्रॉसटूल को --android_crosstool_top या --crosstool_top फ़्लैग का इस्तेमाल करके चुना जा सकता है.

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

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

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

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

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

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

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

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

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

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

--dynamic_mode=mode

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

मोड:

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

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

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

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

--crosstool_top=label

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

--host_crosstool_top=label

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

--apple_crosstool_top=label

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

--android_crosstool_top=label

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

--compiler=version

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

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

--android_sdk=label

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

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

--java_toolchain=label

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

--host_java_toolchain=label

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

--javabase=(label)

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

--host_javabase=label

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

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

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

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

--spawn_strategy=strategy

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

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

--strategy mnemonic=strategy

यह विकल्प यह कंट्रोल करता है कि निर्देश कहां और कैसे लागू किए जाएं. यह हर स्मृति चिह्न के आधार पर, --spawn_strategy (और स्मृति चिह्न वाले Genrule के साथ --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 का इस्तेमाल करके, यह पुष्टि की जा सकती है कि रनफ़ाइल ट्री बनाने के लिए, सभी टारगेट, ओवरहेड के बिना कंपाइल होते हैं या नहीं.

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

--[no]build_runfile_manifests

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

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

--[no]discard_analysis_cache

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

--[no]keep_going (-k)

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

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

--[no]use_ijars

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

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

--[no]interface_shared_objects

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

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

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

--[no]build

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

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

--[no]build_tests_only

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

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

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

--save_temps

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

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

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

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

--build_tag_filters=tag[,tag]*

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

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

--test_size_filters=size[,size]*

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

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

और

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

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

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

--test_timeout_filters=timeout[,timeout]*

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

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

--test_tag_filters=tag[,tag]*

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

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

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

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

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

--test_lang_filters=lang[,lang]*

इस पैरामीटर में, कॉमा लगाकर अलग की गई उन भाषाओं की सूची दी जाती है जिनके लिए आधिकारिक *_test नियम लागू होते हैं. इन भाषाओं की पूरी सूची देखने के लिए, बिल्ड एनसाइक्लोपीडिया देखें. बाहर रखी गई भाषाओं को बताने के लिए, हर भाषा के पहले '-' का इस्तेमाल किया जा सकता है. हर भाषा के लिए इस्तेमाल किया जाने वाला नाम, *_test नियम में भाषा के प्रीफ़िक्स से मेल खाना चाहिए. उदाहरण के लिए, cc, java या sh.

अगर भाषा की जानकारी दी गई है, तो Bazel सिर्फ़ बताई गई भाषा के टेस्ट टारगेट की जांच करेगा (या अगर --build_tests_only की जानकारी भी दी गई है, तो उसे बनाएगा).

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

  % bazel test --test_lang_filters=cc,java foo/...

foo/... में सिर्फ़ C/C++ और Java टेस्ट (क्रमशः cc_test और java_test नियमों का इस्तेमाल करके तय किए गए) की जांच करेगा, जबकि

  % bazel test --test_lang_filters=-sh,-java foo/...

sh_test और java_test को छोड़कर, foo/... में सभी टेस्ट चलाए जाएंगे.

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

--test_filter=filter-expression

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

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

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

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

--explain=logfile

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

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

--verbose_explanations

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

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

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

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

--profile=file

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

--[no]show_loading_progress

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

--[no]show_progress

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

--show_progress_rate_limit=n

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

--show_result=n

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

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

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

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

--sandbox_debug

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

--subcommands (-s)

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

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

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

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

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

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

--verbose_failures

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

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

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

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

--workspace_status_command=program

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

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

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

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

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

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

समझौता:

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

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

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

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

  Bazel हमेशा ये वोलेटाइल बटन दिखाता है:

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

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

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

प्लैटफ़ॉर्म

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

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

--platforms=labels

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

--host_platform=label

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

--extra_execution_platforms=labels

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

--extra_toolchains=labels

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

--toolchain_resolution_debug=regex

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

अन्य सूचनाएं

--flag_alias=alias_name=target_path

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

--symlink_prefix=string

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

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

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

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

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

--platform_suffix=string

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

--default_visibility=(private|public)

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

--[no]use_action_cache

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

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

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

अहम विकल्प

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

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

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

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

टेस्ट चलाना

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

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

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

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

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

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

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

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

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

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

--check_tests_up_to_date

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

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

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

--test_verbose_timeout_warnings

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

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

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

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

--[no]test_keep_going

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

--flaky_test_attempts=attempts

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

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

--runs_per_test=[regex@]number

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

टारगेट के स्टेटस का पता, --runs_per_test_detects_flakes फ़्लैग की वैल्यू से चलता है:

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

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

--java_debug

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

--[no]verbose_test_summary

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

--test_tmpdir=path

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

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

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

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

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

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

--test_arg=arg

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

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

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

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

--run_under=command-prefix

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

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

हालांकि, कुछ बातों का ध्यान रखना ज़रूरी है:

• टेस्ट चलाने के लिए इस्तेमाल किया गया पाथ, आपके एनवायरमेंट में मौजूद पाथ से अलग हो सकता है. इसलिए, आपको --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

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

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

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

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

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

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

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

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

--run_under=command-prefix

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

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

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

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

टेस्ट चलाना

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

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

clean निर्देश

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

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

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

  % bazel clean --expunge

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

ध्यान दें: इससे IO के लिए विवाद हो सकता है.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

help

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

--[no]long (-l)

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

shutdown

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

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

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

info

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

% bazel info server_pid
1285

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

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

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

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

  % bazel info --show_make_env -c opt COMPILATION_MODE
  opt

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

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

version और --version

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

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

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

mobile-install

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

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

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

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

--incremental

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

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

--split_apks

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

--start_app

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

--debug_app

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

--start=_start_type_

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

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

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

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

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

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

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

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

Java-एजेंट की जांच third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar पर 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 कमांड, --profile विकल्प का इस्तेमाल करके, पहले से इकट्ठा किए गए डेटा का विश्लेषण करता है. इसमें, बिल्ड एक्सीक्यूशन का विश्लेषण करने या तय किए गए फ़ॉर्मैट में डेटा एक्सपोर्ट करने के कई विकल्प मिलते हैं.

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

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

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

canonicalize-flags

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

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

ध्यान दें: कुछ विकल्पों को फिर से क्रम में नहीं लगाया जा सकता, क्योंकि Bazel यह पक्का नहीं कर सकता कि उनका असर एक जैसा होगा. यह भी ध्यान रखें कि यह कमांड, --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

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

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

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

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

 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 का इंक्रीमेंटल बिल्ड.

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

--output_user_root=dir

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

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

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

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

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

--server_javabase=dir

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

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

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

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

--host_jvm_args=string

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

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

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

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

--host_jvm_debug

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

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

--autodetect_server_javabase

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

--batch

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

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

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

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

--max_idle_secs=n

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

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

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

--[no]shutdown_on_low_sys_mem

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

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

--[no]block_for_lock

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

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

--io_nice_level=n

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

--batch_cpu_scheduling

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

अन्य विकल्प

--[no]announce_rc

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

--color (yes|no|auto)

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

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

--config=name

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

--curses (yes|no|auto)

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

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

--[no]show_timestamps

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