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

अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है किसी समस्या की शिकायत करें सोर्स देखें रात · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

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

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

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

विकल्प

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

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

पैकेज की जगह

--package_path

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

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

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

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

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

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

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

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

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

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

--deleted_packages

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

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

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

--[no]check_visibility

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

--output_filter=regex

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

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

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

टूल फ़्लैग

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

--copt=cc-option

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

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

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

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

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

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

--host_copt=cc-option

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

--host_conlyopt=cc-option

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

--host_cxxopt=cc-option

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

--host_linkopt=linker-option

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

--conlyopt=cc-option

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

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

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

--cxxopt=cc-option

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

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

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

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

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

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

--linkopt=linker-option

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

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

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

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

--strip (always|never|sometimes)

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

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

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

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

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

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

--stripopt=strip-option

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

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

--fdo_instrument=profile-output-dir

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

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

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

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

--fdo_optimize=profile-zip

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

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

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

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

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

--java_language_version=version

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

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

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

--tool_java_language_version=version

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

--java_runtime_version=version

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

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

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

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

--tool_java_runtime_version=version

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

--jvmopt=jvm-option

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

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

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

--javacopt=javac-option

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

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

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

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

  -source 8 -target 8 -encoding UTF-8

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

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

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

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

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

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

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

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

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

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

--cpu=cpu

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

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

--action_env=VAR=VALUE

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

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

--experimental_action_listener=label

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

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

--[no]experimental_extra_action_top_level_only

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

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

--experimental_extra_action_filter=regex

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

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

यह फ़्लैग सिर्फ़ --experimental_action_listener फ़्लैग करें.

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

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

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

--host_cpu=cpu

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

--android_platforms=platform[,platform]*

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

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

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

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

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

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

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

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

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

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

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

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

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

--dynamic_mode=mode

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

मोड:

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

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

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

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

--force_ignore_dash_static

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

--[no]force_pic

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

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

--android_resource_shrinking

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

--custom_malloc=malloc-library-target

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

--crosstool_top=label

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

--host_crosstool_top=label

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

--apple_crosstool_top=label

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

--android_crosstool_top=label

चेतावनी: --android_crosstool_top अब काम नहीं करता. इसे सेट करने की ज़रूरत नहीं है.

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

--compiler=version

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

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

--android_sdk=label

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

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

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

--java_toolchain=label

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

--host_java_toolchain=label

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

--javabase=(label)

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

--host_javabase=label

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

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

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

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

--spawn_strategy=strategy

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

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

--strategy mnemonic=strategy

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

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

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

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

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

--genrule_strategy=strategy

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

--jobs=n (-जे)

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

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

--progress_report_interval=n

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

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

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

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

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

--[no]build_runfile_links

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

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

--[no]build_runfile_manifests

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

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

--[no]discard_analysis_cache

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

--[no]keep_going (-के)

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

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

--[no]use_ijars

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

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

--[no]interface_shared_objects

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

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

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

--[no]build

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

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

--[no]build_tests_only

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

--[no]check_up_to_date

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

--check_tests_up_to_date भी देखें.

--[no]compile_one_dependency

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

--save_temps

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

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

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

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

--build_tag_filters=tag[,tag]*

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

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

--test_size_filters=size[,size]*

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

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

और

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

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

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

--test_timeout_filters=timeout[,timeout]*

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

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

--test_tag_filters=tag[,tag]*

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

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

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

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

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

--test_lang_filters=string[,string]*

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

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

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

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

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

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

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

--test_filter=filter-expression

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

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

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

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

--explain=logfile

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

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

--verbose_explanations

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

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

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

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

--profile=file

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

--[no]show_loading_progress

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

--[no]show_progress

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

--show_progress_rate_limit=n

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

--show_result=n

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

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

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

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

--sandbox_debug

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

--subcommands (-s)

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

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

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

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

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

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

--verbose_failures

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

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

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

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

--workspace_status_command=program

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

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

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

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

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

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

समझौता:

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

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

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

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

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

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

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

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

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

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

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

--[no]stamp

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

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

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

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

प्लैटफ़ॉर्म

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

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

--platforms=labels

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

--host_platform=label

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

--extra_execution_platforms=labels

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

--extra_toolchains=labels

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

--toolchain_resolution_debug=regex

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

अन्य सूचनाएं

--flag_alias=alias_name=target_path

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

--symlink_prefix=string

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

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

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

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

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

--platform_suffix=string

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

--default_visibility=(private|public)

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

--starlark_cpu_profile=_file_

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

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

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

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

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

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

अहम विकल्प

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

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

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

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

चल रही जांच

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

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

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

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

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

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

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

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

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

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

--check_tests_up_to_date

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

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

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

--test_verbose_timeout_warnings

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

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

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

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

--[no]test_keep_going

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

--flaky_test_attempts=attempts

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

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

--runs_per_test=[regex@]number

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

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

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

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

--[no]runs_per_test_detects_flakes

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

--test_summary=output_style

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

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

--test_output=output_style

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

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

--java_debug

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

--[no]verbose_test_summary

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

--test_tmpdir=path

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

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

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

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

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

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

--test_arg=arg

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

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

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

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

--run_under=command-prefix

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

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

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

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

उदाहरण:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--run_under=command-prefix

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

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

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

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

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

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

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

clean निर्देश

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

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

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

  % bazel clean --expunge

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

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

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

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

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

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

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

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

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

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

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

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

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

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

चेतावनी: क्वेरी निर्देश पर अब भी प्रयोग जारी है और इसका एपीआई बदल जाएगा.

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

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

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

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

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

help

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

--[no]long (-l)

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

shutdown

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

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

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

info

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

% bazel info server_pid
1285

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

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

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

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

  % bazel info --show_make_env -c opt COMPILATION_MODE
  opt

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

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

version और --version

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

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

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

mobile-install

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

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

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

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

--incremental

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

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

--split_apks

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

--start_app

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

--debug_app

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

--start=_start_type_

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

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

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

--adb=path

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

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

--adb_arg=serial

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

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

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

adb -s deadbeef install ...

--incremental_install_verbosity=number

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

dump

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

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

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

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

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

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

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

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

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

उदाहरण:

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

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

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

analyze-profile

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

canonicalize-flags

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

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

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

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

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

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

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

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

--output_base=dir

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

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

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

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

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

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

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

--output_user_root=dir

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

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

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

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

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

--server_javabase=dir

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

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

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

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

--host_jvm_args=string

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

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

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

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

--host_jvm_debug

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

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

--autodetect_server_javabase

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

--batch

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

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

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

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

--max_idle_secs=n

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

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

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

--[no]shutdown_on_low_sys_mem

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

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

--[no]block_for_lock

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

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

--io_nice_level=n

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

--batch_cpu_scheduling

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

अन्य विकल्प

--[no]announce_rc

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

--color (yes|no|auto)

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

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

--config=name

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

--curses (yes|no|auto)

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

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

--[no]show_timestamps

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