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

किसी समस्या की शिकायत करें सोर्स देखें रात · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

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

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

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

विकल्प

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

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

पैकेज की जगह

--package_path

चेतावनी: --package_path विकल्प अब काम नहीं करता. Bazel, मुख्य रिपॉज़िटरी में मौजूद पैकेज को वर्कस्पेस रूट में रखने को प्राथमिकता देता है.

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

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

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

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

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

  % mkdir -p foo/bazel
  % cd foo/bazel
  % touch MODULE.bazel
  % 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 बिल्ड नियम, कंपाइलर कमांड लाइन पर रखे जाएंगे बाद में ये विकल्प सेट करें.

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

--host_copt=cc-option

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

--host_conlyopt=cc-option

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

--host_cxxopt=cc-option

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

--host_linkopt=linker-option

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

--conlyopt=cc-option

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

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

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

--cxxopt=cc-option

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

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

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

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

अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है

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

--linkopt=linker-option

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

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

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

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

--strip (always|never|sometimes)

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

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

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

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

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

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

--stripopt=strip-option

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

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

--fdo_instrument=profile-output-dir

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

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

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

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

--fdo_optimize=profile-zip

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

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

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

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

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

--java_language_version=version

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

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

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

--tool_java_language_version=version

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

--java_runtime_version=version

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

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

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

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

--tool_java_runtime_version=version

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

--jvmopt=jvm-option

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

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

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

--javacopt=javac-option

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

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

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

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

  -source 8 -target 8 -encoding UTF-8

अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है

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

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

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

• off का मतलब है कि जांच करने की सुविधा बंद है.
• warn का मतलब है कि javac, हर उस डायरेक्ट डिपेंडेंसी के लिए [strict] टाइप करें जो मौजूद नहीं है.
• 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 पेयर से तय किया जा सकता है. नाम से तय करने पर, वैल्यू को कॉल करने के एनवायरमेंट से लिया जाएगा. वहीं, name=value पेयर से तय करने पर, वैल्यू को कॉल करने के एनवायरमेंट से अलग सेट किया जाएगा.

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

--experimental_action_listener=label

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

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

--[no]experimental_extra_action_top_level_only

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

अगर यह विकल्प सही पर सेट होता है, तो अतिरिक्त कार्रवाइयां --experimental_action_listener आदेश पंक्ति विकल्प केवल शीर्ष स्तरीय लक्ष्यों के लिए शेड्यूल किया जाएगा.

--experimental_extra_action_filter=regex

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

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

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

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

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

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

--host_cpu=cpu

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

--android_platforms=platform[,platform]*

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

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

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

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

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

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

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

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

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

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

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

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

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

--dynamic_mode=mode

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

मोड:

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

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

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

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

--force_ignore_dash_static

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

--[no]force_pic

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

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

--android_resource_shrinking

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

--custom_malloc=malloc-library-target

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

--crosstool_top=label

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

--host_crosstool_top=label

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

--apple_crosstool_top=label

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

--compiler=version

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

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

--android_sdk=label

समर्थन नहीं होना या रुकना. इसकी जानकारी सीधे तौर पर नहीं दी जानी चाहिए.

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

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

--java_toolchain=label

कोई कार्रवाई नहीं की गई. इसे सिर्फ़ पुराने सिस्टम के साथ काम करने की सुविधा के लिए रखा गया है.

--host_java_toolchain=label

नहीं. सिर्फ़ पुराने सिस्टम के साथ काम करने के लिए रखा गया.

--javabase=(label)

नहीं. सिर्फ़ पुराने सिस्टम के साथ काम करने के लिए रखा गया.

--host_javabase=label

नहीं. सिर्फ़ पुराने सिस्टम के साथ काम करने के लिए रखा गया.

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

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

--spawn_strategy=strategy

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

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

--strategy mnemonic=strategy

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

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

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

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

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

--genrule_strategy=strategy

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

--jobs=n (-जे)

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

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

--progress_report_interval=n

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

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

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

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

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

--[no]build_runfile_links

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

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

--[no]build_runfile_manifests

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

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

--[no]discard_analysis_cache

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

--[no]keep_going (-k)

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

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

--[no]use_ijars

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

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

--[no]interface_shared_objects

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

