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

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

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

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

विकल्प

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

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

पैकेज की जगह

--package_path

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

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

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

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

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

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

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

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

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

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

--deleted_packages

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

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

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

--[no]check_visibility

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

--output_filter=regex

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

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

टूल फ़्लैग

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

--copt=cc-option

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

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

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

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

--host_copt=cc-option

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

--host_conlyopt=cc-option

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

--host_cxxopt=cc-option

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

--host_linkopt=linker-option

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

--conlyopt=cc-option

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

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

--cxxopt=cc-option

यह विकल्प एक तर्क लेता है जिसे कंपाइलर को तब भेजा जाता है जब C++ सोर्स फ़ाइलों को कंपाइल करना.

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

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

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

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

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

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

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

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

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

--stripopt=strip-option

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

--fdo_instrument=profile-output-dir

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

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

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

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

--fdo_optimize=profile-zip

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

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

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

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

--[no]output_symbol_counts

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

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

--java_language_version=version

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

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

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

--tool_java_language_version=version

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

--java_runtime_version=version

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

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

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

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

--tool_java_runtime_version=version

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

--jvmopt=jvm-option

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

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

  -source 8 -target 8 -encoding UTF-8

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

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

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

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

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

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

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

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

--cpu=cpu

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

--action_env=VAR=VALUE

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

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

--experimental_action_listener=label

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

--[no]experimental_extra_action_top_level_only

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

--experimental_extra_action_filter=regex

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

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

--fat_apk_cpu=cpu[,cpu]*

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

डिफ़ॉल्ट वैल्यू armeabi-v7a है.

के लिए APK में एक .so फ़ाइल बनाई और पैकेज की जाती है हर सीपीयू की है, जिसे --fat_apk_cpu के साथ तय किया जाता है. .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. यह इतने समय में .pb.cc फ़ाइल, base नाम की डायरेक्ट्री में मौजूद है.

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

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

मोड:

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

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

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

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

--force_ignore_dash_static

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

--[no]force_pic

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

--android_resource_shrinking

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

--custom_malloc=malloc-library-target

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

--crosstool_top=label

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

--host_crosstool_top=label

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

--apple_crosstool_top=label

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

--android_crosstool_top=label

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

--compiler=version

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

--android_sdk=label

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

अगर android_sdk_repository नियम को वर्कस्पेस फ़ाइल में परिभाषित किया गया है.

--java_toolchain=label

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

--host_java_toolchain=label

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

--javabase=(label)

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

--host_javabase=label

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

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

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

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

--spawn_strategy=strategy

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

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

--strategy mnemonic=strategy

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

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

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

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

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

--genrule_strategy=strategy

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

--jobs=n (-जे)

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

--progress_report_interval=n

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

--[no]build_runfile_manifests

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

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

--[no]discard_analysis_cache

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

--[no]keep_going (-के)

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

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

--[no]use_ijars

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

--[no]interface_shared_objects

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

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

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

--[no]build

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

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

--[no]build_tests_only

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

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

--build_tag_filters=tag[,tag]*

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

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

--test_size_filters=size[,size]*

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

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

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

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

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

--test_timeout_filters=timeout[,timeout]*

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

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

--test_tag_filters=tag[,tag]*

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

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

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

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

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

--test_lang_filters=lang[,lang]*

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

अगर बताया गया है, तो Basel की जांच होगा (या अगर --build_tests_only है, तो बिल्ड किया जाएगा) भी निर्दिष्ट किया गया है) केवल निर्दिष्ट भाषा(भाषाओं) के परीक्षण लक्ष्य.

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

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

की जांच करने के लिए केवल C/C++ और Java परीक्षणों ( cc_test और java_test नियम) foo/... में, जबकि

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

foo/... में, sh_test और java_test टेस्ट.

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

--test_filter=filter-expression

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

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

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

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

--explain=logfile

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

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

--verbose_explanations

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

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

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

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

--profile=file

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

--[no]show_loading_progress

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

--[no]show_progress

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

--show_progress_rate_limit=n

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

--show_result=n

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

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

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

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

--sandbox_debug

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

--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 कॉल; उन्हें कॉपी करना न भूलें!) हालांकि, कुछ निर्देश Basel के अंदर अंदरूनी तौर पर लागू किए जाते हैं, जैसे सिमलिंक ट्री बनाना. इन्हें दिखाने के लिए कोई कमांड लाइन नहीं है.

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

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

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

