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

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

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

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

विकल्प

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

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

पैकेज की जगह की जानकारी

--package_path

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

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

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

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

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

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

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

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

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

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

--deleted_packages

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

जांचने में गड़बड़ी

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

--[no]check_visibility

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

--output_filter=regex

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

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

`--आउटपुट_फ़िल्टर='^//(पहला/प्रोजेक्ट|सेकंड/प्रोजेक्ट):'` खास पैकेज के लिए आउटपुट दिखाएं.
`--आउटपुट_फ़िल्टर='^//(?!(पहले/bad_project|second/bad_project):).**'` बताए गए पैकेज के लिए आउटपुट न दिखाएं.
`--आउटपुट_फ़िल्टर=` सब कुछ दिखाएं.
`--आउटपुट_फ़िल्टर=DONT_MATCH_ANYTHING` कुछ भी न दिखाएं.

टूल फ़्लैग

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

--copt=cc-option

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

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

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

डीबग टेबल के बिना foo लाइब्रेरी इकट्ठा करेगा. इससे, अलग-अलग स्थिति वाला कोड जनरेट होगा.

--host_copt=cc-option

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

--host_conlyopt=cc-option

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

--host_cxxopt=cc-option

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

--host_linkopt=linker-option

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

--conlyopt=cc-option

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

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

--cxxopt=cc-option

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

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

जैसे:

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

--linkopt=linker-option

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

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

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

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

--strip (always|never|sometimes)

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

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

यह जनरेट की गई सभी बाइनरी से डीबग करने की जानकारी को अलग करते हुए टारगेट को इकट्ठा करेगा.

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

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

--stripopt=strip-option

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

--fdo_instrument=profile-output-dir

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

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

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

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

--fdo_optimize=profile-zip

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

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

दिए गए तर्क के लिए LLVM कंपाइलर को इंडेक्स किए गए LLVM प्रोफ़ाइल की आउटपुट फ़ाइल में ले जाना चाहिए. यह 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. आप local_java_repository या remote_java_repostory डेटा स्टोर करने की जगह के नियमों का इस्तेमाल करके, कस्टम JVM रजिस्टर करके मान बढ़ा सकते हैं.

--tool_java_runtime_version=version

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

--jvmopt=jvm-option

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

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

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

--javacopt=javac-option

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

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

Javas डिफ़ॉल्ट डीबग जानकारी के साथ, Java_binary बना देगा (बज़ेल डिफ़ॉल्ट के बजाय).

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

  -source 8 -target 8 -encoding UTF-8
-extra_checks[:(off|on)]

यह avac विकल्प ज़्यादा सही जाँच चालू करता है. अगर कोई समस्या मिलती है, तो उसे गड़बड़ी के तौर पर दिखाया जाएगा. चेक चालू करने के लिए -extra_checks या -extra_checks:on का इस्तेमाल किया जा सकता है. -extra_checks:off, विश्लेषण को पूरी तरह से बंद कर देता है. जब यह विकल्प नहीं दिया गया हो, तो डिफ़ॉल्ट व्यवहार का इस्तेमाल किया जाता है.

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

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

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

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

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

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

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

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

--cpu=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]*

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

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

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

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

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

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

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

--dynamic_mode=mode

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

मोड:

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

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

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

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

--force_ignore_dash_static

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

--[no]force_pic

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

--android_resource_shrinking

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

--custom_malloc=malloc-library-target

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

--crosstool_top=label

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

--host_crosstool_top=label

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

--apple_crosstool_top=label

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

--android_crosstool_top=label

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

--compiler=version

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

--android_sdk=label

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

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

--java_toolchain=label

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

--host_java_toolchain=label

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

--javabase=(label)

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

--host_javabase=label

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

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

एक्ज़ीक्यूशन की रणनीति

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

--spawn_strategy=strategy

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

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

--strategy mnemonic=strategy