आउटपुट चुनना

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

--[no]build

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

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

--[no]build_tests_only

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

--[no]check_up_to_date

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

--check_tests_up_to_date भी देखें.

--[no]compile_one_dependency

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

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

  % bazel test --test_lang_filters=foo,bar //baz/...

सिर्फ़ उन टारगेट की जांच करेगा जो //baz/... में foo_test या bar_test के इंस्टेंस हैं, जबकि

  % bazel test --test_lang_filters=-foo,-bar //baz/...

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

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

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

--test_filter=filter-expression

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

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

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

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

--explain=logfile

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

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

--verbose_explanations

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

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

इस विकल्प का उपयोग करने से जनरेट की गई एक्सप्लेनेशन फ़ाइल और इसका इस्तेमाल करने पर लगने वाले जुर्माने --explain.

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

--profile=file

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

--[no]show_loading_progress

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

--[no]show_progress

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

--show_progress_rate_limit=n

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

--show_result=n

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

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

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

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

--sandbox_debug

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

--subcommands (-s)

इस विकल्प की वजह से, बेज़ल पूरी कमांड लाइन प्रिंट करता है. लागू करने से पहले हर निर्देश की पुष्टि करता है.

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

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

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

नीचे --verbose_failures जानकारी भी देखें.

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

--verbose_failures

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

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

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

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

--workspace_status_command=program

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

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

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

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

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

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

समझौता:

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

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

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

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

  Basel की वजह से, हमेशा ये डेटा अपडेट होते हैं:

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

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

अगर किसी वजह से वर्कस्पेस स्टेटस कमांड काम नहीं करता है (नॉन-ज़ीरो पर बाहर निकलता है), तो बिल्ड पूरा नहीं होगा.

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

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

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

--[no]stamp

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

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

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

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

प्लैटफ़ॉर्म

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

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

--platforms=labels

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

--host_platform=label

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

--extra_execution_platforms=labels

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

--extra_toolchains=labels

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

--toolchain_resolution_debug=regex

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

अन्य सूचनाएं

--flag_alias=alias_name=target_path

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

--symlink_prefix=string

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

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

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

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

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

--platform_suffix=string

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

--default_visibility=(private|public)

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

--starlark_cpu_profile=_file_

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

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

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

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

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

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

अहम विकल्प

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

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

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

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

चल रही जांच

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

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

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

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

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

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

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

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

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

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

--check_tests_up_to_date

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

इस विकल्प से, --check_up_to_date व्यवहार का भी पता चलता है.

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

--test_verbose_timeout_warnings

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

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

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

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

--[no]test_keep_going

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

--flaky_test_attempts=attempts

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

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

--runs_per_test=[regex@]number

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

विफल रन वाले टारगेट की स्थिति, --runs_per_test_detects_flakes फ़्लैग:

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

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

--[no]runs_per_test_detects_flakes

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

--test_summary=output_style

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

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

--test_output=output_style

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

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

--java_debug

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

--[no]verbose_test_summary

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

--test_tmpdir=path

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

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

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

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

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

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

--test_arg=arg

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

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

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

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

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

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

--run_under=command-prefix