--verbose_failures

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

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

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

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

--workspace_status_command=program

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

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

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

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

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

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

समझौता:

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

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

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

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

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

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

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

प्लैटफ़ॉर्म

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

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

--platforms=labels

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

--host_platform=label

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

--extra_execution_platforms=labels

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

--extra_toolchains=labels

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

--toolchain_resolution_debug=regex

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

अन्य सूचनाएं

--flag_alias=alias_name=target_path

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

--symlink_prefix=string

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

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

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

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

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

--platform_suffix=string

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

--default_visibility=(private|public)

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

--[no]use_action_cache

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

--starlark_cpu_profile=_file_

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

अहम विकल्प

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

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

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

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

चल रही जांच

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

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

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

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

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

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

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

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

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

--check_tests_up_to_date

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

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

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

--test_verbose_timeout_warnings

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

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

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

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

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

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

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

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

--test_arg=arg

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

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

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

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

--run_under=command-prefix

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

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

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

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

उदाहरण:

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

चयन का परीक्षण करें

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

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

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

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

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

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

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

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

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

जब बाइनरी एक टेस्ट होता है, तो मौजूदा काम करने वाली डायरेक्ट्री exec रूट होगी और आम तौर पर, एनवायरमेंट टेस्ट की नकल करने की अच्छी भावना से कोशिश की जाती है, को ट्रैक करें. हालांकि, एम्युलेशन सटीक नहीं होता है और कई टेस्ट शार्ड को इस तरह नहीं चलाया जा सकता ( --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 run --ui_event_filters=-info,-stdout,-stderr --noshow_progress //java/myapp:myapp

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

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

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

clean निर्देश

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

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

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

  % bazel clean --expunge

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

help

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

--[no]long (-l)

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

shutdown

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

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

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

info

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

% bazel info server_pid
1285

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

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

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

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

  % bazel info --show_make_env -c opt COMPILATION_MODE
  opt

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

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

version और --version

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

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

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

mobile-install

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

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

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

--incremental

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

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

--split_apks

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

--start_app

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

--debug_app

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

--start=_start_type_

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

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

--adb=path

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

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

--adb_arg=serial

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

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

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

adb -s deadbeef install ...

--incremental_install_verbosity=number

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

dump

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

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

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

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

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

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

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

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

हर आदेश के लिए इन विकल्पों को 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 निर्देश, पहले इकट्ठा किए गए डेटा का विश्लेषण करता है --profile विकल्प का इस्तेमाल करके बिल्ड के दौरान. यह कई तरह की जानकारी देता है बिल्ड के विश्लेषण का विश्लेषण करने या डेटा को एक्सपोर्ट करने के विकल्प दिए गए फ़ॉर्मैट में.

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

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

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

canonicalize-flags

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

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

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

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

स्टार्टअप के विकल्प

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

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

--output_base=dir

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

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

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

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

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

--output_user_root=dir

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

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

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

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

--server_javabase=dir

Java वर्चुअल मशीन के बारे में बताता है, जिसमें Bazz खुद चलता है. मान 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 वर्चुअल मशीन को कनेक्ट होने का इंतज़ार करना पड़ता है इस्तेमाल करने का सुझाव दिया है, इसके लिए, Baज़ेन का इस्तेमाल किया जा सकता है. यह मुख्य तौर पर यह बैज डेवलपर के इस्तेमाल के लिए है.

--autodetect_server_javabase

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

--batch

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

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

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

--max_idle_secs=n

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

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

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

--io_nice_level=n

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

--batch_cpu_scheduling

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

अन्य विकल्प

--[no]announce_rc

यह नीति कंट्रोल करती है कि जब Ba ज़रिए, ba सुझावों को baकोई शुरू करना. (स्टार्टअप विकल्पों की घोषणा बिना किसी शर्त के की जाती है.)

--color (yes|no|auto)

इस विकल्प से तय होता है कि Basel को हाइलाइट करने के लिए कलर का इस्तेमाल करना है या नहीं उसका आउटपुट स्क्रीन पर दिखाई देता है.

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

--config=name

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

--curses (yes|no|auto)

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

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

--[no]show_timestamps

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