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

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

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

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

विकल्प

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

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

पैकेज की जगह

--package_path

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

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

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

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

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

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

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

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

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

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

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

--deleted_packages

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

गड़बड़ी की जांच करना

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

--[no]check_visibility

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

--output_filter=regex

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

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

टूल फ़्लैग

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

--copt=cc-option

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

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

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

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

--host_copt=cc-option

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

--host_conlyopt=cc-option

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

--host_cxxopt=cc-option

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

--host_linkopt=linker-option

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

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

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

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

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

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

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

--stripopt=strip-option

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

--fdo_instrument=profile-output-dir

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

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

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

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

--fdo_optimize=profile-zip

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

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

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

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

--java_language_version=version

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

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

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

--tool_java_language_version=version

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

--java_runtime_version=version

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

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

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

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

--tool_java_runtime_version=version

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

--jvmopt=jvm-option

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

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

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

--javacopt=javac-option

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

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

यह java_binary को फिर से बनाएगा. इसमें javac की डिफ़ॉल्ट डीबग जानकारी होगी, न कि Bazel की डिफ़ॉल्ट जानकारी.

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

  -source 8 -target 8 -encoding UTF-8

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

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

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

सिमैंटिक बनाना

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

--compilation_mode (fastbuild|opt|dbg) (-c)

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

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

--cpu=cpu

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

--action_env=VAR=VALUE

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

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

--experimental_action_listener=label

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

--[no]experimental_extra_action_top_level_only

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

--experimental_extra_action_filter=regex

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

इस फ़्लैग का इस्तेमाल, सिर्फ़ --experimental_action_listener फ़्लैग के साथ किया जा सकता है.

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

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

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

--host_cpu=cpu

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

--android_platforms=platform[,platform]*

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

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

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

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

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

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

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

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

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

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

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

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

--dynamic_mode=mode

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

मोड:

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

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

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

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

--force_ignore_dash_static

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

--[no]force_pic

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

--android_resource_shrinking

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

--custom_malloc=malloc-library-target

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

--crosstool_top=label

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

--host_crosstool_top=label

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

--apple_crosstool_top=label

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

--compiler=version

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

--android_sdk=label

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

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

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

--java_toolchain=label

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

--host_java_toolchain=label

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

--javabase=(label)

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

--host_javabase=label

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

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

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

--spawn_strategy=strategy

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

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

--strategy mnemonic=strategy

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

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

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

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

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

--genrule_strategy=strategy

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

--jobs=n (-j)

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

--progress_report_interval=n

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

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

जब Bazel, कर्सर कंट्रोल का इस्तेमाल कर रहा होता है, तब हर सेकंड में प्रोग्रेस की जानकारी दी जाती है. इसकी जानकारी --curses में दी गई है.

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

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

--[no]build_runfile_links

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

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

--[no]build_runfile_manifests

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

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

--[no]discard_analysis_cache

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

--[no]keep_going (-k)

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

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

--[no]use_ijars

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

--[no]interface_shared_objects

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

आउटपुट चुनने का विकल्प

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

--[no]build

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

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

--[no]build_tests_only

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

--[no]check_up_to_date

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

--check_tests_up_to_date भी देखें.

--[no]compile_one_dependency

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

--save_temps

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

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

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

--build_tag_filters=tag[,tag]*

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

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

--test_size_filters=size[,size]*

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

  % 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 भी दिया गया है, तो Bazel उन टेस्ट टारगेट को बनाएगा. टेस्ट टाइमआउट फ़िल्टर को टेस्ट टाइमआउट की मान्य वैल्यू की कॉमा से अलग की गई सूची के तौर पर तय किया जाता है. जैसे, छोटा, सामान्य, लंबा या हमेशा के लिए. इसके पहले, '-' का निशान लगाया जा सकता है. इसका इस्तेमाल, टेस्ट टाइमआउट को शामिल न करने के लिए किया जाता है. उदाहरण के लिए सिंटैक्स देखने के लिए, --test_size_filters देखें.

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

--test_tag_filters=tag[,tag]*

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

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

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

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

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

--test_lang_filters=string[,string]*

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

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

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

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

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

--test_filter=filter-expression

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

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

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

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

--explain=logfile

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

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

--verbose_explanations

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

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

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

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

--profile=file

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

--[no]show_loading_progress

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

--[no]show_progress

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

--show_progress_rate_limit=n

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

--show_result=n

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

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

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

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

--sandbox_debug

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

--subcommands (-s)

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

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

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

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

नीचे दिया गया --verbose_failures विकल्प भी देखें.

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

--verbose_failures

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

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

Workspace खाते की स्थिति

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

--workspace_status_command=program

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

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

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

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

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

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

कॉन्ट्रैक्ट:

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

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

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

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

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

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

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

अगर किसी वजह से वर्कस्पेस की स्थिति की कमांड काम नहीं करती है (शून्य से बाहर निकल जाती है), तो बिल्ड नहीं हो पाएगा.

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

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

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

--[no]stamp

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

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

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

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

प्लैटफ़ॉर्म

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

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

--platforms=labels

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

--host_platform=label

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

--extra_execution_platforms=labels

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

--extra_toolchains=labels

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

--toolchain_resolution_debug=regex

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

अन्य सूचनाएं

--flag_alias=alias_name=target_path

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

--symlink_prefix=string

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

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

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

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

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

--platform_suffix=string

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

--default_visibility=(private|public)

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

--starlark_cpu_profile=_file_

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

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

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

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

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

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

अहम विकल्प

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

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

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

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