इससे एक प्रीफ़िक्स तय होता है, जिसे टेस्ट रनर, टेस्ट कमांड को चलाने से पहले उसके आगे डालेगा. Bourne shell के टोकनाइज़ेशन नियमों का इस्तेमाल करके, 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 कमांड से मिलता-जुलता है. हालांकि, इसका इस्तेमाल किसी एक टारगेट को बनाने और चलाने के लिए किया जाता है. यहां एक सामान्य सत्र दिया गया है (//java/myapp:myapp हैलो कहता है और अपने आर्ग प्रिंट करता है):

  % bazel run java/myapp:myapp -- --arg1 --arg2
  INFO: Analyzed target //java/myapp:myapp (13 packages loaded, 27 targets configured).
  INFO: Found 1 target...
  Target //java/myapp:myapp up-to-date:
    bazel-bin/java/myapp/myapp
  INFO: Elapsed time: 14.290s, Critical Path: 5.54s, ...
  INFO: Build completed successfully, 4 total actions
  INFO: Running command line: bazel-bin/java/myapp/myapp <args omitted>
  Hello there
  $EXEC_ROOT/java/myapp/myapp
  --arg1
  --arg2

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

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

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

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

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

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

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

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

--run_under=command-prefix

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

Bazz के हिसाब से, लॉगिंग आउटपुट फ़िल्टर किए जा रहे हैं

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

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

टेस्ट एक्ज़ीक्यूट किए जा रहे हैं

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

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

clean निर्देश

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

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

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

  % bazel clean --expunge

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

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

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

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

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

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

क्वेरी की भाषा इन बातों पर आधारित है ग्राफ़ पर बीजगणितीय संक्रियाएं; तो उसे विस्तार से बताया गया है.

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

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

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

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

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

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

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

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

info

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

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

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

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

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

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

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

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

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

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

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

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

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

• package_path: कोलन से अलग किए गए पाथ की सूची, जिसमें पैकेज खोजने के लिए bazel का इस्तेमाल किया जाएगा. इसका फ़ॉर्मैट, --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++ कंपाइलर. यह "Make" एनवायरमेंट में $(CC) वैरिएबल है, इसलिए --show_make_env फ़्लैग की ज़रूरत है.

  % bazel info --show_make_env -c opt COMPILATION_MODE
  opt

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

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

version और --version

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

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

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

mobile-install

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

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

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

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

--incremental

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

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

--split_apks

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

--start_app

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

--debug_app

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

--start=_start_type_

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

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

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

--adb=path

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

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

--adb_arg=serial

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

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

adb को इस नंबर से कॉल करता है

adb -s deadbeef install ...

--incremental_install_verbosity=number

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

dump

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

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

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

• --action_cache ऐक्शन कैश मेमोरी का कॉन्टेंट डंप करता है.
• --packages, पैकेज की कैश मेमोरी का कॉन्टेंट डंप करता है.
• --skyframe, इंटरनल बेज़ल डिपेंडेंसी ग्राफ़ की स्थिति को डंप करता है.
• --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-agent को third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar पर, Bazel में चेक किया जाता है. इसलिए, पक्का करें कि आपने $BAZEL को उस जगह के हिसाब से अडजस्ट किया हो जहां आपने अपना Bazel डेटा स्टोर किया है.

हर आदेश के लिए इन विकल्पों को Basel को देना न भूलें, नहीं तो सर्वर रीस्टार्ट करें.

उदाहरण:

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

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

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

analyze-profile

analyze-profile कमांड, यह पहले से JSON ट्रेस प्रोफ़ाइल थी बेज़ल के न्योते के दौरान इकट्ठा हुए वीडियो.

canonicalize-flags

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

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

ध्यान दें: कुछ विकल्पों को फिर से क्रम में नहीं लगाया जा सकता, क्योंकि Bazel यह पक्का नहीं कर सकता कि उनका असर एक जैसा होगा. यह भी ध्यान रखें कि यह कमांड, --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 सिंटैक्स का इस्तेमाल करके तय किया जाना चाहिए. साथ ही, ये विकल्प Basel के नाम से पहले दिखने चाहिए आदेश. इन्हें किसी .bazelrc फ़ाइल में शामिल करने के लिए, startup --key=value का इस्तेमाल करें.

--output_base=dir

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

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

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

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

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

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

  % 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 वर्चुअल मशीन को पास किए जाने वाला एक स्टार्टअप विकल्प तय करता है, जिसमें Bagel दौड़ता है. इसका इस्तेमाल स्टैक का साइज़ सेट करने के लिए किया जा सकता है, उदाहरण के लिए:

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

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

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

--host_jvm_debug

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

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

--autodetect_server_javabase

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

--batch

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

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

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

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

--max_idle_secs=n

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

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

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

--[no]shutdown_on_low_sys_mem

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

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

--[no]block_for_lock

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

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

--io_nice_level=n

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

--batch_cpu_scheduling

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

अन्य विकल्प

--[no]announce_rc

यह नीति कंट्रोल करती है कि Basel, चालू होने के विकल्पों और कमांड के विकल्पों को पढ़कर सुनाता है या नहीं bazzrc फ़ाइलों को स्टोर करने में मदद करता है.

--color (yes|no|auto)

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

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

--config=name

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

--curses (yes|no|auto)

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

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

--[no]show_timestamps

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