यह विकल्प तय करता है कि निर्देश कहां और कैसे काम करेंगे, जिससे हर एक पर --spawn_strategy (और --genrule_strategy -नुकसान के आधार पर. काम करने वाली रणनीतियों और उनके असर के बारे में जानने के लिए --spawn_strategy देखें.

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

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

जानकारी से मेल खाने वाले आखिरी regex_filter का इस्तेमाल किया जाता है. यह विकल्प कार्यनीति निर्दिष्ट करने के लिए अन्य फ़्लैग को ओवरराइड करता है.

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

--genrule_strategy=strategy

--strategy=Genrule=strategy के लिए इसका समर्थन रोक दिया गया है.

--jobs=n (-जे)

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

--progress_report_interval=n

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

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

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

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

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

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

--[no]build_runfile_manifests

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

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

--[no]discard_analysis_cache

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

--[no]keep_going (-के)

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

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

--[no]use_ijars

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

--[no]interface_shared_objects

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

आउटपुट चुनें

ये विकल्प तय करते हैं कि क्या बनाना है या जांच करना है.

--[no]build

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

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

--[no]build_tests_only

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

--[no]check_up_to_date

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

यह भी देखें --check_tests_up_to_date.

--[no]compile_one_dependency

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

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

--save_temps

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

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

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

--build_tag_filters=tag[,tag]*

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

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

--test_size_filters=size[,size]*

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

  % bazel test --test_size_filters=small,medium //foo:all
और
  % bazel test --test_size_filters=-large,-enormous //foo:all

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

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

--test_timeout_filters=timeout[,timeout]*

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

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

--test_tag_filters=tag[,tag]*

अगर तय किया गया है, तो बैजल सिर्फ़ उन टेस्ट टारगेट की जांच करेगा (या जो --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.

अगर तय किया गया है, तो बेज़ेल सिर्फ़ तय की गई भाषा (भाषाओं) को टेस्ट करेगा(या --build_tests_onlyअगर बताया गया है, तो वह बना सकता है).

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

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

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

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

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

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

--test_filter=filter-expression

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

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

शब्दों की अधिकता

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

--explain=logfile

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

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

--verbose_explanations

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

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

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

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

--profile=file

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

--[no]show_loading_progress

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

--[no]show_progress

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

--show_progress_rate_limit=n

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

--show_result=n

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

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

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

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

--sandbox_debug

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

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

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

नीचे --verbose_failures भी देखें.

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

--verbose_failures

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

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

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

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

--workspace_status_command=program

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

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

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

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

फिर बेज़ेल मुख्य-मान की जोड़ी को दो फ़ाइलों में लिखता है:

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

अनुबंध है:

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

    बैजल हमेशा इन स्थिर कुंजियों का आउटपुट देती है:

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

    बैजल हमेशा इन वोलाटाइल बटन का आउटपुट देती है:

    • BUILD_TIMESTAMP: यूनिक्स एपिसोड के बाद से सेकंड में बिल्ड का समय (System.currentTimeMillis() के मान को एक हज़ार से भाग देने पर मिलने वाली संख्या)

Linux/macOS पर, आप फ़ाइल फ़ोल्डर की स्थिति को वापस पाने की सुविधा बंद करने के लिए --workspace_status_command=/bin/true पास कर सकते हैं. ऐसा इसलिए होता है, क्योंकि true कुछ नहीं करता, सफलतापूर्वक (शून्य के साथ बाहर निकल जाता है) और कोई आउटपुट प्रिंट नहीं करता. Windows पर, आप इसी असर के लिए एमएसवाईएस 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 नियमों के लिए डिफ़ॉल्ट) सेट करता है, तो यह विकल्प यह तय करता है कि स्टैंपिंग चालू है या नहीं.

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

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

प्लैटफ़ॉर्म

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

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

--platforms=labels

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

--host_platform=label

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

--extra_execution_platforms=labels

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

--extra_toolchains=labels

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

--toolchain_resolution_debug=regex

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

अन्य सूचनाएं

--flag_alias=alias_name=target_path

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

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

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

इस विकल्प के कुछ सामान्य मान:

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

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

--platform_suffix=string

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

--default_visibility=(private|public)

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

--[no]use_action_cache

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

--starlark_cpu_profile=_file_

यह फ़्लैग, जिसका मान किसी फ़ाइल का नाम होता है, इससे बज़ेल के सभी Starlark थ्रेड के द्वारा उपयोग किए जाने वाले CPU के आंकड़े एकत्र हो जाते हैं, और प्रोफ़ाइल pprof प्रारूप में लिखी जाती है, नामित फ़ाइल में.

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

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

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

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

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

अहम विकल्प

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

ये विकल्प भी ज़रूरी हैं:

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

जांच चल रही है

बैजल के साथ टेस्ट बनाने और चलाने के लिए, bazel test लिखें और फिर टेस्ट टारगेट का नाम लिखें.

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

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

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

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

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

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

अगर 'हां', तो कैश करने का व्यवहार अपने आप वैसा ही होगा जैसा उसे छोड़कर कैश मेमोरी में काम नहीं करता है और --runs_per_test के साथ टेस्ट चलता है.

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

--check_tests_up_to_date

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

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

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

--test_verbose_timeout_warnings

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

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

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

--[no]test_keep_going

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

--flaky_test_attempts=attempts

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

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

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

--test_summary=output_style

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

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

--test_output=output_style

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

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

--java_debug

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

--[no]verbose_test_summary

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

--test_tmpdir=path

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

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

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

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

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

--test_arg=arg

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

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

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

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

--run_under=command-prefix

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

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

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

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

उदाहरण:

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

टेस्ट चुनें

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

bazel test के लिए दूसरे विकल्प

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

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

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

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

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

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

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

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

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

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

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

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

--run_under=command-prefix

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

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

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

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

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

  % bazel clean --expunge

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

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

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

निर्भरता ग्राफ़ की क्वेरी करना

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

क्वेरी की भाषा, ग्राफ़ के आधार पर एल्गोरिदम की कार्रवाइयों के आधार पर तय की जाती है; इसके बारे में पूरी जानकारी दी गई है

Bazel Query रेफ़रंस. कृपया रेफ़रंस के लिए, दस्तावेज़ और खास निर्देश के लिए लाइन-लाइन विकल्पों के लिए उस दस्तावेज़ को देखें.

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

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

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

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

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

कार्रवाई ग्राफ़ की क्वेरी करना

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

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

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

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

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

help

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

--[no]long (-l)

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

shutdown

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

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

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

info

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

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

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

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

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

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

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

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

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

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

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

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

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

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

% bazel info server_pid
1285

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

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

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

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

  % bazel info --show_make_env -c opt COMPILATION_MODE
  opt

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

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

version और --version

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

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

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

mobile-install

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

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

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

--incremental

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

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

--split_apks

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

--start_app

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

--debug_app

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

--start=_start_type_

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

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

--adb=path

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

--android_sdk की ओर से तय किए गए Android SDK में, adb का इस्तेमाल करने का डिफ़ॉल्ट विकल्प होता है.

--adb_arg=serial

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

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

adb को

adb -s deadbeef install ...

--incremental_install_verbosity=number

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

dump

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

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

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

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

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

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

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

Java-agent को Bazel में third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar पर चेक किया जाता है, इसलिए पक्का करें कि आप अपने Bazel डेटा संग्रह स्थान को रखने के लिए $BAZEL को एडजस्ट करें.

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

उदाहरण:

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

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

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

analyze-profile

analyze-profile निर्देश, --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

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

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

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

--output_base=dir

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

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

जैसे:

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

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

--output_user_root=dir

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

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

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

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

--server_javabase=dir

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

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

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

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

--host_jvm_args=string

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

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

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

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

--host_jvm_debug

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

--autodetect_server_javabase

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

--batch

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

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

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

--max_idle_secs=n

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

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

--[no]shutdown_on_low_sys_mem

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

पर क्लिक करें. अगर सिस्टम की उपलब्ध मेमोरी बहुत कम हो जाती है, तो सर्वर बंद हो जाएगा.

--[no]block_for_lock

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

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

--io_nice_level=n

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

--batch_cpu_scheduling

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

विविध विकल्प

--[no]announce_rc

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

--color (yes|no|auto)

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

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

--config=name

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

--curses (yes|no|auto)

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

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

--[no]show_timestamps

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