टेस्ट चलाए जा रहे हैं

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

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

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

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

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

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

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

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

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

--check_tests_up_to_date

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

इस विकल्प का मतलब --check_up_to_date भी है.

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

--test_verbose_timeout_warnings

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

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

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

--[no]test_keep_going

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

--flaky_test_attempts=attempts

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

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

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

--test_summary=output_style

इससे यह तय होता है कि टेस्ट के नतीजे की खास जानकारी कैसे दिखाई जानी चाहिए.

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

--test_output=output_style

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

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

--java_debug

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

--[no]verbose_test_summary

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

--test_tmpdir=path

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

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

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

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

जिन टेस्ट में टाइम आउट की कैटगरी को साइज़ से अलग बताया गया है उन्हें वही वैल्यू मिलेगी जो साइज़ टैग से टाइम आउट को इंप्लिसिट तौर पर सेट करने पर मिलती है. इसलिए, 'long' टाइमआउट का एलान करने वाले 'small' साइज़ के टेस्ट का टाइमआउट उतना ही होगा जितना कि 'large' साइज़ के टेस्ट का होता है. हालांकि, 'large' साइज़ के टेस्ट के लिए टाइमआउट का एलान नहीं किया जाता.

--test_arg=arg

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

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

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

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

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

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

--run_under=command-prefix

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

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

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

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

उदाहरण:

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

टेस्ट चुनना

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

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

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

एक्ज़ीक्यूटेबल फ़ाइलें चलाना

bazel run कमांड, bazel build कमांड की तरह ही होती है. हालांकि, इसका इस्तेमाल किसी एक टारगेट को बनाने और चलाने के लिए किया जाता है. यहां एक सामान्य सेशन दिया गया है (//java/myapp:myapp कहता है कि नमस्ते और अपने आर्ग्युमेंट प्रिंट करता है):

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

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

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

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

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

• BUILD_WORKSPACE_DIRECTORY: उस वर्कस्पेस का रूट जहां बिल्ड चलाया गया था.
• BUILD_WORKING_DIRECTORY: मौजूदा वर्किंग डायरेक्ट्री, जहां से Bazel को चलाया गया था.
• BUILD_ID: bazel run इनवोकेशन का बिल्ड आईडी. यह आम तौर पर यूनीक होता है. हालांकि, अगर Bazel को --script_path के साथ चलाया गया था और नतीजे वाली स्क्रिप्ट को फिर से इस्तेमाल किया जाता है, तो ऐसा नहीं होता.
• BUILD_EXECROOT: यह bazel run को शुरू करने का एक्ज़ीक्यूशन रूट है.

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

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

--run_under=command-prefix

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

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

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

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

टेस्ट लागू करना

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

बिल्ड आउटपुट को साफ़ करना

clean निर्देश

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

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

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

  % bazel clean --expunge

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

help

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

--[no]long (-l)

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

shutdown

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

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

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

info

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

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

कॉन्फ़िगरेशन से अलग डेटा

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

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

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

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

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

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

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

• command_log: कमांड लॉग फ़ाइल का पूरा पाथ; इसमें Bazel की सबसे हाल की कमांड की इंटरलीव्ड stdout और stderr स्ट्रीम शामिल होती हैं. ध्यान दें कि 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: यह कोलन से अलग किए गए पाथ की सूची होती है. Bazel, पैकेज ढूंढने के लिए इन पाथ का इस्तेमाल करता है. इसका फ़ॉर्मैट, --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 से मिली वैल्यू का इस्तेमाल करने वाली स्क्रिप्ट ज़्यादा भरोसेमंद होंगी.
• "Make" एनवायरमेंट का पूरा ऐक्सेस. अगर --show_make_env फ़्लैग तय किया गया है, तो मौजूदा कॉन्फ़िगरेशन के "मेक" एनवायरमेंट में मौजूद सभी वैरिएबल भी दिखते हैं. जैसे, CC, GLIBC_VERSION वगैरह. ये ऐसे वैरिएबल हैं जिन्हें BUILD फ़ाइलों में $(CC) या varref("CC") सिंटैक्स का इस्तेमाल करके ऐक्सेस किया जाता है.

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

  % bazel info --show_make_env -c opt COMPILATION_MODE
  opt

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

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

version और --version

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

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

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

mobile-install

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

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

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

--incremental

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

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

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

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

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

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

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

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

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

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

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

उदाहरण:

    % bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.4.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.4.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.4.jar \
    --host_jvm_args=-DRULE_MEMORY_TRACKER=1 \
    dump --skylark_memory=$HOME/prof.gz
    % pprof -flame $HOME/prof.gz

analyze-profile

analyze-profile कमांड, JSON ट्रेस प्रोफ़ाइल का विश्लेषण करती है. यह प्रोफ़ाइल, Bazel इनवोकेशन के दौरान पहले इकट्ठा की गई थी.

canonicalize-flags

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

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

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

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

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

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

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

--output_base=dir

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

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

--output_user_root=dir

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

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

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

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

--server_javabase=dir

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

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

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

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

--host_jvm_args=string

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

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

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

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

--host_jvm_debug

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

--autodetect_server_javabase

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

--batch

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

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

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

--max_idle_secs=n

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

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

--[no]shutdown_on_low_sys_mem

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

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

--[no]block_for_lock

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

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

--io_nice_level=n

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

--batch_cpu_scheduling

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

अन्य विकल्प

--[no]announce_rc

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

--color (yes|no|auto)

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

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

--config=name

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

--curses (yes|no|auto)

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

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

--[no]show_timestamps

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