इस पेज में वे विकल्प दिए गए हैं जो Basel के अलग-अलग कमांड के साथ उपलब्ध होते हैं, जैसे कि bazel build, bazel run, और bazel test. यह पेज बिल्ड with Baज़ल में Basel के कमांड की सूची का साथी है.
टारगेट सिंटैक्स
build या test जैसे कुछ निर्देश, टारगेट की सूची पर काम कर सकते हैं. उनके लिए, लेबल की तुलना में ज़्यादा सुविधाजनक सिंटैक्स का इस्तेमाल किया जाता है. इसे बनाने के लिए टारगेट तय करना सेक्शन में बताया गया है.
विकल्प
नीचे दिए सेक्शन में, बिल्ड के दौरान उपलब्ध विकल्पों के बारे में बताया गया है. जब किसी सहायता निर्देश पर --long का इस्तेमाल किया जाता है, तो ऑन-लाइन सहायता मैसेज हर विकल्प के मतलब, टाइप, और डिफ़ॉल्ट वैल्यू के बारे में खास जानकारी देता है.
ज़्यादातर विकल्प सिर्फ़ एक बार दिए जा सकते हैं. कई बार तय किए जाने पर, पिछला इंस्टेंस जीत जाता है. जिन विकल्पों को कई बार इस्तेमाल किया जा सकता है उनकी पहचान ऑन-लाइन सहायता में, 'कई बार इस्तेमाल किया जा सकता है' टेक्स्ट में की जाती है.
पैकेज की जगह
--package_path
चेतावनी: --package_path विकल्प अब काम नहीं करता. Baज़ल, डेटा स्टोर करने की मुख्य जगह में मौजूद पैकेज को फ़ाइल फ़ोल्डर रूट के तहत रखना पसंद करता है.
यह विकल्प डायरेक्ट्री के उस सेट के बारे में बताता है जिसे किसी दिए गए पैकेज की बिल्ड फ़ाइल ढूंढने के लिए खोजा जाता है.
Basel, पैकेज पाथ को खोजकर अपने पैकेज ढूंढता है. यह बेज़ल डायरेक्ट्री की क्रम वाली सूची है, जिसे कोलन से अलग किया गया है. हर डायरेक्ट्री, आंशिक सोर्स ट्री का रूट है.
--package_path विकल्प का इस्तेमाल करके, पसंद के मुताबिक पैकेज पाथ तय करने के लिए:
% bazel build --package_path %workspace%:/some/other/root
पैकेज पाथ एलिमेंट को तीन फ़ॉर्मैट में बताया जा सकता है:
- अगर पहला वर्ण
/है, तो पाथ ऐब्सलूट होता है. - अगर पाथ
%workspace%से शुरू होता है, तो पाथ को सबसे पास की बेज़ल डायरेक्ट्री के हिसाब से लिया जाता है. उदाहरण के लिए, अगर आपकी वर्किंग डायरेक्ट्री/home/bob/clients/bob_client/bazel/fooहै, तो पैकेज पाथ में स्ट्रिंग%workspace%को/home/bob/clients/bob_client/bazelतक बड़ा किया जाएगा. - बाकी सभी चीज़ों को वर्किंग डायरेक्ट्री से लिया जाता है.
आम तौर पर, यह आपकी उम्मीद के मुताबिक नहीं होता.
अगर आपने बेज़ल फ़ाइल फ़ोल्डर के नीचे की डायरेक्ट्री से Basel का इस्तेमाल किया है, तो यह उम्मीद से हटकर काम कर सकता है.
उदाहरण के लिए, अगर पैकेज-पाथ एलिमेंट
.का इस्तेमाल किया जाता है और फिर उसे/home/bob/clients/bob_client/bazel/fooडायरेक्ट्री में कॉपी किया जाता है, तो पैकेज/home/bob/clients/bob_client/bazel/fooडायरेक्ट्री से हट जाएंगे.
अगर ऐसे पैकेज पाथ का इस्तेमाल किया जाता है जो डिफ़ॉल्ट नहीं है, तो सुविधा के लिए उस पाथ के बारे में अपनी Baज़र कॉन्फ़िगरेशन फ़ाइल में बताएं.
Bazz के लिए, किसी भी पैकेज को मौजूदा डायरेक्ट्री में रखना ज़रूरी नहीं है. इसलिए, अगर सभी ज़रूरी पैकेज, पैकेज पाथ पर किसी दूसरी जगह मिल जाते हैं, तो खाली बाज़ल फ़ाइल फ़ोल्डर से बिल्ड बनाया जा सकता है.
उदाहरण: खाली क्लाइंट से बिल्डिंग बनाना
% 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 लाइब्रेरी को कंपाइल करेगा, जिससे रैंक पर निर्भर करने वाला कोड जनरेट होगा.
--host_copt=cc-option
इस विकल्प में एक आर्ग्युमेंट होता है, जिसे exec कॉन्फ़िगरेशन में कंपाइल की गई सोर्स फ़ाइलों के लिए कंपाइलर को भेजा जाता है. यह --copt विकल्प के जैसा होता है, लेकिन यह सिर्फ़ एक्ज़ीक्यूटेबल कॉन्फ़िगरेशन पर लागू होता है.
--host_conlyopt=cc-option
इस विकल्प में एक आर्ग्युमेंट होता है, जिसे exec कॉन्फ़िगरेशन में कंपाइल की गई C सोर्स फ़ाइलों के कंपाइलर को भेजा जाना चाहिए. यह --conlyopt विकल्प के जैसा होता है, लेकिन सिर्फ़ exec कॉन्फ़िगरेशन पर लागू होता है.
--host_cxxopt=cc-option
इस विकल्प में एक आर्ग्युमेंट होता है, जिसे exec कॉन्फ़िगरेशन में कंपाइल की गई C++ सोर्स फ़ाइलों के कंपाइलर को भेजा जाना है. यह --cxxopt विकल्प के जैसा होता है, लेकिन यह सिर्फ़ एक्ज़ीक्यूटेबल कॉन्फ़िगरेशन पर लागू होता है.
--host_linkopt=linker-option
इस विकल्प में एक आर्ग्युमेंट होता है, जिसे exec कॉन्फ़िगरेशन में कंपाइल की गई सोर्स फ़ाइलों के लिंकर को भेजना होता है. यह --linkopt विकल्प के जैसा होता है, लेकिन सिर्फ़ exec कॉन्फ़िगरेशन पर लागू होता है.
--conlyopt=cc-option
इस विकल्प में एक आर्ग्युमेंट होता है, जिसे C सोर्स फ़ाइलों को कंपाइल करते समय कंपाइलर को भेजा जाता है.
यह --copt की तरह है. हालांकि, यह सिर्फ़ C कंपाइलेशन पर लागू होता है, C++ कंपाइलेशन या लिंक करने पर नहीं. इसलिए, --conlyopt का इस्तेमाल करके C से जुड़े विकल्पों
(जैसे कि -Wno-pointer-sign) को पास किया जा सकता है.
--cxxopt=cc-option
इस विकल्प में एक आर्ग्युमेंट होता है, जिसे C++ सोर्स फ़ाइलों को कंपाइल करते समय कंपाइलर को भेजा जाता है.
यह --copt की तरह है. हालांकि, यह सिर्फ़ C++ कंपाइलेशन पर लागू होता है, C कंपाइलेशन या लिंक करने पर नहीं. इसलिए, C++ के खास विकल्पों
(जैसे कि -fpermissive या -fno-implicit-templates) को --cxxopt का इस्तेमाल करके पास किया जा सकता है.
उदाहरण के लिए:
% bazel build --cxxopt="-fpermissive" --cxxopt="-Wno-error" //foo/cruddy_code
--linkopt=linker-option
इस विकल्प में एक आर्ग्युमेंट होता है, जिसे लिंक करते समय कंपाइलर को भेजा जाता है.
यह --copt की तरह है, लेकिन सिर्फ़ जोड़ने पर लागू होता है, कंपाइलेशन पर नहीं. इसलिए आप --linkopt का इस्तेमाल करके कंपाइलर विकल्प पास कर सकते हैं, जो सिर्फ़ लिंक समय (जैसे कि -lssp या -Wl,--wrap,abort) पर समझ में आते हैं. उदाहरण के लिए:
% bazel build --copt="-fmudflap" --linkopt="-lmudflap" //foo/buggy_code
बिल्ड रूल की विशेषताओं में, लिंक के विकल्पों की जानकारी भी दी जा सकती है. इस विकल्प की सेटिंग को हमेशा प्राथमिकता दी जाती है. cc_library.linkopts भी देखें.
--strip (always|never|sometimes)
इस विकल्प की मदद से यह तय किया जाता है कि लिंकर को -Wl,--strip-debug विकल्प वाले विकल्प का इस्तेमाल करके, Baज़ल, सभी बाइनरी और शेयर की गई लाइब्रेरी से डीबग करने की जानकारी हटा देगा या नहीं.
--strip=always का मतलब है कि हमेशा स्ट्रिप डीबग करने की जानकारी.
--strip=never का मतलब है कि डीबग करने की जानकारी को कभी न हटाएं.
--strip=sometimes की डिफ़ॉल्ट वैल्यू का मतलब है, अगर --compilation_mode
fastbuild पर है, तो स्ट्रिप.
% bazel build --strip=always //foo:bar
जनरेट की गई सभी बाइनरी से डीबग करने की जानकारी हटाकर, टारगेट को कंपाइल कर देगा.
Basel का --strip विकल्प, ld के --strip-debug विकल्प के जैसा होता है:
यह सिर्फ़ डीबग करने की जानकारी को हटाता है. अगर किसी वजह से आपको सिर्फ़ debug सिंबल का ही नहीं,
बल्कि all सिंबल को हटाना है, तो आपको ld के --strip-all विकल्प का इस्तेमाल करना होगा.
ऐसा करने के लिए, आपको बेज़ल से --linkopt=-Wl,--strip-all पास करना होगा. यह भी ध्यान रखें कि बेज़ल का --strip फ़्लैग सेट करने से, --linkopt=-Wl,--strip-all बदल जाएगा, इसलिए आपको इनमें से सिर्फ़ एक को सेट करना चाहिए.
अगर सिर्फ़ एक बाइनरी बनाई जा रही है और आपको सभी सिंबल हटाने हैं, तो --stripopt=--strip-all को भी पास करके, टारगेट का //foo:bar.stripped वर्शन साफ़ तौर पर बनाया जा सकता है. जैसा कि --stripopt पर मौजूद सेक्शन में बताया गया है, इससे बिल्ड के सभी लिंक ऐक्शन में स्ट्रिप ऐक्शन को शामिल करने के बजाय, फ़ाइनल बाइनरी के लिंक होने के बाद स्ट्रिप ऐक्शन होता है.
--stripopt=strip-option
यह *.stripped बाइनरी जनरेट करते समय, strip कमांड को पास करने का एक और विकल्प है. डिफ़ॉल्ट वैल्यू
-S -p है. इस विकल्प का इस्तेमाल एक से ज़्यादा बार किया जा सकता है.
--fdo_instrument=profile-output-dir
बिल्ट-इन C/C++ बाइनरी के चलने पर, --fdo_instrument विकल्प एफ़डीओ (फ़ीडबैक के ज़रिए ऑप्टिमाइज़ेशन) प्रोफ़ाइल आउटपुट जनरेट करने की सुविधा चालू करता है. GCC के लिए, दिए गए तर्क का इस्तेमाल हर .o फ़ाइल की प्रोफ़ाइल जानकारी वाली .gcda फ़ाइलों के हर ऑब्जेक्ट वाली फ़ाइल डायरेक्ट्री ट्री के लिए डायरेक्ट्री प्रीफ़िक्स के तौर पर किया जाता है.
प्रोफ़ाइल डेटा ट्री जनरेट होने के बाद, प्रोफ़ाइल ट्री को ज़िप अप कर लेना चाहिए. साथ ही, एफ़डीओ के लिए ऑप्टिमाइज़ किए गए कंपाइलेशन को चालू करने के लिए, --fdo_optimize=profile-zip बेज़ल विकल्प को उपलब्ध कराना चाहिए.
एलएलवीएम कंपाइलर के लिए आर्ग्युमेंट, वह डायरेक्ट्री भी होती है जिसमें रॉ एलएलवीएम प्रोफ़ाइल का डेटा फ़ाइल(फ़ाइलें) डंप की जाती है. उदाहरण के लिए:
--fdo_instrument=/path/to/rawprof/dir/.
--fdo_instrument और --fdo_optimize विकल्पों का एक साथ इस्तेमाल नहीं किया जा सकता.
--fdo_optimize=profile-zip
--fdo_optimize विकल्प की मदद से, कंपाइल करते समय एफ़डीओ (सुझाव/राय देने या शिकायत करने से जुड़ा ऑप्टिमाइज़ेशन) ऑप्टिमाइज़ेशन के लिए, हर ऑब्जेक्ट की फ़ाइल प्रोफ़ाइल की जानकारी का इस्तेमाल किया जा सकता है. GCC के लिए, दिया गया आर्ग्युमेंट एक ऐसी ZIP फ़ाइल है जिसमें हर .o फ़ाइल की प्रोफ़ाइल की जानकारी वाली .gcda फ़ाइलों के पहले से जनरेट किए गए फ़ाइल ट्री शामिल होते हैं.
वैकल्पिक रूप से, दिया गया तर्क किसी ऐसी ऑटो प्रोफ़ाइल की ओर इशारा कर सकता है जिसे एक्सटेंशन .afdo से पहचानी गई है.
एलएलवीएम कंपाइलर के लिए दिया गया तर्क, इंडेक्स की गई उस LLVM प्रोफ़ाइल आउटपुट फ़ाइल पर ले जाता है जिसे llvm-profdata टूल से तैयार किया जाता है. साथ ही, इसमें .profdata एक्सटेंशन होना चाहिए.
--fdo_instrument और --fdo_optimize विकल्पों का एक साथ इस्तेमाल नहीं किया जा सकता.
--java_language_version=version
यह विकल्प Java सोर्स के वर्शन के बारे में बताता है. उदाहरण के लिए:
% bazel build --java_language_version=8 java/com/example/common/foo:all
सिर्फ़ Java 8 स्पेसिफ़िकेशन के साथ काम करने वाले कंस्ट्रक्शन को कंपाइल करता है और उनकी अनुमति देता है.
डिफ़ॉल्ट वैल्यू 8 है. -->
संभावित वैल्यू ये हैं: 8, 9, 10, 11, 14, 15, और 21. साथ ही, default_java_toolchain का इस्तेमाल करके कस्टम Java टूलचेन को रजिस्टर करके, इन्हें बढ़ाया जा सकता है.
--tool_java_language_version=version
Java की भाषा का वर्शन, जिसका इस्तेमाल ऐसे टूल बनाने के लिए किया जाता है जो बिल्ड के दौरान एक्ज़ीक्यूट किए जाते हैं. डिफ़ॉल्ट वैल्यू 8 है.
--java_runtime_version=version
यह विकल्प JVM के वर्शन के बारे में बताता है, ताकि कोड को एक्ज़ीक्यूट करने और टेस्ट चलाने में इसका इस्तेमाल किया जा सके. जैसे:
% bazel run --java_runtime_version=remotejdk_11 java/com/example/common/foo:java_application
रिमोट रिपॉज़िटरी से JDK 11 डाउनलोड करता है और इसका इस्तेमाल करके Java ऐप्लिकेशन चलाता है.
डिफ़ॉल्ट मान local_jdk है.
संभावित वैल्यू ये हैं: local_jdk, local_jdk_version,
remotejdk_11, और remotejdk_17.
local_java_repository या remote_java_repository डेटा स्टोर करने की जगह के नियमों का इस्तेमाल करके, कस्टम JVM को रजिस्टर करके, वैल्यू बढ़ाई जा सकती हैं.
--tool_java_runtime_version=version
जेवीएम का यह वर्शन, ऐसे टूल को एक्ज़ीक्यूट करने के लिए इस्तेमाल किया जाता है जो बिल्ड के दौरान ज़रूरी होते हैं.
डिफ़ॉल्ट मान remotejdk_11 है.
--jvmopt=jvm-option
इस विकल्प से विकल्प आर्ग्युमेंट को Java वीएम को पास किया जा सकता है. इसका इस्तेमाल किसी बड़े आर्ग्युमेंट के साथ या अलग-अलग तर्क के साथ कई बार किया जा सकता है. उदाहरण के लिए:
% bazel build --jvmopt="-server -Xms256m" java/com/example/common/foo:all
सभी Java बाइनरी लॉन्च करने के लिए, सर्वर वीएम का इस्तेमाल करेगा. साथ ही, वीएम के लिए स्टार्टअप हीप साइज़ को 256 एमबी पर सेट करेगा.
--javacopt=javac-option
इस विकल्प से विकल्प आर्ग्युमेंट को javac पर भेजा जा सकता है. इसका इस्तेमाल किसी बड़े आर्ग्युमेंट के साथ या अलग-अलग तर्क के साथ कई बार किया जा सकता है. उदाहरण के लिए:
% bazel build --javacopt="-g:source,lines" //myprojects:prog
javac डिफ़ॉल्ट डीबग जानकारी (बेज़ल डिफ़ॉल्ट के बजाय) के साथ java_binary को फिर से बनाएगा.
इस विकल्प को javac के लिए बेज़ल बिल्ट-इन डिफ़ॉल्ट विकल्पों के बाद और प्रति नियम विकल्पों के पहले javac पर पास किया जाता है. JavaScript के किसी भी विकल्प की आखिरी जानकारी. javac के लिए डिफ़ॉल्ट विकल्प ये हैं:
-source 8 -target 8 -encoding UTF-8
--strict_java_deps (default|strict|off|warn|error)
यह विकल्प कंट्रोल करता है कि javac, सीधे तौर पर उन डिपेंडेंसी के लिए जांच करता है या नहीं जो मौजूद नहीं हैं. Java टारगेट को, सीधे तौर पर इस्तेमाल किए जाने वाले सभी टारगेट को डिपेंडेंसी के तौर पर साफ़ तौर पर बताना चाहिए. यह फ़्लैग javac को यह पता लगाने का निर्देश देता है कि हर java फ़ाइल की जांच करने के लिए इस्तेमाल किए गए जार का पता कैसे लगाया जाए. साथ ही, अगर वे मौजूदा टारगेट से सीधे तौर पर निर्भरता का आउटपुट नहीं हैं, तो चेतावनी/गड़बड़ी को निर्देश देता है.
offका मतलब है कि जांच करने की सुविधा बंद है.warnका मतलब है कि javac, हर उस डायरेक्ट डिपेंडेंसी के लिए[strict]टाइप की स्टैंडर्ड JavaScript चेतावनियां जनरेट करेगा जो मौजूद नहीं हैं.default,strict, औरerrorसभी मतलब javac, चेतावनियों के बजाय गड़बड़ियां जनरेट करेंगे. इससे, कोई भी छूटी हुई डायरेक्ट डिपेंडेंसी मिलने पर मौजूदा टारगेट बनने में मदद मिलेगी. फ़्लैग के अनिर्दिष्ट होने पर भी यह डिफ़ॉल्ट व्यवहार होता है.
सिमेंटिक्स बनाएं
ये विकल्प, बिल्ड कमांड और/या आउटपुट फ़ाइल के कॉन्टेंट पर असर डालते हैं.
--compilation_mode (fastbuild|opt|dbg) (-सी)
--compilation_mode विकल्प (इसे अक्सर -c भी छोटा किया जाता है, खास तौर पर -c opt), fastbuild, dbg या opt का तर्क लेता है. इससे C/C++ कोड-जनरेशन के कई विकल्पों पर असर पड़ता है. जैसे, ऑप्टिमाइज़ेशन का लेवल और डीबग टेबल पूरी तरह से काम करना. Baज़ल, कंपाइलेशन मोड के लिए एक अलग आउटपुट डायरेक्ट्री का इस्तेमाल करता है, ताकि आप हर बार पूरा रीबिल्ड करने की ज़रूरत के बिना, एक मोड से दूसरे मोड पर स्विच कर सकें.
fastbuildका मतलब है कि फ़ाइलों को जल्द से जल्द बनाएं: डीबग करने की कम से कम जानकारी (-gmlt -Wl,-S) जनरेट करें और ऑप्टिमाइज़ न करें. यह डिफ़ॉल्ट सेटिंग है. ध्यान दें:-DNDEBUGको सेट नहीं किया जाएगा.dbgका मतलब है कि डीबग करने की सुविधा चालू करके बनाया गया (-g), ताकि आप gdb (या किसी दूसरे डीबगर) का इस्तेमाल कर सकें.optका मतलब है कि ऐसे बिल्ड में ऑप्टिमाइज़ेशन चालू है औरassert()कॉल बंद है (-O2 -DNDEBUG). डीबग करने की जानकारी,optमोड में तब तक जनरेट नहीं होगी, जब तक कि आप--copt -gको पास नहीं कर लेते.
--cpu=cpu
यह विकल्प, बिल्ड के दौरान बाइनरी को कंपाइल करने के लिए इस्तेमाल किया जाने वाला टारगेट सीपीयू आर्किटेक्चर तय करता है.
--action_env=VAR=VALUE
सभी कार्रवाइयों को पूरा करने के दौरान उपलब्ध एनवायरमेंट वैरिएबल का सेट तय करता है.
वैरिएबल को या तो नाम से तय किया जा सकता है. इस स्थिति में वैल्यू को
इनवोकेशन एनवायरमेंट से लिया जाएगा या
name=value पेयर से लिया जाएगा, जो वैल्यू को
इनवॉइस के एनवायरमेंट से अलग सेट करता है.
इस --action_env फ़्लैग को एक से ज़्यादा बार बताया जा सकता है. अगर कई --action_env फ़्लैग में एक ही वैरिएबल के लिए कोई वैल्यू असाइन की जाती है, तो सबसे नया असाइनमेंट जीत जाएगा.
--experimental_action_listener=label
experimental_action_listener विकल्प, बेज़ल को बिल्ड ग्राफ़ में extra_actions डालने के लिए label के बताए गए action_listener नियम की जानकारी का इस्तेमाल करने का निर्देश देता है.
--[no]experimental_extra_action_top_level_only
अगर इस विकल्प को 'सही है' पर सेट किया जाता है, तो --experimental_action_listener कमांड लाइन विकल्प से मिलने वाली अतिरिक्त कार्रवाइयां, सिर्फ़ टॉप लेवल के टारगेट के लिए शेड्यूल की जाएंगी.
--experimental_extra_action_filter=regex
experimental_extra_action_filter विकल्प बेज़ल को, टारगेट के उस सेट को फ़िल्टर करने का निर्देश देता है जिसके लिए, extra_actions को शेड्यूल करना है.
यह फ़्लैग सिर्फ़ --experimental_action_listener फ़्लैग के साथ लागू होता है.
अनुरोध किए गए टारगेट-टू-बिल्ड को अस्थायी तौर पर बंद होने की स्थिति में, सभी extra_actions डिफ़ॉल्ट रूप से, एक्ज़ीक्यूशन के लिए शेड्यूल हो जाते हैं.
--experimental_extra_action_filter, शेड्यूल को extra_actions तक सीमित कर देगा, जिसमें से मालिक का लेबल बताए गए रेगुलर एक्सप्रेशन से मेल खाता है.
नीचे दिए गए उदाहरण में, extra_actions को शेड्यूल करने की प्रोसेस को सिर्फ़ उन कार्रवाइयों पर लागू करने के लिए सीमित किया गया है जिनमें मालिक के लेबल में '/bar/' शामिल है:
% bazel build --experimental_action_listener=//test:al //foo/... \ --experimental_extra_action_filter=.*/bar/.*
--host_cpu=cpu
यह विकल्प उस सीपीयू आर्किटेक्चर के नाम के बारे में बताता है जिसका इस्तेमाल होस्ट टूल बनाने के लिए किया जाना चाहिए.
--android_platforms=platform[,platform]*
वे प्लैटफ़ॉर्म जिन्हें android_binary नियम के लिए deps का ट्रांज़िशन बनाना है (खास तौर पर C++ जैसी नेटिव डिपेंडेंसी के लिए). उदाहरण के लिए, अगर कोई cc_library android_binary नियम के ट्रांज़िटिव deps में दिखता है, तो android_binary नियम के लिए --android_platforms की मदद से तय किए गए हर प्लैटफ़ॉर्म के लिए एक बार बनाया जाएगा और फ़ाइनल आउटपुट में शामिल किया जाएगा.
इस फ़्लैग के लिए कोई डिफ़ॉल्ट वैल्यू नहीं है: कस्टम Android प्लैटफ़ॉर्म तय करना और उसका इस्तेमाल करना ज़रूरी है.
--android_platforms में बताए गए हर प्लैटफ़ॉर्म के लिए, एक .so फ़ाइल बनाई और पैकेज की जाती है. .so फ़ाइल के नाम के शुरू में android_binary नियम के नाम से पहले "lib" होता है. उदाहरण के लिए, अगर android_binary का नाम "foo" है, तो फ़ाइल libfoo.so है.
--per_file_copt=[+-]regex[,[+-]regex]...@option[,option]...
अगर कोई C++ फ़ाइल मौजूद है, तो दिए गए विकल्पों के साथ उसे बना दिया जाएगा. लेबल या एक्ज़ीक्यूशन पाथ वाली कोई भी C++ फ़ाइल, जो शामिल किए गए किसी रेगुलर एक्सप्रेशन
एक्सप्रेशन से मेल खाती है और जो किसी भी एक्सक्लूज़न एक्सप्रेशन से मेल नहीं खाती. लेबल का मिलान करने के लिए, लेबल के कैननिकल फ़ॉर्मैट का इस्तेमाल किया जाता है.
(जैसे, //package:label_name).
एक्ज़ीक्यूशन पाथ, आपकी वर्कस्पेस डायरेक्ट्री का मिलता-जुलता पाथ होता है. इसमें, C++ फ़ाइल का बेस नाम (इसमें एक्सटेंशन भी शामिल है) भी शामिल होता है. इसमें प्लैटफ़ॉर्म डिपेंडेंट प्रीफ़िक्स भी शामिल हैं.
जनरेट की गई फ़ाइलों (जैसे कि सामान्य आउटपुट) का मिलान करने के लिए,
Baze सिर्फ़ एक्ज़ीक्यूशन पाथ का इस्तेमाल कर सकता है. इस मामले में, regexp को '//' से शुरू नहीं होना चाहिए
क्योंकि यह किसी भी एक्ज़ीक्यूशन पाथ से मेल नहीं खाता. पैकेज के नाम इस तरह इस्तेमाल किए जा सकते हैं:
--per_file_copt=base/.*\.pb\.cc@-g0. यह base नाम की डायरेक्ट्री में मौजूद हर .pb.cc फ़ाइल से मेल खाएगा.
इस विकल्प का इस्तेमाल एक से ज़्यादा बार किया जा सकता है.
कंपाइलेशन मोड का इस्तेमाल किए बिना, यह विकल्प लागू किया जाता है. उदाहरण के लिए, --compilation_mode=opt की मदद से कुछ फ़ाइलों को कंपाइल किया जा सकता है और बेहतर ऑप्टिमाइज़ेशन चालू करके या ऑप्टिमाइज़ेशन बंद करके कुछ फ़ाइलों को चुनकर चुनिंदा फ़ाइलों को कंपाइल किया जा सकता है.
चेतावनी: अगर कुछ फ़ाइलों को डीबग सिंबल के साथ कंपाइल किया जाता है, तो लिंक करते समय सिंबल हटाए जा सकते हैं. इसे --strip=never सेट करके रोका जा सकता है.
सिंटैक्स: [+-]regex[,[+-]regex]...@option[,option]... जहां
regex का मतलब रेगुलर एक्सप्रेशन है. इसे शामिल करने वाले पैटर्न की पहचान करने के लिए, + के शुरू में प्रीफ़िक्स लगाया जा सकता है. साथ ही, बाहर रखे गए पैटर्न की पहचान करने के लिए, - का इस्तेमाल किया जा सकता है. option का मतलब आर्बिट्रेरी विकल्प है, जो C++ कंपाइलर को पास किया जाता है. अगर विकल्प में , है, तो उसे इस तरह कोट करना चाहिए
\,. विकल्पों में @ भी शामिल हो सकता है, क्योंकि रेगुलर एक्सप्रेशन को विकल्पों से अलग करने के लिए सिर्फ़ पहले @ का इस्तेमाल किया जाता है.
उदाहरण:
--per_file_copt=//foo:.*\.cc,-//foo:file\.cc@-O0,-fprofile-arcs
यह //foo/ में मौजूद सभी .cc फ़ाइलों के लिए, C++ कंपाइलर की कमांड लाइन में -O0 और -fprofile-arcs विकल्पों को जोड़ता है. हालांकि, इसके लिए file.cc विकल्प शामिल नहीं किए जाते.
--dynamic_mode=mode
इससे यह तय होता है कि बिल्ड के नियमों पर linkstatic एट्रिब्यूट के साथ इंटरैक्ट करते हुए, C++ बाइनरी को डाइनैमिक रूप से लिंक किया जाएगा या नहीं.
मोड:
default: इसकी मदद से, बैज डाइनैमिक है कि उसे डाइनैमिक तरीके से लिंक करना है या नहीं. ज़्यादा जानकारी के लिए linkstatic देखें.fully: सभी टारगेट को डाइनैमिक तौर पर लिंक करता है. इससे, लिंक करने का समय कम हो जाएगा और बाइनरी का साइज़ कम हो जाएगा.off: ज़्यादातर स्टैटिक मोड में सभी टारगेट को लिंक करता है. अगर-staticको लिंकऑप्ट में सेट किया गया है, तो टारगेट पूरी तरह से स्टैटिक में बदल जाएंगे.
--fission (yes|no|[dbg][,opt][,fastbuild])
Fission को चालू करता है. यह .o फ़ाइलों के बजाय, खास .dwo फ़ाइलों पर C++ डीबग की जानकारी को लिखता है. ऐसा करने पर लिंक का साइज़ कम हो जाता है और लिंक होने का समय कम हो जाता है.
अगर नीति को [dbg][,opt][,fastbuild] (उदाहरण:
--fission=dbg,fastbuild) पर सेट किया जाता है, तो सिर्फ़ कंपाइलेशन मोड के चुनिंदा सेट के लिए ही Fission चालू होता है. यह bazzrc सेटिंग के लिए
काम का है. yes पर सेट करने पर, Fission की सुविधा हर समय चालू रहती है. no पर सेट करने पर, Fission की सुविधा हमेशा के लिए बंद रहती है. डिफ़ॉल्ट वैल्यू no है.
--force_ignore_dash_static
अगर यह फ़्लैग सेट है, तो cc_* नियमों के लिंकऑप्ट में मौजूद किसी भी -static विकल्प को अनदेखा कर दिया जाता है. यह सिर्फ़ C++ के मज़बूत बिल्ड
के लिए एक उपाय के तौर पर है.
--[no]force_pic
इस सुविधा को चालू करने पर, सभी C++ कंपाइलेशन, पोज़िशन-इंडिपेंडेंट कोड ("-fPIC") बनाते हैं. लिंक, गैर-PIC लाइब्रेरी के बजाय PIC के पहले से बनी लाइब्रेरी को प्राथमिकता देते हैं, और लिंक, रैंक के हिसाब से अलग-अलग एक्ज़ीक्यूटेबल ("-pie") बनाते हैं. डिफ़ॉल्ट तौर पर बंद है.
--android_resource_shrinking
चुनें कि क्या android_binary नियमों के लिए रिसॉर्स को छोटा करने की कार्रवाई करनी है. android_binary के नियमों पर shrink_resources एट्रिब्यूट को डिफ़ॉल्ट के तौर पर सेट करता है. ज़्यादा जानकारी के लिए, उस नियम का दस्तावेज़ देखें. डिफ़ॉल्ट रूप से बंद होती है.
--custom_malloc=malloc-library-target
जब कहा जाए, तब सभी malloc="target" एट्रिब्यूट को बदलकर हमेशा दिए गए मैलोक तरीके का इस्तेमाल करें. इनमें वे टारगेट भी शामिल हैं जो डिफ़ॉल्ट का इस्तेमाल करते हैं (किसी malloc की जानकारी नहीं देकर).
--crosstool_top=label
यह विकल्प, क्रॉसटूल कंपाइलर सुइट की जगह की जानकारी देता है. इसका इस्तेमाल, बिल्ड के दौरान सभी C++ कंपाइलेशन के लिए किया जाएगा. Basel, किसी CROSSTOOL फ़ाइल के लिए उस जगह पर खोजेगा और उसका इस्तेमाल
--compiler की सेटिंग को अपने-आप तय करने के लिए करेगा.
--host_crosstool_top=label
अगर इसके बारे में नहीं बताया गया है, तो Basel, एक्ज़ीक्यूटेबल कॉन्फ़िगरेशन में कोड को कंपाइल करने के लिए --crosstool_top वैल्यू का इस्तेमाल करता है, जैसे कि बिल्ड के दौरान चलने वाले टूल. इस फ़्लैग का मुख्य मकसद क्रॉस-कंपाइलेशन को चालू करना है.
--apple_crosstool_top=label
objc*, ios*, और apple* नियमों के ट्रांज़िटिव deps में C/C++ के नियमों को कंपाइल करने के लिए इस्तेमाल किया जाने वाला क्रॉसटूल. उन टारगेट के लिए, यह फ़्लैग --crosstool_top को बदल देता है.
--compiler=version
यह विकल्प, C/C++ कंपाइलर वर्शन (जैसे कि gcc-4.1.0) के बारे में बताता है. बिल्ड के दौरान बाइनरी को कंपाइल करने के लिए इसका इस्तेमाल किया जाता है. अगर आपको कस्टम क्रॉसटूल का इस्तेमाल करना है, तो इस फ़्लैग के बारे में बताने के बजाय, CROSSTOOL फ़ाइल का इस्तेमाल करें.
--android_sdk=label
समर्थन नहीं होना या रुकना. इसे सीधे तौर पर तय नहीं किया जाना चाहिए.
इस विकल्प से Android SDK/प्लैटफ़ॉर्म टूलचेन और Android रनटाइम लाइब्रेरी के बारे में पता चलता है, जिनका इस्तेमाल Android से जुड़े किसी भी नियम को बनाने के लिए किया जाएगा.
अगर workspace फ़ाइल में android_sdk_repository नियम तय किया जाता है, तो Android SDK अपने-आप चुन लिया जाएगा.
--java_toolchain=label
नहीं, सिर्फ़ पुराने सिस्टम के साथ काम करने की सुविधा के लिए रखा गया.
--host_java_toolchain=label
नहीं, सिर्फ़ पुराने सिस्टम के साथ काम करने की सुविधा के लिए रखा गया.
--javabase=(label)
नहीं, सिर्फ़ पुराने सिस्टम के साथ काम करने की सुविधा के लिए रखा गया.
--host_javabase=label
नहीं, सिर्फ़ पुराने सिस्टम के साथ काम करने की सुविधा के लिए रखा गया.
प्लान लागू करने की रणनीति
इन विकल्पों से इस बात पर असर पड़ता है कि 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'कंपाइलिंग //foo/bar/baz' कोsandboxedरणनीति के साथ चलाता है, लेकिन ऑर्डर को रिवर्स करने पर वहlocalपर चलता है. - उदाहरण:
--strategy_regexp='Compiling.*/bar=local,sandboxed',localरणनीति के साथ 'कंपाइलिंग //foo/bar/baz' को चलाता है और अगर यह काम नहीं करता है, तो वापसsandboxedपर चला जाता है.
--genrule_strategy=strategy
यह --strategy=Genrule=strategy के लिए काम न करने वाला शॉर्ट-हैंड है.
--jobs=n (-जे)
यह विकल्प एक पूर्णांक तर्क लेता है. इससे उन जॉब की संख्या की सीमा तय होती है जिन्हें बिल्ड पूरा करने के दौरान एक साथ लागू किया जाना चाहिए.
--progress_report_interval=n
बेज़ल समय-समय पर ऐसी प्रोग्रेस रिपोर्ट को प्रिंट करता है जो अभी तक पूरी नहीं हुई हैं (जैसे, लंबे समय तक चल रही टेस्ट). इस विकल्प से, रिपोर्टिंग की फ़्रीक्वेंसी सेट की जाती है. प्रोग्रेस, हर n सेकंड में प्रिंट होगी.
डिफ़ॉल्ट रूप से 0 होता है, इसका मतलब है कि इंक्रीमेंटल एल्गोरिदम: पहली रिपोर्ट 10 सेकंड के बाद प्रिंट की जाएगी. इसके बाद, 30 सेकंड और इसके बाद, हर मिनट में एक बार रिपोर्ट की जाएगी.
जब बैज, --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) लिया जाता है.
फ़्लैग अलग-अलग होते हैं; इनमें से एक या दोनों को सेट किया जा सकता है. डिफ़ॉल्ट रूप से, Baज़र, लोकल सिस्टम के कॉन्फ़िगरेशन से सीधे
रैम की मात्रा और सीपीयू कोर की संख्या का अनुमान लगाता है.
--[no]build_runfile_links
यह विकल्प डिफ़ॉल्ट रूप से चालू होता है. इससे पता चलता है कि टेस्ट और बाइनरी के लिए रनफ़ाइल सिमलिंक, आउटपुट डायरेक्ट्री में बनाए जाने चाहिए या नहीं.
--nobuild_runfile_links का इस्तेमाल करके, यह पुष्टि की जा सकती है कि रनफ़ाइल ट्री बनाने के लिए, सभी टारगेट, ओवरहेड के बिना कंपाइल होते हैं या नहीं.
जब टेस्ट या ऐप्लिकेशन लागू किए जाते हैं, तो उनके रन-टाइम डेटा
डिपेंडेंसी को एक साथ एक ही जगह पर इकट्ठा किया जाता है. बेज़ल के आउटपुट ट्री में, यह "रनफ़ाइल" ट्री आम तौर पर उस बाइनरी या टेस्ट के सिबलिंग के तौर पर होता है.
जांच के दौरान, रनफ़ाइल को $TEST_SRCDIR/workspace/packagename/filename फ़ॉर्म के पाथ का इस्तेमाल करके ऐक्सेस किया जा सकता है.
रनफ़ाइल ट्री यह पक्का करता है कि जांच के पास उन सभी फ़ाइलों का ऐक्सेस हो
जिन पर वह तय की गई डिपेंडेंसी है, कोई और फ़ाइल नहीं. डिफ़ॉल्ट रूप से, रनफ़ाइल ट्री को ज़रूरी फ़ाइलों के सिम्बॉलिक लिंक का एक सेट बनाकर लागू किया जाता है. जैसे-जैसे लिंक का सेट बढ़ता है, वैसे-वैसे इस कार्रवाई में खर्च भी बढ़ता है. कुछ बड़े बिल्ड का कुल समय भी काफ़ी बढ़ सकता है. ऐसा खास तौर पर इसलिए होता है, क्योंकि हर एक टेस्ट (या ऐप्लिकेशन) के लिए उसका अपना रनफ़ाइल ट्री होता है.
--[no]build_runfile_manifests
यह विकल्प डिफ़ॉल्ट रूप से चालू होता है. इससे पता चलता है कि रनफ़ाइल मेनिफ़ेस्ट को आउटपुट ट्री में लिखा जाना चाहिए या नहीं.
इसे बंद करने पर --nobuild_runfile_links लागू होगी.
टेस्ट को रिमोट तरीके से एक्ज़ीक्यूट करते समय, इस सुविधा को बंद किया जा सकता है. इसकी वजह यह है कि रनफ़ाइल ट्री, मेमोरी में मौजूद मेनिफ़ेस्ट की मदद से दूर से बनाए जाते हैं.
--[no]discard_analysis_cache
इस विकल्प को चालू करने पर, Baज़ल, विश्लेषण शुरू होने से ठीक पहले विश्लेषण की कैश मेमोरी को खारिज कर देगा. इससे, लागू करने के चरण के लिए अतिरिक्त मेमोरी (करीब 10%) खाली हो जाएगी. हालांकि, इसकी कमी यह है कि आने वाले समय में बिल्ड ज़्यादा समय लेने वाले होते हैं. मेमोरी सेव करने वाला मोड भी देखें.
--[no]keep_going (-के)
GNU Make की तरह ही, पहली गड़बड़ी मिलने पर बिल्ड को प्रोसेस करना बंद हो जाता है. कभी-कभी गड़बड़ियों का सामना करने पर भी जितना हो सके उतना बेहतर बनाने की कोशिश करना फ़ायदेमंद होता है. इस विकल्प से यह सुविधा चालू होती है. इसके बारे में तय किए जाने पर बिल्ड हर उस टारगेट को बनाने की कोशिश करेगा, जिसके लिए ज़रूरी शर्तें पूरी हो गई थीं. हालांकि, यह गड़बड़ियों को अनदेखा करेगा.
आम तौर पर, यह विकल्प बिल्ड के एक्ज़ीक्यूशन के चरण से जुड़ा होता है, लेकिन इससे विश्लेषण के चरण पर भी असर पड़ता है: अगर बिल्ड कमांड में कई टारगेट तय किए गए हों, लेकिन उनमें से सिर्फ़ कुछ का विश्लेषण पूरा हो सके, तो बिल्ड तब तक गड़बड़ी के साथ बंद रहेगा, जब तक --keep_going के बारे में नहीं बताया जाता. इस स्थिति में बिल्ड, एक्ज़ीक्यूशन के चरण में जाएगा. हालांकि, सिर्फ़ उन टारगेट के लिए बिल्ड का सही तरीके से विश्लेषण किया जाएगा.
--[no]use_ijars
इस विकल्प को चुनने से, java_library के टारगेट को कंपाइल करने का तरीका बेज़ल से बदल जाता है. डिपेंडेंट टारगेट को कंपाइल करने के लिए java_library के आउटपुट का इस्तेमाल करने के बजाय, बेज़ल ऐसे इंटरफ़ेस जार बनाएगा जिनमें सिर्फ़ गैर-निजी सदस्यों (सार्वजनिक, सुरक्षित, और डिफ़ॉल्ट (पैकेज) ऐक्सेस के तरीकों और फ़ील्ड) के हस्ताक्षर शामिल हों. साथ ही, डिपेंडेंट टारगेट को कंपाइल करने के लिए इंटरफ़ेस जार का इस्तेमाल करें.java_library ऐसा करने से, जब सिर्फ़ तरीके के निकायों या क्लास के प्राइवेट सदस्यों में बदलाव किए जाते हैं, तो उन्हें फिर से कंपाइल करने से रोका जा सकता है.
--[no]interface_shared_objects
इस विकल्प से इंटरफ़ेस शेयर किए गए ऑब्जेक्ट चालू होता है. इससे बाइनरी और शेयर की गई अन्य लाइब्रेरी, लागू करने के बजाय, शेयर किए गए ऑब्जेक्ट के इंटरफ़ेस पर निर्भर होती हैं. सिर्फ़ लागू करने के तरीके में बदलाव होने पर, Basel बिना किसी वजह के बदली हुई शेयर की गई लाइब्रेरी पर निर्भर टारगेट को फिर से बनाने से बच सकता है.
आउटपुट चुनने की सुविधा
इन विकल्पों से यह तय होता है कि क्या बनाना है या क्या टेस्ट करना है.
--[no]build
इस विकल्प की वजह से बिल्ड पूरा होता है. यह डिफ़ॉल्ट रूप से चालू होता है. इसे बंद करने पर, एक्ज़ीक्यूशन का चरण स्किप हो जाता है. इससे, सिर्फ़ पहले दो चरण, लोड और विश्लेषण होते हैं.
यह विकल्प, BUILD फ़ाइलों की पुष्टि करने और इनपुट में गड़बड़ियों का पता लगाने के लिए काम का है. इसके लिए, कोई सिस्टम बनाने की ज़रूरत नहीं है.
--[no]build_tests_only
अगर बताया गया है, तो Basel सिर्फ़ वही नियम बनाएगा जो *_test और test_suite के नियमों को लागू करने के लिए ज़रूरी हैं. इन नियमों को उनके साइज़, टाइम आउट, टैग या भाषा की वजह से फ़िल्टर नहीं किया गया है.
अगर बताया गया है, तो Baज़र, कमांड लाइन पर तय किए गए अन्य टारगेट को अनदेखा कर देगा.
डिफ़ॉल्ट रूप से, यह विकल्प बंद रहता है और Basel के लिए अनुरोध किया गया हर कॉन्टेंट तैयार होता है. इसमें *_test और test_suite नियम भी शामिल हैं, जिन्हें टेस्टिंग से फ़िल्टर करके बाहर कर दिया गया है. यह काम का है, क्योंकि शायद bazel test --build_tests_only foo/... चलाने से foo ट्री के सभी बिल्ड ब्रेकेज का पता नहीं चल पा रहा है.
--[no]check_up_to_date
इस विकल्प की वजह से बेज़ल बिल्ड पूरा नहीं करता. हालांकि, सिर्फ़ यह जांच करते हैं कि बताए गए सभी टारगेट अप-टू-डेट हैं या नहीं. अगर ऐसा है, तो बिल्ड हमेशा की तरह पूरा हो जाता है. हालांकि, अगर कोई फ़ाइल पुरानी है, तो उसे बनाने के बजाय गड़बड़ी की रिपोर्ट की जाती है और बिल्ड फ़ेल हो जाता है. इस विकल्प से यह पता लगाया जा सकता है कि बिल्ड को, सोर्स में किए गए बदलाव (उदाहरण के लिए, पहले से सबमिट की जांच) की तुलना में हाल ही में किया गया है या नहीं. ऐसा करने के लिए, बिल्ड की लागत नहीं देनी पड़ती.
--check_tests_up_to_date भी देखें.
--[no]compile_one_dependency
आर्ग्युमेंट फ़ाइलों की एक डिपेंडेंसी कंपाइल करें. यह IDE में सोर्स फ़ाइलों की जांच करने के लिए मददगार है. उदाहरण के लिए, एक ऐसा टारगेट फिर से बनाकर जो सोर्स फ़ाइल पर निर्भर है, ताकि एडिट/बिल्ड/टेस्ट साइकल में गड़बड़ियों का जल्द से जल्द पता लगाया जा सके. यह आर्ग्युमेंट, बिना फ़्लैग वाले सभी आर्ग्युमेंट के इंटरप्रेट करने के तरीके पर असर डालता है: हर आर्ग्युमेंट, फ़ाइल टारगेट लेबल होना चाहिए या मौजूदा डायरेक्ट्री का सादा फ़ाइल नाम होना चाहिए. साथ ही, हर सोर्स फ़ाइल के नाम पर निर्भर एक नियम बनाया जाना चाहिए. C++ और Java सोर्स के लिए, एक ही भाषा के स्पेस वाले नियमों को प्राथमिकता दी जाती है. एक ही प्राथमिकता वाले कई नियमों के लिए, बिल्ड फ़ाइल में सबसे पहले दिखने वाला नियम चुना जाता है. साफ़ तौर पर नाम वाला ऐसा टारगेट पैटर्न जो किसी सोर्स फ़ाइल का रेफ़रंस नहीं देता है, उससे गड़बड़ी होती है.
--save_temps
--save_temps विकल्प की वजह से, कंपाइलर के अस्थायी आउटपुट सेव होते हैं. इनमें .s फ़ाइलें (असेंबलर कोड), .i (पहले से प्रोसेस की गई C) और .ii
(पहले से प्रोसेस की गई C++) फ़ाइलें शामिल हैं. ये आउटपुट अक्सर डीबग करने के लिए मददगार होते हैं. तापमान सिर्फ़ कमांड लाइन पर तय किए गए टारगेट के सेट के लिए जनरेट किए जाएंगे.
फ़िलहाल, --save_temps फ़्लैग सिर्फ़ cc_* नियमों के लिए काम करता है.
यह पक्का करने के लिए कि Baज़र, अतिरिक्त आउटपुट फ़ाइलों की जगह को प्रिंट करे, देखें कि आपकी --show_result n सेटिंग ज़रूरत के मुताबिक है या नहीं.
--build_tag_filters=tag[,tag]*
अगर तय किया गया है, तो Baze सिर्फ़ ऐसे टारगेट बनाएगा जिनमें कम से कम एक ज़रूरी टैग (अगर उनमें से किसी के बारे में बताया गया हो) और शामिल न किया गया कोई भी टैग न हो. बिल्ड टैग फ़िल्टर का इस्तेमाल, टैग कीवर्ड की कॉमा-डीलिमिटेड सूची के तौर पर किया जाता है. वैकल्पिक रूप से, इसे '-' चिह्न से पहले इस्तेमाल किया जाता है. इससे बाहर रखे गए टैग को दिखाया जाता है. ज़रूरी टैग में '+' का निशान पहले से हो सकता है.
टेस्ट चलाते समय, 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" स्ट्रिंग का इस्तेमाल करें. Baज़ल, सिर्फ़ रेफ़र किए गए नियम क्लास को टारगेट करके टेस्ट करेगा या अगर --build_tests_only भी तय किया गया है, तो बिल्ड करेगा. उन टारगेट को बाहर रखने के बजाय, "-foo" स्ट्रिंग का इस्तेमाल करें. उदाहरण के लिए,
% bazel test --test_lang_filters=foo,bar //baz/...
सिर्फ़ उन टारगेट की जांच करेगा जो //baz/... में foo_test या bar_test के उदाहरण हैं. हालांकि,
% bazel test --test_lang_filters=-foo,-bar //baz/...
foo_test और
bar_test इंस्टेंस को छोड़कर, //baz/... में मौजूद सभी टारगेट की जांच करेगा.
--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 निर्देश अपना समय कहां खर्च कर रहा है.
--[no]show_loading_progress
इस विकल्प से Baज़ल, पैकेज लोड होने की प्रोग्रेस का मैसेज दिखाता है. अगर यह बंद है, तो मैसेज नहीं दिखाए जाएंगे.
--[no]show_progress
इस विकल्प से प्रोग्रेस से जुड़े मैसेज दिखते हैं. यह डिफ़ॉल्ट रूप से चालू रहता है. इस सुविधा के बंद होने पर, प्रोग्रेस से जुड़े मैसेज नहीं दिख रहे हैं.
--show_progress_rate_limit=n
इस विकल्प की मदद से, बेज़ल हर n सेकंड में ज़्यादा से ज़्यादा एक प्रोग्रेस मैसेज दिखाएगा, जिसमें n एक असली संख्या है.
इस विकल्प की डिफ़ॉल्ट वैल्यू 0.02 है. इसका मतलब है कि baaz हर 0.02 सेकंड में, प्रोग्रेस से जुड़े मैसेज को एक तक सीमित कर देगा.
--show_result=n
इस विकल्प से bazel build कमांड के आखिर में, नतीजे की जानकारी को प्रिंट करने को कंट्रोल किया जाता है. डिफ़ॉल्ट रूप से, अगर किसी एक बिल्ड टारगेट के बारे में बताया गया था, तो बेज़ल यह मैसेज प्रिंट करता है कि टारगेट को सही तरीके से अप-टू-डेट किया गया है या नहीं. अगर ऐसा है, तो टारगेट बनाई गई आउटपुट फ़ाइलों की सूची भी प्रिंट हो जाती है. अगर एक से ज़्यादा टारगेट तय किए गए हैं, तो नतीजे की जानकारी नहीं दिखाई जाती है.
हालांकि, किसी एक टारगेट या कुछ टारगेट को बनाने के लिए, नतीजे की जानकारी मददगार हो सकती है. हालांकि, बड़े बिल्ड (जैसे कि पूरा टॉप-लेवल प्रोजेक्ट ट्री) के लिए, यह जानकारी बहुत ज़्यादा और ध्यान भटकाने वाली हो सकती है. इस विकल्प की मदद से, इसे कंट्रोल किया जा सकता है. --show_result
एक पूर्णांक तर्क लगाता है. यह टारगेट की वह ज़्यादा से ज़्यादा संख्या है जिसके लिए
पूरे नतीजे की जानकारी प्रिंट की जानी चाहिए. डिफ़ॉल्ट रूप से,
वैल्यू 1 होती है. इस थ्रेशोल्ड से ऊपर, अलग-अलग टारगेट के लिए
नतीजे की कोई भी जानकारी नहीं दिखाई जाती. इस तरह, शून्य होने की वजह से, नतीजे की
जानकारी हमेशा छिपा दी जाती है.
बहुत ज़्यादा वैल्यू होने पर, नतीजा हमेशा प्रिंट होता है.
अगर उपयोगकर्ता, टारगेट का एक छोटा ग्रुप (उदाहरण के लिए, कंपाइलेशन एडिट टेस्ट साइकल के दौरान) और ज़्यादा टारगेट पहले वाले मामले में, नतीजे की जानकारी बहुत काम की होती है, जबकि बाद वाले मामलों में जानकारी कम होती है. सभी विकल्पों की तरह, यह जानकारी .bazelrc फ़ाइल की मदद से भी दी जा सकती है.
फ़ाइलों को इस तरह प्रिंट किया जाता है कि फ़ाइल नाम को कॉपी करके शेल में चिपकाना और चलाना आसान हो. हर टारगेट के लिए "अप-टू-डेट" या "फ़ेल" मैसेज को उन स्क्रिप्ट से आसानी से पार्स किया जा सकता है जिनसे बिल्ड बढ़ता है.
--sandbox_debug
इस विकल्प की मदद से, कार्रवाई करने के लिए सैंडबॉक्सिंग का इस्तेमाल करते समय Basel, डीबग करने से जुड़ी ज़्यादा जानकारी प्रिंट कर सकता है. इस विकल्प में सैंडबॉक्स डायरेक्ट्री भी सुरक्षित रहती हैं, ताकि फ़ाइलों को चलाने के दौरान दिखने वाली फ़ाइलों की जांच की जा सके.
--subcommands (-s)
इस विकल्प की वजह से, Bagel के इस्तेमाल करने के चरण में हर कमांड को एक्ज़ीक्यूट करने से पहले, पूरी कमांड लाइन प्रिंट हो जाती है.
>>>>> # //examples/cpp:hello-world [action 'Linking examples/cpp/hello-world']
(cd /home/johndoe/.cache/bazel/_bazel_johndoe/4c084335afceb392cfbe7c31afee3a9f/bazel && \
exec env - \
/usr/bin/gcc -o bazel-out/local-fastbuild/bin/examples/cpp/hello-world -B/usr/bin/ -Wl,-z,relro,-z,now -no-canonical-prefixes -pass-exit-codes -Wl,-S -Wl,@bazel-out/local_linux-fastbuild/bin/examples/cpp/hello-world-2.params)
जहां भी मुमकिन हो, निर्देशों को बॉर्न शेल के साथ काम करने वाले सिंटैक्स में प्रिंट किया जाता है,
ताकि उन्हें आसानी से कॉपी किया जा सके और शेल कमांड प्रॉम्प्ट में चिपकाया जा सके.
(आपके शेल को cd और exec कॉल से सुरक्षित रखने के लिए आस-पास के ब्रैकेट दिए गए हैं; पक्का करें कि उन्हें कॉपी किया गया है!)
हालांकि, कुछ कमांड बेज़ल में अंदर ही लागू किए जाते हैं, जैसे कि
सिमलिंक ट्री बनाना. इन्हें दिखाने के लिए कोई कमांड लाइन नहीं है.
--subcommands=pretty_print को कमांड के आर्ग्युमेंट को एक लाइन के बजाय, सूची के तौर पर प्रिंट करने के लिए पास किया जा सकता है. इससे लंबी कमांड लाइन को पढ़ने में आसानी हो सकती है.
नीचे --verbose_failures जानकारी भी देखें.
किसी फ़ाइल के सबकमैंड को टूल-फ़्रेंडली फ़ॉर्मैट में लॉग करने के लिए, --execution_log_json_file और --execution_log_binary_file देखें.
--verbose_failures
इस विकल्प की वजह से, Bagel के इस्तेमाल करने के दौरान उन कमांड के लिए पूरी कमांड लाइन प्रिंट हो जाती है जो फ़ेल हो गई हैं. यह फ़ेलिंग बिल्ड को डीबग करने में मददगार हो सकता है.
फ़ेल होने वाले निर्देश, बॉर्न शेल के साथ काम करने वाले सिंटैक्स में प्रिंट किए जाते हैं. इन निर्देशों को कॉपी करके, शेल प्रॉम्प्ट में चिपकाया जा सकता है.
फ़ाइल फ़ोल्डर की स्थिति
बेज़ल से बनी बाइनरी पर "स्टाम्प" लगाने के लिए इन विकल्पों का इस्तेमाल करें: बाइनरी में अतिरिक्त जानकारी एम्बेड करने के लिए, जैसे कि सोर्स कंट्रोल में बदलाव या फ़ाइल फ़ोल्डर से जुड़ी अन्य जानकारी. इस तरीके का इस्तेमाल, stamp एट्रिब्यूट के साथ काम करने वाले नियमों के साथ किया जा सकता है. जैसे, genrule, cc_binary वगैरह.
--workspace_status_command=program
इस फ़्लैग की मदद से, एक बाइनरी तय की जा सकती है, जिसे हर बिल्ड से पहले Basel को चलाया जाता है. प्रोग्राम, फ़ाइल फ़ोल्डर की स्थिति की जानकारी की रिपोर्ट दे सकता है. जैसे, सोर्स कंट्रोल में हुए मौजूदा बदलाव.
फ़्लैग की वैल्यू, नेटिव प्रोग्राम का पाथ होना चाहिए. Linux/macOS पर, यह एक्ज़ीक्यूटेबल हो सकता है. Windows पर यह नेटिव बाइनरी होनी चाहिए. आम तौर पर, यह ".exe", ".bat" या ".cmd" फ़ाइल होनी चाहिए.
प्रोग्राम को स्टैंडर्ड आउटपुट के लिए, शून्य या उससे ज़्यादा कुंजी/वैल्यू पेयर को प्रिंट करना चाहिए. हर लाइन में एक एंट्री होनी चाहिए. इसके बाद, शून्य से बाहर निकल जाएं (ऐसा न करने पर बिल्ड फ़ेल हो जाएगा). कुंजी के नाम कुछ भी हो सकते हैं, लेकिन उनमें सिर्फ़ अपर केस अक्षरों और अंडरस्कोर का इस्तेमाल किया जा सकता है. कुंजी के नाम के बाद पहला स्पेस इसे वैल्यू से अलग करता है. मान, बाकी लाइन है (इसमें अतिरिक्त खाली सफ़ेद जगह भी शामिल हैं). कुंजी और वैल्यू में से न तो कुंजी कई पंक्तियों में हो सकती है. कुंजियों की डुप्लीकेट कॉपी नहीं बनाई जानी चाहिए.
Baze, कुंजियों को दो बकेट में बांटता है: "स्टेबल" और "वोलेटाइल". ("स्टेबल" और "वोलेटाइल" नाम समझने में आसान हैं. इसलिए, इनके बारे में ज़्यादा जानकारी न दें.)
इसके बाद, Basel की-वैल्यू पेयर को दो फ़ाइलों में लिखता है:
bazel-out/stable-status.txtऐसी सभी कुंजियां और मान शामिल होते हैं जहां कुंजी का नामSTABLE_से शुरू होता हैbazel-out/volatile-status.txtइसमें बाकी कुंजियां और उनकी वैल्यू शामिल होती हैं
समझौता:
अगर हो सके, तो "स्टेबल" कुंजियों की वैल्यू में कभी-कभी ही बदलाव होना चाहिए. अगर
bazel-out/stable-status.txtके कॉन्टेंट में बदलाव होता है, तो Baze उन कार्रवाइयों को अमान्य कर देगा जो इन पर निर्भर करती हैं. दूसरे शब्दों में, अगर किसी स्थिर कुंजी की वैल्यू में बदलाव होता है, तो Basel की स्टैंप वाली कार्रवाइयां फिर से चलाई जाएंगी. इसलिए, स्टेबल स्टेटस में टाइमस्टैंप जैसी चीज़ें नहीं होनी चाहिए, क्योंकि ये टाइमस्टैंप हमेशा बदलते रहते हैं. इससे, हर बिल्ड के साथ Basel की स्टैंप वाली कार्रवाइयां फिर से चलाई जाएंगी.Basel हमेशा नीचे दी गई स्टेबल कुंजियां देता है:
BUILD_EMBED_LABEL:--embed_labelकी वैल्यूBUILD_HOST: उस होस्ट मशीन का नाम जिस पर Basel चल रहा हैBUILD_USER: उस उपयोगकर्ता का नाम जिसके तौर पर Basel का इस्तेमाल किया जा रहा है
"ज़्यादा अपडेट होने वाली" कुंजियों की वैल्यू अक्सर बदल सकती हैं. बज़ल उम्मीद करते हैं कि वे समय-समय पर बदलते रहेंगे, जैसे कि टाइमस्टैंप बदलते हैं और
bazel-out/volatile-status.txtफ़ाइल को सही तरीके से अपडेट करते हैं. हालांकि, स्टैंप वाली कार्रवाइयों को हर समय फिर से न चलाने के लिए, Baze फ़ाइल ऐसा बताती है कि बार-बार अपडेट होने वाली फ़ाइल कभी नहीं बदलती. दूसरे शब्दों में, अगर लगातार अपडेट होने वाली स्थिति वाली फ़ाइल ही ऐसी फ़ाइल है जिसका कॉन्टेंट बदला गया है, तो Basel, इस पर निर्भर कार्रवाइयों को अमान्य नहीं करेगा. अगर कार्रवाइयों के अन्य इनपुट बदल गए हैं, तो बेज़ल उस कार्रवाई को फिर से करता है और कार्रवाई को अपडेट किया गया बार-बार अपडेट होने वाला स्टेटस दिखेगा. हालांकि, सिर्फ़ बदलाव की स्थिति में बदलाव होने से कार्रवाई अमान्य नहीं होगी.Basel की वजह से, हमेशा ये डेटा अपडेट होते हैं:
BUILD_TIMESTAMP: Unix Epoch के बाद के वर्शन में बिल्ड का समय सेकंड में (System.currentTimeMillis()की वैल्यू को हज़ार से भाग देने पर मिलने वाली वैल्यू)FORMATTED_DATE: बिल्ड का समय यूटीसी मेंyyyy MMM d HH mm ss EEEके तौर पर फ़ॉर्मैट किया गया है. उदाहरण के लिए, 2 जून, 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 नियमों के लिए डिफ़ॉल्ट) सेट करता है, तो इस विकल्प से यह तय होता है कि स्टैंपिंग चालू है या नहीं.
इस विकल्प या stamp एट्रिब्यूट पर ध्यान दिए बिना, Baज़ल की मदद से, एक्ज़ीक्यूटेबल कॉन्फ़िगरेशन के लिए बनाई गई बाइनरी कभी नहीं हटती हैं. stamp =
0 (*_test नियमों के लिए डिफ़ॉल्ट) सेट करने वाले नियमों के लिए, --[no]stamp पर ध्यान दिए बिना स्टैंप लगाने की सुविधा बंद है. अगर टारगेट की डिपेंडेंसी नहीं बदली है, तो --stamp तय करने पर, उन्हें फिर से बनाने के लिए मजबूर नहीं किया जाता है.
आम तौर पर, बिल्ड की परफ़ॉर्मेंस के लिए --nostamp को सेट करना अच्छा होता है, क्योंकि इससे इनपुट में उतार-चढ़ाव कम होता है और बिल्ड कैश मेमोरी में ज़्यादा बढ़ोतरी होती है.
प्लैटफ़ॉर्म
इन विकल्पों का इस्तेमाल उन होस्ट और टारगेट प्लैटफ़ॉर्म को कंट्रोल करने के लिए करें जो बिल्ड के काम करने के तरीके को कॉन्फ़िगर करते हैं. साथ ही, इससे यह भी कंट्रोल किया जा सकता है कि Baज़र के नियमों के लिए कौनसे एक्ज़ीक्यूशन प्लैटफ़ॉर्म और टूलचेन उपलब्ध हैं.
कृपया प्लैटफ़ॉर्म और टूलचेन पर बैकग्राउंड की जानकारी देखें.
--platforms=labels
प्लैटफ़ॉर्म के नियमों के लेबल, जो मौजूदा कमांड के लिए टारगेट प्लैटफ़ॉर्म की जानकारी देते हैं.
--host_platform=label
प्लैटफ़ॉर्म के नियम का लेबल, जो होस्ट सिस्टम के बारे में बताता है.
--extra_execution_platforms=labels
ऐसे प्लैटफ़ॉर्म जो कार्रवाइयां करने के लिए, एक्ज़ीक्यूशन प्लैटफ़ॉर्म के तौर पर उपलब्ध हैं. प्लैटफ़ॉर्म, टारगेट के हिसाब से या टारगेट पैटर्न के तौर पर तय किए जा सकते हैं. इन प्लैटफ़ॉर्म पर, Workspace फ़ाइल में register_execution_platforms() की मदद से एलान किए गए प्लैटफ़ॉर्म से पहले विचार किया जाएगा. यह विकल्प प्राथमिकता के हिसाब से प्लैटफ़ॉर्म की कॉमा-सेपरेटेड लिस्ट स्वीकार करता है. अगर फ़्लैग एक से ज़्यादा बार पास किया जाता है, तो सबसे हाल का ओवरराइड.
--extra_toolchains=labels
टूलचेन के रिज़ॉल्यूशन के दौरान, टूलचेन के नियमों पर ध्यान दिया जाना चाहिए. टूलचेन को सटीक टारगेट या टारगेट पैटर्न के तौर पर तय किया जा सकता है. Workspace फ़ाइल में 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/की वजह से Baze, छिपी हुई डायरेक्ट्री.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ज़ल का इस्तेमाल, डेवलपमेंट साइकल के दौरान सॉफ़्टवेयर इंजीनियर करते हैं. साथ ही, प्रोडक्शन के लिए डिप्लॉयमेंट के लिए बाइनरी तैयार करते समय, रिलीज़ इंजीनियर दोनों इसका इस्तेमाल करते हैं. इस सेक्शन में, Basel का इस्तेमाल करने वाले रिलीज़ इंजीनियरों के लिए कुछ सलाह दी गई हैं.
अहम विकल्प
रिलीज़ के लिए बेज़ल का इस्तेमाल करते समय, बिल्ड का काम करने वाली दूसरी स्क्रिप्ट की तरह ही समस्याएं आती हैं. ज़्यादा जानकारी के लिए, स्क्रिप्ट से बेज़ल को कॉल करें देखें. खास तौर पर, हम इन विकल्पों का सुझाव देते हैं:
ये विकल्प भी अहम हैं:
--package_path--symlink_prefix: कई कॉन्फ़िगरेशन के हिसाब से बिल्ड मैनेज करने के लिए, हर बिल्ड को किसी अलग आइडेंटिफ़ायर से अलग करना आसान हो सकता है. जैसे, "64बिट" बनाम "32बिट". यह विकल्प,bazel-bin(वगैरह) के सिमलिंक को अलग करता है.
चल रही जांच
बेज़ल से टेस्ट बनाने और चलाने के लिए, bazel test टाइप करने के बाद
टेस्ट टारगेट का नाम डालें.
डिफ़ॉल्ट रूप से, यह निर्देश बिल्ड और टेस्ट गतिविधि की एक साथ जांच करता है. साथ ही, कमांड लाइन पर बताए गए सभी टारगेट (इसमें कमांड लाइन में बताए गए टेस्ट न होने वाले टारगेट भी शामिल है) तैयार करता है और *_test और test_suite टारगेट को टेस्ट करता है. ऐसा उनकी ज़रूरी शर्तें पूरी होते ही किया जाता है. इसका मतलब है कि टेस्ट को बिल्डिंग के साथ इंटरलीव किया जाता है. आम तौर पर, ऐसा करने से
स्पीड काफ़ी बढ़ जाती है.
bazel test के लिए विकल्प
--cache_test_results=(yes|no|auto) (-t)
अगर यह विकल्प 'ऑटो' (डिफ़ॉल्ट) पर सेट है, तो नीचे दी गई कोई भी शर्त लागू होने पर ही, Baज़ल दोबारा टेस्ट करेगा:
- Baज़र, टेस्ट या उसकी डिपेंडेंसी में हुए बदलावों का पता लगाता है
- टेस्ट को
externalके तौर पर मार्क किया गया है --runs_per_testका इस्तेमाल करके, कई टेस्ट चलाने का अनुरोध किया गया- परीक्षण विफल रहा.
अगर 'नहीं' है, तो सभी जांच बिना किसी शर्त के लागू की जाएंगी.
अगर 'हां' है, तो कैश मेमोरी और अपने-आप काम करने का तरीका एक जैसा ही होगा. हालांकि, यह जांच न होने पर कैश मेमोरी में सेव हो सकता है और --runs_per_test की मदद से जांच कर सकता है.
जिन उपयोगकर्ताओं ने अपनी .bazelrc फ़ाइल में, इस विकल्प को डिफ़ॉल्ट रूप से चालू किया है उन्हें किसी खास रन के लिए, डिफ़ॉल्ट रूप से -t (चालू) या -t- (बंद है) वाले शॉर्ट वीडियो में बदलाव करना आसान लग सकता है.
--check_tests_up_to_date
यह विकल्प बेज़ेल को सिर्फ़ टेस्ट न करने का निर्देश देता है. इससे, वह सिर्फ़ कैश मेमोरी में सेव किए गए टेस्ट के नतीजों की जांच और रिपोर्ट करता है. अगर ऐसे टेस्ट हैं जो पहले नहीं बनाए गए हैं और चलाए गए हैं या जिनकी जांच के नतीजे पुराने हैं (उदाहरण के लिए, सोर्स कोड या बिल्ड के विकल्प बदल जाने की वजह से), तो Basel गड़बड़ी का मैसेज ("टेस्ट नतीजा अप-टू-डेट नहीं है" रिपोर्ट करेगा), टेस्ट की स्थिति को "NO STATUS" के तौर पर रिकॉर्ड करेगा (अगर कलर आउटपुट चालू है, तो लाल रंग में कोड देगा).
इस विकल्प से --check_up_to_date व्यवहार की जानकारी भी मिलती है.
यह विकल्प, पहले से सबमिट की गई जांचों के लिए मददगार हो सकता है.
--test_verbose_timeout_warnings
यह विकल्प बेज़ल को बताता है कि अगर टेस्ट का टाइम आउट, टेस्ट के पूरा करने के समय से काफ़ी ज़्यादा है, तो वह उपयोगकर्ता को साफ़ तौर पर चेतावनी दे. टेस्ट का टाइम आउट इस तरह सेट किया जाना चाहिए कि वह फ़्रीज़ न हो, लेकिन बहुत ज़्यादा टाइम आउट होने पर, उन असली समस्याओं की जानकारी छिप सकती है जो अचानक से दिखती हैं.
उदाहरण के लिए, जो टेस्ट आम तौर पर एक या दो मिनट में होता है उसमें ETERNAL या लॉन्ग का टाइम आउट नहीं होना चाहिए, क्योंकि ये बहुत ज़्यादा या बहुत ज़्यादा होते हैं.
इस विकल्प से, उपयोगकर्ताओं को टाइम आउट की सही वैल्यू तय करने या मौजूदा टाइम आउट वैल्यू की जांच करने में मदद मिलती है.
--[no]test_keep_going
डिफ़ॉल्ट रूप से, सभी जांच पूरी होने तक चलती हैं. अगर यह फ़्लैग बंद कर दिया जाता है,
तो भी टेस्ट पास न होने पर बिल्ड रद्द कर दिया जाता है. बाद के बिल्ड चरण
और टेस्ट को शुरू करने की प्रक्रिया नहीं चलती है और फ़्लाइट के अंदर आने वाले कॉल रद्द कर दिए जाते हैं.
--notest_keep_going और --keep_going, दोनों को तय न करें.
--flaky_test_attempts=attempts
इस विकल्प से पता चलता है कि अगर किसी वजह से टेस्ट फ़ेल हो जाता है, तो उसे कितनी बार आज़माया जाना चाहिए. एक ऐसी जांच जो शुरुआत में फ़ेल हो जाती है, लेकिन बाद में कामयाब हो जाती है उसे टेस्ट की खास जानकारी में FLAKY के तौर पर रिपोर्ट किया जाता है. हालांकि,
बेज़ल एग्ज़िट कोड या पास हो चुके टेस्ट की कुल संख्या की पहचान करने के लिए, इसे पास माना जाता है. उन सभी टेस्ट को फ़ेल माना जाता है जो अनुमति वाली सभी कोशिशों में फ़ेल हो जाते हैं.
डिफ़ॉल्ट रूप से (जब यह विकल्प न बताया गया हो या यह डिफ़ॉल्ट पर सेट हो), तो सामान्य जांच के लिए सिर्फ़ एक बार कोशिश की जा सकती है. साथ ही, flaky एट्रिब्यूट सेट वाले जांच के नियमों के लिए, तीन बार कोशिश की जा सकती है. जांच करने की कोशिशों की सीमा को बदलने के लिए, पूर्णांक वैल्यू तय की जा सकती है. सिस्टम के गलत इस्तेमाल को रोकने के लिए, Basel को ज़्यादा से ज़्यादा 10 बार टेस्ट करने की अनुमति मिलती है.
--runs_per_test=[regex@]number
इस विकल्प से तय होता है कि हर टेस्ट कितनी बार करना चाहिए. सभी टेस्ट को एक्ज़ीक्यूट करने को अलग-अलग टेस्ट माना जाता है. फ़ॉलबैक फ़ंक्शन हर एक पर अलग-अलग लागू होगा.
काम नहीं करने वाले टारगेट की स्थिति, --runs_per_test_detects_flakes फ़्लैग की वैल्यू पर निर्भर करती है:
- अगर यह नहीं होता है, तो किसी भी तरह के टेस्ट में असफल होने पर, पूरा टेस्ट फ़ेल हो जाता है.
- अगर यह टैग मौजूद है और एक ही शार्ड रिटर्न पास और फ़ेल से दो रन होते हैं, तो टेस्ट में गड़बड़ी की स्थिति दिखेगी (जब तक कि दूसरे रन न होने की वजह से यह फ़ेल हो जाए).
अगर एक ही संख्या दी गई है, तो सभी टेस्ट उसे कई बार चलाएंगे.
इसके अलावा, रेगुलर एक्सप्रेशन का इस्तेमाल करके
रेगुलर एक्सप्रेशन@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 आउटपुट को, सिर्फ़ stdout में भेजता है. इससे यह पक्का किया जाता है कि एक साथ होने वाली जांच के नतीजे एक-दूसरे से जुड़े न हों. बिल्ड में ऊपर दिए गए जवाब के आउटपुट के हिसाब से खास जानकारी प्रिंट करता है.all,errorsके जैसा है. हालांकि, यह सभी टेस्ट के आउटपुट को प्रिंट करता है. इनमें पास हो चुके टेस्ट भी शामिल हैं.streamedहर टेस्ट से, stdout/stderr आउटपुट को रीयल-टाइम में स्ट्रीम करता है.
--java_debug
इस विकल्प की वजह से, Java टेस्ट की Java वर्चुअल मशीन को जांच शुरू करने से पहले, JDWP के नियमों का पालन करने वाले डीबगर से कनेक्शन मिलने का इंतज़ार करना पड़ता है. यह विकल्प --test_output=streamed को लागू करता है.
--[no]verbose_test_summary
डिफ़ॉल्ट रूप से, यह विकल्प चालू होता है. इससे, जांच के समय और अन्य जानकारी (जैसे, जांच की कोशिश) को जांच की खास जानकारी में प्रिंट किया जाता है. अगर
--noverbose_test_summary तय किया गया है, तो टेस्ट की खास जानकारी में
सिर्फ़ टेस्ट का नाम, टेस्ट का स्टेटस, और कैश मेमोरी में सेव किए गए टेस्ट इंडिकेटर को शामिल किया जाएगा.
साथ ही, इसे 80 वर्णों में रखने के लिए फ़ॉर्मैट किया जाएगा.
--test_tmpdir=path
यह नीति, डिवाइस पर किए गए टेस्ट की अस्थायी डायरेक्ट्री के बारे में बताती है. हर जांच इस डायरेक्ट्री में एक अलग सबडायरेक्ट्री में की जाएगी. डायरेक्ट्री को हर bazel test कमांड की शुरुआत में साफ़ किया जाएगा.
डिफ़ॉल्ट रूप से, basel इस डायरेक्ट्री को Basel आउटपुट बेस डायरेक्ट्री में रखता है.
--test_timeout=seconds या --test_timeout=seconds,seconds,seconds,seconds
यह नीति, टाइम आउट की नई वैल्यू के तौर पर सेकंड की तय संख्या का इस्तेमाल करके, सभी जांचों के लिए टाइम आउट की वैल्यू को बदल देती है. अगर सिर्फ़ एक वैल्यू दी गई है, तो उस वैल्यू का इस्तेमाल टेस्ट टाइम आउट की सभी कैटगरी के लिए किया जाएगा.
इसके अलावा, कॉमा लगाकर अलग की गई चार वैल्यू दी जा सकती हैं. इनमें, छोटे, मॉडरेट, लंबे, और बार-बार होने वाले टेस्ट (इसी क्रम में) के लिए, अलग-अलग टाइम आउट तय किए जा सकते हैं. दोनों ही फ़ॉर्मैट में, किसी भी टेस्ट साइज़ के लिए शून्य या नेगेटिव वैल्यू को, राइटिंग टेस्ट पेज पर दी गई टाइम आउट की डिफ़ॉल्ट कैटगरी से बदल दिया जाएगा. डिफ़ॉल्ट रूप से, Basel, टेस्ट के साइज़ से टाइम आउट की सीमा का अनुमान लगाकर, सभी जांचों के लिए इन टाइम आउट का इस्तेमाल करेगा. भले ही, साइज़ की जानकारी साफ़ तौर पर दी गई हो या साफ़ तौर पर.
टाइम आउट की कैटगरी को साफ़ तौर पर उसके साइज़ से अलग बताने वाले टेस्ट को वही वैल्यू मिलेगी, जैसे कि साइज़ टैग की मदद से, टाइम आउट को आसानी से सेट किया गया हो. इसलिए, 'छोटे' साइज़ की जांच, जो 'लंबे' टाइम आउट के बारे में बताती है उस जांच का असरदार टाइम आउट भी वैसा ही होगा जैसा किसी 'बड़े' टेस्ट में होने वाला टाइम आउट साफ़ तौर पर नहीं होगा.
--test_arg=arg
हर जांच प्रोसेस के लिए कमांड लाइन के विकल्प/फ़्लैग/तर्क देती है. कई आर्ग्युमेंट को पास करने के लिए, इस विकल्प का इस्तेमाल एक से ज़्यादा बार किया जा सकता है. उदाहरण के लिए,
--test_arg=--logtostderr --test_arg=--v=3.
ध्यान दें कि bazel run कमांड के उलट, bazel test -- target --logtostderr --v=3 की तरह सीधे तौर पर टेस्ट आर्ग्युमेंट पास नहीं किए जा सकते. इसकी वजह यह है कि bazel test में भेजे गए बाहरी आर्ग्युमेंट, अतिरिक्त टेस्ट टारगेट के तौर पर इंटरप्रेट किए जाते हैं. इसका मतलब है कि --logtostderr और --v=3, दोनों को टेस्ट टारगेट माना जाएगा. यह अस्पष्टता bazel run कमांड के लिए मौजूद नहीं है, जो सिर्फ़ एक टारगेट को स्वीकार करता है.
--test_arg को bazel run कमांड को पास किया जा सकता है. हालांकि, इसे तब तक अनदेखा किया जाता है, जब तक कि चलाया जा रहा टारगेट, जांच वाला टारगेट न हो. (किसी दूसरे फ़्लैग की तरह ही, अगर इसे -- टोकन के बाद bazel run कमांड में पास किया जाता है, तो इसे Basel की ओर से प्रोसेस नहीं किया जाता. हालांकि, इसे एक्ज़ीक्यूट किए गए टारगेट के लिए शब्दों में ही फ़ॉरवर्ड किया जाता है.)
--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'
चयन का परीक्षण करें
जैसा कि आउटपुट चुनने के विकल्प सेक्शन में बताया गया है, आपके पास टेस्ट को साइज़, समय खत्म होने, टैग या भाषा के हिसाब से फ़िल्टर करने का विकल्प है. एक सुविधा सामान्य नाम फ़िल्टर किसी खास फ़िल्टर आर्ग को टेस्ट रनर पर फ़ॉरवर्ड कर सकता है.
bazel test के लिए अन्य विकल्प
सिंटैक्स और बाकी विकल्प बिलकुल bazel build की तरह हैं.
एक्ज़ीक्यूटेबल चल रहे हैं
bazel run कमांड bazel build की तरह है. हालांकि, इसका इस्तेमाल किसी एक टारगेट को बनाने और चलाने के लिए किया जाता है. यह रहा एक सामान्य सेशन
(//java/myapp:myapp हैलो कहता है और अपने आर्ग प्रिंट करता है):
% bazel run java/myapp:myapp -- --arg1 --arg2
INFO: Analyzed target //java/myapp:myapp (13 packages loaded, 27 targets configured).
INFO: Found 1 target...
Target //java/myapp:myapp up-to-date:
bazel-bin/java/myapp/myapp
INFO: Elapsed time: 14.290s, Critical Path: 5.54s, ...
INFO: Build completed successfully, 4 total actions
INFO: Running command line: bazel-bin/java/myapp/myapp <args omitted>
Hello there
$EXEC_ROOT/java/myapp/myapp
--arg1
--arg2
bazel run एक जैसी है, लेकिन बिलकुल अलग है. सीधे तौर पर बेज़ल की बनाई बाइनरी का इस्तेमाल करने के लिए, इसका काम करने का तरीका अलग-अलग है. यह इस बात पर निर्भर करता है कि जिस बाइनरी का इस्तेमाल किया जाना है वह टेस्ट है या नहीं.
जब बाइनरी कोई जांच नहीं होती है, तो मौजूदा मौजूदा डायरेक्ट्री बाइनरी का रनफ़ाइल ट्री होगी.
जब बाइनरी एक टेस्ट होता है, तो मौजूदा डायरेक्ट्री ही एक्ज़ीक्यूट रूट होती है. साथ ही, एनवायरमेंट टेस्ट की कॉपी बनाने की अच्छी भावना से कोशिश की जाती है, जो आम तौर पर लागू होती हैं. हालांकि, एम्युलेशन सही नहीं होता है और एक से ज़्यादा शार्ड वाले टेस्ट इस तरह से नहीं चलाए जा सकते (इससे बचने के लिए --test_sharding_strategy=disabled कमांड लाइन विकल्प का इस्तेमाल किया जा सकता है)
बाइनरी में, यहां दिए गए अतिरिक्त एनवायरमेंट वैरिएबल भी उपलब्ध होते हैं:
BUILD_WORKSPACE_DIRECTORY: उस फ़ाइल फ़ोल्डर का रूट जहां बिल्ड चलाया गया था.BUILD_WORKING_DIRECTORY: काम कर रही मौजूदा डायरेक्ट्री जहां से Basel को चलाया गया था.
उदाहरण के लिए, इनका इस्तेमाल कमांड लाइन पर मौजूद फ़ाइल के नामों की व्याख्या करने के लिए किया जा सकता है.
bazel run के लिए विकल्प
--run_under=command-prefix
इसका असर bazel test (ऊपर देखें) के लिए दिए गए --run_under विकल्प जैसा ही होता है. हालांकि, यह सिर्फ़ bazel test से चलाए जा रहे टेस्ट के बजाय, bazel
run से चलाए जा रहे निर्देश पर लागू होता है. इसलिए, इसे लेबल के तहत नहीं चलाया जा सकता.
Bazz के हिसाब से, लॉगिंग आउटपुट फ़िल्टर किए जा रहे हैं
bazel run के साथ बाइनरी का इस्तेमाल शुरू करने पर, Basel से होने वाले लॉगिंग आउटपुट को खुद प्रिंट करता है.
साथ ही, इसे शुरू करने की प्रोसेस के तहत बाइनरी को भी प्रिंट किया जाता है. लॉग में किसी भी तरह की रुकावट न आए, इसके लिए --ui_event_filters और --noshow_progress फ़्लैग का इस्तेमाल करके, Basel के आउटपुट को बंद किया जा सकता है.
उदाहरण के लिए:
bazel run --ui_event_filters=-info,-stdout,-stderr --noshow_progress //java/myapp:myapp
टेस्ट एक्ज़ीक्यूट किए जा रहे हैं
bazel run, टेस्ट बाइनरी भी चला सकता है. इसका असर, राइटिंग टेस्ट में बताए गए एनवायरमेंट के नज़दीकी अनुमान से टेस्ट करने पर होता है. ध्यान दें कि --test_arg के अलावा, इस तरह की जांच करने पर, किसी भी --test_* आर्ग्युमेंट पर कोई असर नहीं पड़ता .
बिल्ड आउटपुट की सफ़ाई की जा रही है
clean निर्देश
बेज़ेल के पास clean का निर्देश है, जो Make के निर्देश से मिलता-जुलता है.
यह इस Basel इंस्टेंस से किए गए सभी बिल्ड कॉन्फ़िगरेशन के लिए आउटपुट डायरेक्ट्री को मिटा देता है
या इस BaZ इंस्टेंस से बनाए गए पूरे काम करने वाले ट्री को मिटा देता है और इंटरनल कैश को रीसेट करता है. अगर इसे किसी भी कमांड-लाइन विकल्प के बिना चलाया जाता है, तो सभी कॉन्फ़िगरेशन की आउटपुट डायरेक्ट्री को हटा दिया जाएगा.
याद रखें कि बेज़ल इन्सटेंस किसी एक फ़ाइल फ़ोल्डर से जुड़ा है, इसलिए
clean कमांड से उस फ़ाइल फ़ोल्डर में, उस बैजल इंस्टेंस के ज़रिए किए गए सभी बिल्ड के सभी आउटपुट मिट जाएंगे.
Baज़ल इंस्टेंस से बनाए गए, काम करने वाले पूरे ट्री को पूरी तरह से हटाने के लिए, --expunge का विकल्प तय करें. --expunge पर काम करने पर, 'साफ़ करें' निर्देश से, पूरे आउटपुट बेस ट्री को हटा दिया जाता है. इसमें, बिल्ड आउटपुट के साथ-साथ उन सभी अस्थायी फ़ाइलें शामिल होती हैं जिन्हें Basel ने बनाया है. यह
shutdown कमांड के हिसाब से, फ़ाइलें खाली होने के बाद बेज़ल सर्वर को भी बंद कर देता है. उदाहरण के लिए, किसी बेज़ल इंस्टेंस की सभी डिस्क और मेमोरी ट्रेस को साफ़ करने के लिए, आप यह बता सकते हैं:
% bazel clean --expunge
इसके अलावा, --expunge_async का इस्तेमाल करके, कॉन्टेंट को बैकग्राउंड में मिटाया जा सकता है. जब तक एसिंक्रोनस एक्सपंज चलता रहता है, उसी क्लाइंट में Basel कमांड को शुरू करना सुरक्षित है.
clean कमांड मुख्य रूप से उन फ़ाइल फ़ोल्डर के लिए डिस्क स्टोरेज खाली करने के लिए दिया जाता है जिनकी अब ज़रूरत नहीं है.
ऐसा हो सकता है कि Baज़र का रीबिल्ड रीबिल्ड बिलकुल सही न हो, इसलिए कोई समस्या आने पर, clean का इस्तेमाल एक जैसी स्थिति को वापस पाने के लिए किया जा सकता है.
बेज़ेल का डिज़ाइन ऐसा है कि इन समस्याओं को ठीक किया जा सकता है और
इन गड़बड़ियों को ठीक करना सबसे बड़ी प्राथमिकता है. अगर आपको कभी कोई गलत इंक्रीमेंटल बिल्ड मिलता है, तो clean का इस्तेमाल करने के बजाय, गड़बड़ी की रिपोर्ट दर्ज करें और टूल में गड़बड़ियों की शिकायत करें.
डिपेंडेंसी ग्राफ़ की क्वेरी करना
बेज़ेल में एक क्वेरी लैंग्वेज होती है, जो बिल्ड के दौरान इस्तेमाल किए गए डिपेंडेंसी ग्राफ़ के बारे में सवाल पूछने के लिए होती है. क्वेरी भाषा का इस्तेमाल दो निर्देशों से किया जाता है: query और cquery. इन दोनों कमांड के बीच सबसे बड़ा अंतर यह है कि क्वेरी, लोडिंग के चरण के बाद चलती है और cquery, विश्लेषण के फ़ेज़ के बाद चलती है. ये टूल सॉफ़्टवेयर इंजीनियरिंग के कई कामों के लिए बहुत मददगार साबित होते हैं.
क्वेरी की भाषा, ग्राफ़ के ऊपर बीजगणितीय संक्रियाओं के आइडिया पर आधारित है; इसे
Baze क्वेरी का रेफ़रंस. कृपया रेफ़रंस, उदाहरणों, और क्वेरी के हिसाब से कमांड-लाइन के विकल्पों के लिए वह दस्तावेज़ देखें.
क्वेरी टूल में कई कमांड-लाइन विकल्प इस्तेमाल किए जाते हैं. --output, आउटपुट फ़ॉर्मैट को चुनता है.
--[no]keep_going (डिफ़ॉल्ट रूप से बंद होता है) की वजह से क्वेरी टूल, गड़बड़ियों पर लगातार काम करता रहता है. अगर गड़बड़ियां होने पर अधूरा नतीजा स्वीकार नहीं किया जाता, तो यह व्यवहार भी बंद हो सकता है.
--[no]tool_deps विकल्प, डिफ़ॉल्ट रूप से चालू होता है. इसकी वजह से, नॉन-टारगेट कॉन्फ़िगरेशन में डिपेंडेंसी को उस डिपेंडेंसी ग्राफ़ में शामिल किया जाता है जिस पर क्वेरी काम करती है.
--[no]implicit_deps विकल्प, डिफ़ॉल्ट रूप से चालू होता है. इसकी वजह से, इंप्लिसिट डिपेंडेंसी को डिपेंडेंसी ग्राफ़ में शामिल किया जाता है, जिस पर क्वेरी काम करती है. इंप्लिसिट डिपेंडेंसी वह है जिसे बिल्ड फ़ाइल में साफ़ तौर पर तय नहीं किया गया है, लेकिन उसे बैज़ल से जोड़ा गया है.
उदाहरण के लिए: "पीईबीएल ट्री में सभी टेस्ट बनाने के लिए ज़रूरी सभी जेन रूल की परिभाषाओं (BUILD फ़ाइलों में) की जगह की जानकारी दिखाएं."
bazel query --output location 'kind(genrule, deps(kind(".*_test rule", foo/bar/pebl/...)))'
ऐक्शन ग्राफ़ की क्वेरी करना
aquery कमांड की मदद से, अपने बिल्ड ग्राफ़ में कार्रवाइयों के लिए क्वेरी की जा सकती है.
यह विश्लेषण के बाद कॉन्फ़िगर किए गए टारगेट ग्राफ़ पर काम करता है. इसमें कार्रवाइयों, आर्टफ़ैक्ट, और उनके संबंधों के बारे में जानकारी दिखाई जाती है.
यह टूल कई कमांड-लाइन विकल्प स्वीकार करता है.
--output, आउटपुट फ़ॉर्मैट को चुनता है. डिफ़ॉल्ट आउटपुट फ़ॉर्मैट (text) को लोग आसानी से पढ़ सकते हैं. मशीन से पढ़ने लायक फ़ॉर्मैट के लिए proto या textproto का इस्तेमाल करें.
खास तौर पर, क्वेरी कमांड सामान्य बेज़ल बिल्ड के ऊपर काम करती है और बिल्ड के दौरान उपलब्ध
विकल्पों के सेट को इनहेरिट करती है.
यह फ़ंक्शन के उन ही सेट के साथ काम करता है जो पारंपरिक
query, लेकिन siblings, buildfiles, और
tests में भी उपलब्ध हैं.
ज़्यादा जानकारी के लिए, ऐक्शन ग्राफ़ क्वेरी देखें.
अन्य निर्देश और विकल्प
help
help निर्देश से ऑनलाइन मदद मिलती है. डिफ़ॉल्ट रूप से, इसमें उपलब्ध निर्देशों की खास जानकारी और सहायता से जुड़े विषय दिखते हैं, जैसा कि बिल्डिंग विद बेज़ल की मदद से बनाया गया है में दिखाया गया है.
किसी तर्क को तय करने से किसी खास विषय के लिए
ज़्यादा जानकारी मिलती है. ज़्यादातर विषय बेज़ेल कमांड हैं, जैसे कि build या query. हालांकि, सहायता से जुड़े कुछ ऐसे विषय भी हैं जो निर्देशों के मुताबिक नहीं हैं.
--[no]long (-l)
डिफ़ॉल्ट रूप से, bazel help [topic] किसी विषय के लिए
सिर्फ़ काम के विकल्पों की खास जानकारी प्रिंट करता है. अगर
--long विकल्प बताया गया है, तो हर विकल्प का टाइप, डिफ़ॉल्ट वैल्यू, और
पूरी जानकारी भी प्रिंट की जाती है.
shutdown
shutdown कमांड इस्तेमाल करने पर, Basel सर्वर की प्रोसेस रुक सकती हैं. इस निर्देश की वजह से, Bagel सर्वर के इस्तेमाल में न होने पर वह बंद हो जाता है. उदाहरण के लिए, किसी बिल्ड या अन्य कमांड के पूरा होने के बाद. ज़्यादा जानकारी के लिए, क्लाइंट/सर्वर को लागू करने का तरीका देखें.
बेज़ल सर्वर, इस्तेमाल में न होने पर टाइम आउट होने के बाद अपने-आप बंद हो जाते हैं. इसलिए, यह निर्देश शायद ही कभी ज़रूरी होता है. हालांकि, यह निर्देश स्क्रिप्ट में तब काम आ सकता है, जब आपको पता हो कि दिए गए फ़ाइल फ़ोल्डर में अब कोई बिल्ड नहीं होगा.
shutdown एक
विकल्प, --iff_heap_size_greater_than _n_ स्वीकार करता है, जिसके लिए
एक पूर्णांक तर्क (एमबी में) की ज़रूरत होती है. अगर बताया जाए, तो इससे पहले से इस्तेमाल की गई मेमोरी
को बंद करने की प्रोसेस तय होती है. यह उन स्क्रिप्ट के लिए काम का है जो बहुत सारी बिल्ड प्रोसेस शुरू करती हैं. इसकी वजह यह है कि Basel सर्वर में होने वाली कोई भी मेमोरी लीक होने पर कभी-कभी यह क्रैश हो सकता है. कंडिशनल रीस्टार्ट करने से, यह स्थिति पहले जैसी हो जाती है.
info
info कमांड, Basel सर्वर इंस्टेंस से जुड़ी या किसी खास बिल्ड कॉन्फ़िगरेशन से जुड़ी अलग-अलग वैल्यू को प्रिंट करता है.
(इनका इस्तेमाल बिल्ड ड्राइव करने वाली स्क्रिप्ट में किया जा सकता है.)
info निर्देश, सिंगल (ज़रूरी नहीं)
तर्क की अनुमति भी देता है, जो नीचे दी गई सूची में से किसी एक कुंजी का नाम है.
इस मामले में, bazel info key सिर्फ़ उस एक कुंजी की वैल्यू प्रिंट करेगा. (बेज़ल को स्क्रिप्ट करते समय यह खास तौर पर सुविधाजनक होता है, क्योंकि इससे sed -ne /key:/s/key://p से नतीजे को पाइप करने की ज़रूरत नहीं पड़ती:
कॉन्फ़िगरेशन-इंडिपेंडेंट डेटा
release: इस Basel इंस्टेंस के लिए रिलीज़ लेबल या अगर यह रिलीज़ बाइनरी नहीं है, तो "डेवलपमेंट वर्शन".workspaceबेस वर्कस्पेस डायरेक्ट्री का ऐब्सलूट पाथ.install_base: इंस्टॉल करने की इस डायरेक्ट्री का ऐब्सलूट पाथ, जिसे मौजूदा उपयोगकर्ता के लिए Basel इंस्टेंस इस्तेमाल करता है. Basel ने इस डायरेक्ट्री के नीचे, अपनी ज़रूरत के हिसाब से एक्ज़ीक्यूटेबल फ़ाइल को इंस्टॉल किया है.output_base: बेस आउटपुट डायरेक्ट्री का ऐब्सलूट पाथ, जिसका इस्तेमाल बेज़ल इंस्टेंस मौजूदा उपयोगकर्ता और वर्कस्पेस कॉम्बिनेशन के लिए किया जाता है. Basel ने अपने स्क्रैच और बिल्ड आउटपुट को इस डायरेक्ट्री में रखा है.execution_root: आउटपुट रूट डायरेक्ट्री के लिए ऐब्सलूट पाथ. यह डायरेक्ट्री उन सभी फ़ाइलों का रूट है जिन्हें बिल्ड के दौरान एक्ज़ीक्यूट किए जाने वाले निर्देशों के ज़रिए ऐक्सेस किया जा सकता है. साथ ही, यह डायरेक्ट्री उन कमांड के लिए भी काम करती है. अगर फ़ाइल फ़ोल्डर की डायरेक्ट्री में बदलाव किया जा सकता है, तो वहांbazel-<workspace>नाम का एक सिमलिंक मौजूद होगा, जो इस डायरेक्ट्री पर ले जाएगा.output_path: सभी फ़ाइलों के लिए इस्तेमाल किए जाने वाले एक्ज़ीक्यूशन रूट के नीचे, आउटपुट डायरेक्ट्री का ऐब्सलूट पाथ. अगर वर्कस्पेस डायरेक्ट्री में लिखा जा सकता है, तो वहांbazel-outनाम का सिमलिंक होता है, जो इस डायरेक्ट्री पर ले जाता है.server_pid: Basel सर्वर प्रोसेस का प्रोसेस आईडी.server_log: 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वगैरह). ये ऐसे वैरिएबल होते हैं जिन्हें BUILD फ़ाइलों में$(CC)याvarref("CC")सिंटैक्स का इस्तेमाल करके ऐक्सेस किया जाता है.
उदाहरण: मौजूदा कॉन्फ़िगरेशन के लिए C++ कंपाइलर.
यह "मेक" एनवायरमेंट में $(CC) वैरिएबल है, इसलिए --show_make_env फ़्लैग की ज़रूरत है.
% bazel info --show_make_env -c opt COMPILATION_MODE opt
उदाहरण: मौजूदा कॉन्फ़िगरेशन के लिए, bazel-bin आउटपुट डायरेक्ट्री. अगर किसी वजह से bazel-bin सिमलिंक नहीं बनाया जा सकता, तो भी इसके सही होने की गारंटी है. उदाहरण के लिए, अगर किसी रीड-ओनली डायरेक्ट्री से बनाया जा रहा है.
% bazel info --cpu=piii bazel-bin /var/tmp/_bazel_johndoe/fbd0e8a34f61ce5d491e3da69d959fe6/execroot/io_bazel/bazel-out/piii-opt/bin % bazel info --cpu=k8 bazel-bin /var/tmp/_bazel_johndoe/fbd0e8a34f61ce5d491e3da69d959fe6/execroot/io_bazel/bazel-out/k8-opt/bin
version और --version
वर्शन आदेश, बनाई गई Basel बाइनरी के बारे में वर्शन विवरण प्रिंट करता है, जिसमें इसे बनाने का परिवर्तन सूची और तारीख शामिल है. इनसे यह खास तौर पर यह तय करने में मदद मिलती है कि आपके पास बैज वाला नया वर्शन है या नहीं या फिर गड़बड़ी की शिकायत की जा रही है या नहीं. इनमें से कुछ दिलचस्प वैल्यू ये हैं:
changelist: वह चेंजलिस्ट, जिस पर Basel का यह वर्शन रिलीज़ हुआ था.label: इस Basel इंस्टेंस के लिए रिलीज़ लेबल या अगर यह रिलीज़ बाइनरी नहीं है, तो "डेवलपमेंट वर्शन". बग की रिपोर्ट करते समय बहुत उपयोगी होता है.
bazel --version, बिना किसी अन्य आर्ग्युमेंट के, bazel version --gnu_format वाले आउटपुट से ही उत्सर्जन करेगा. हालांकि, बेज़ल सर्वर चालू करने या सर्वर संग्रह को अनपैक करने के खराब असर की ज़रूरत नहीं है. bazel --version को कहीं से भी चलाया जा सकता है - इसके लिए वर्कस्पेस की डायरेक्ट्री की ज़रूरत नहीं है.
mobile-install
mobile-install निर्देश से मोबाइल डिवाइसों पर ऐप्लिकेशन इंस्टॉल होते हैं.
फ़िलहाल, यह सुविधा सिर्फ़ उन Android डिवाइसों पर काम करती है जिन पर आर्टिफ़िशियल इंटेलिजेंस का इस्तेमाल किया जा रहा है.
ज़्यादा जानकारी के लिए, bazu मोबाइल-इंस्टॉल देखें.
ये विकल्प इस्तेमाल किए जा सकते हैं:
--incremental
अगर सेट किया जाता है, तो Baze ऐप्लिकेशन को इंस्टॉल करने की कोशिश करता है. इसका मतलब है कि ऐप्लिकेशन को
सिर्फ़ वे हिस्से जिनमें पिछले बिल्ड के बाद से बदलाव हुआ है. इससे AndroidManifest.xml, नेटिव कोड या Java के संसाधनों (जैसे, Class.getResource() के रेफ़रंस) में बताए गए संसाधन अपडेट नहीं किए जा सकते. अगर ये चीज़ें बदलती हैं, तो इस विकल्प को हटाना ज़रूरी है. Basel की भावना के उलट,
Android प्लैटफ़ॉर्म की सीमाओं की वजह से, यह जानना उपयोगकर्ता की ज़िम्मेदारी है कि वह कब अच्छा काम कर रहा है और कब उसे इंस्टॉल
करने की ज़रूरत है.
अगर आपके पास Marshmallow या इसके बाद के वर्शन वाला डिवाइस है, तो --split_apks फ़्लैग का इस्तेमाल करें.
--split_apks
डिवाइस पर ऐप्लिकेशन को इंस्टॉल और अपडेट करने के लिए, स्प्लिट apks का इस्तेमाल करना है या नहीं.
यह सुविधा सिर्फ़ Marshmallow या उसके बाद के वर्शन वाले डिवाइसों पर काम करती है. ध्यान दें कि --split_apks का इस्तेमाल करते समय, --incremental फ़्लैग का इस्तेमाल करना ज़रूरी नहीं है.
--start_app
इंस्टॉल होने के बाद, ऐप्लिकेशन को साफ़ स्थिति में चालू करता है. --start=COLD के बराबर.
--debug_app
ऐप्लिकेशन को इंस्टॉल करने के बाद, उसे खाली स्थिति में शुरू करने से पहले, डीबगर के अटैच होने का इंतज़ार करता है.
--start=DEBUG के बराबर.
--start=_start_type_
ऐप्लिकेशन को इंस्टॉल करने के बाद, किस तरह शुरू होना चाहिए. ये _start_type_s इस्तेमाल किए जा सकते हैं:
NOऐप्लिकेशन शुरू नहीं करता. यह डिफ़ॉल्ट सेटिंग है.- इंस्टॉल होने के बाद,
COLDऐप्लिकेशन को साफ़ स्थिति से चालू करता है. WARMइंक्रीमेंटल इंस्टॉल होने पर भी ऐप्लिकेशन की स्थिति को बनाए रखता है और उसे पहले जैसा करता है.DEBUGऐप्लिकेशन को इंस्टॉल करने के बाद, उसे खाली स्थिति में शुरू करने से पहले डीबगर का इंतज़ार करता है.
--adb=path
इस्तेमाल की जाने वाली adb बाइनरी को बताता है.
डिफ़ॉल्ट रूप से, --android_sdk में बताए गए Android SDK टूल में adb का इस्तेमाल किया जाता है.
--adb_arg=serial
adb में अतिरिक्त आर्ग्युमेंट. ये कमांड लाइन में सबकमांड से पहले आते हैं और आम तौर पर इनका इस्तेमाल यह तय करने के लिए किया जाता है कि किस डिवाइस पर इंस्टॉल करना है.
उदाहरण के लिए, इस्तेमाल करने के लिए Android डिवाइस या एम्युलेटर चुनने के लिए:
% bazel mobile-install --adb_arg=-s --adb_arg=deadbeef
adb को इस तौर पर शुरू करता है
adb -s deadbeef install ...
--incremental_install_verbosity=number
इंक्रीमेंटल इंस्टॉल के लिए वर्बोसिटी. डीबग लॉग करने के लिए, 1 पर सेट करें, ताकि उसे कंसोल में प्रिंट किया जा सके.
dump
dump कमांड, Basel सर्वर के इंटरनल स्टेटस के डंप को स्टडआउट करने के लिए प्रिंट करता है. इस कमांड को मुख्य तौर पर, Basel डेवलपर के इस्तेमाल के लिए बनाया गया है. इसलिए, इस कमांड के आउटपुट के बारे में नहीं बताया गया है. इसमें बदलाव किया जा सकता है.
डिफ़ॉल्ट रूप से, निर्देश सिर्फ़ ऐसे सहायता मैसेज को प्रिंट करेगा जो बेज़ेल राज्य के कुछ खास इलाकों को शामिल करने के संभावित विकल्पों की जानकारी देता है. इंटरनल स्टेट डंप करने के लिए, कम से कम एक विकल्प को तय करना ज़रूरी है.
इन विकल्पों का इस्तेमाल किया जा सकता है:
--action_cache, ऐक्शन कैश मेमोरी वाला कॉन्टेंट डंप करता है.--packages, पैकेज की कैश मेमोरी का कॉन्टेंट डंप करता है.--skyframe, इंटरनल बेज़ल डिपेंडेंसी ग्राफ़ की स्थिति को डंप करता है.--rules, हर नियम और आसपेक्ट क्लास के लिए नियम की खास जानकारी डंप करता है. इसमें गिनती और कार्रवाई की संख्या भी शामिल हैं. इसमें स्थानीय और स्टारलार्क, दोनों तरह के नियम शामिल हैं. अगर मेमोरी ट्रैकिंग की सुविधा चालू है, तो नियमों के तहत मेमोरी के इस्तेमाल को भी प्रिंट किया जाता है.--skylark_memoryबताए गए पाथ पर pprof के साथ काम करने वाली .gz फ़ाइल डंप करता है. यह सुविधा काम करे, इसके लिए आपको मेमोरी ट्रैकिंग की सुविधा चालू करनी होगी.
मेमोरी को ट्रैक करने वाले ऐप्लिकेशन
कुछ dump निर्देशों के लिए, मेमोरी ट्रैकिंग की ज़रूरत होती है. इसे चालू करने के लिए, आपको Bagel को
स्टार्टअप फ़्लैग पास करने होंगे:
--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 पर Basel में की जाती है. इसलिए, पक्का करें कि आपने $BAZEL को उस जगह पर सेट किया हो जहां आपको Basel का डेटा स्टोर करने की जगह है.
हर निर्देश के लिए, इन विकल्पों को Basel को देते रहें. ऐसा न करने पर, सर्वर रीस्टार्ट हो जाएगा.
उदाहरण:
% bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar \
--host_jvm_args=-DRULE_MEMORY_TRACKER=1 \
build --nobuild <targets>
# Dump rules
% bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar \
--host_jvm_args=-DRULE_MEMORY_TRACKER=1 \
dump --rules
# Dump Starlark heap and analyze it with pprof
% bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar \
--host_jvm_args=-DRULE_MEMORY_TRACKER=1 \
dump --skylark_memory=$HOME/prof.gz
% pprof -flame $HOME/prof.gz
analyze-profile
analyze-profile निर्देश, बेज़ल को शुरू करने के दौरान पहले से इकट्ठा की गई JSON ट्रेस प्रोफ़ाइल का विश्लेषण करता है.
canonicalize-flags
canonicalize-flags
कमांड, जो बेज़ल कमांड के लिए विकल्पों की सूची लेता है और उसी इफ़ेक्ट से जुड़े
विकल्पों की सूची दिखाता है. विकल्पों की नई सूची कैननिकल है. उदाहरण के लिए,
एक जैसे इफ़ेक्ट वाले विकल्पों की दो सूचियों को एक ही नई सूची में कैननिकल किया जाता है.
--for_command विकल्प का इस्तेमाल अलग-अलग कमांड से चुनने के लिए किया जा सकता है. फ़िलहाल, सिर्फ़ build और test
का इस्तेमाल किया जा सकता है. जिन विकल्पों के साथ दिया गया निर्देश काम नहीं करता है उनसे गड़बड़ी पैदा होती है.
उदाहरण के लिए:
% bazel canonicalize-flags -- --config=any_name --test_tag_filters="-lint" --config=any_name --test_tag_filters=-lint
स्टार्टअप के विकल्प
इस सेक्शन में बताए गए विकल्पों से, Java वर्चुअल मशीन के चालू होने पर असर पड़ता है. इस मशीन का इस्तेमाल Basel सर्वर प्रोसेस में किया जाता है. ये विकल्प, बाद में इस्तेमाल होने वाले उन सभी निर्देशों पर लागू होते हैं जिन्हें सर्वर मैनेज करता है. अगर पहले से चल रहा कोई Bagel सर्वर है और स्टार्टअप के विकल्प मेल नहीं खाते हैं, तो उसे रीस्टार्ट किया जाएगा.
इस सेक्शन में दिए गए सभी विकल्पों के बारे में बताने के लिए,
--key=value या --key value
सिंटैक्स का इस्तेमाल किया जाना चाहिए. साथ ही, ये विकल्प बेज़ेल कमांड के नाम से पहले दिखने चाहिए. इन्हें किसी .bazelrc फ़ाइल में शामिल करने के लिए, startup --key=value का इस्तेमाल करें.
--output_base=dir
इस विकल्प के लिए पाथ आर्ग्युमेंट होना ज़रूरी है. इसमें एक ऐसी डायरेक्ट्री होनी चाहिए जिसे लिखा जा सके. Baze, इस जगह की जानकारी का इस्तेमाल अपने आउटपुट का डेटा लिखने के लिए करेगा. आउटपुट बेस भी वह कुंजी है जिसकी मदद से क्लाइंट, बेज़ेल सर्वर खोजता है. आउटपुट बेस को बदलने पर, वह सर्वर बदल जाता है जो कमांड को हैंडल करेगा.
डिफ़ॉल्ट रूप से, आउटपुट बेस, उपयोगकर्ता के लॉगिन नेम और Workspace डायरेक्ट्री (असल में, इसका MD5 डाइजेस्ट) के नाम से लिया जाता है, इसलिए एक सामान्य वैल्यू इस तरह दिखती है:/var/tmp/google/_bazel_johndoe/d41d8cd98f00b204e9800998ecf8427e.
उदाहरण के लिए:
OUTPUT_BASE=/var/tmp/google/_bazel_johndoe/custom_output_base
% bazel --output_base ${OUTPUT_BASE}1 build //foo & bazel --output_base ${OUTPUT_BASE}2 build //bar
इस कमांड में, दो Basel के निर्देश एक साथ (शेल & ऑपरेटर की वजह से) चलते हैं,
हर एक अलग Basel सर्वर इंस्टेंस (अलग-अलग आउटपुट बेस की वजह से) का इस्तेमाल करता है.
इसके उलट, अगर दोनों कमांड में डिफ़ॉल्ट आउटपुट बेस का इस्तेमाल किया जाता है, तो दोनों अनुरोध एक ही सर्वर को भेजे जाएंगे. इससे ये अनुरोध एक क्रम में हैंडल किए जाएंगे: पहले //foo बनाना और उसके बाद //bar का इंक्रीमेंटल बिल्ड.
--output_user_root=dir
उस रूट डायरेक्ट्री पर ले जाता है जहां आउटपुट और इंस्टॉल बेस बनाए जाते हैं. डायरेक्ट्री, कॉल करने वाले उपयोगकर्ता के पास या तो मौजूद नहीं होनी चाहिए. पहले, इसकी मदद से अलग-अलग उपयोगकर्ताओं के बीच शेयर की जाने वाली डायरेक्ट्री की जानकारी ली जाती थी, लेकिन अब इसकी अनुमति नहीं थी. समस्या #11100 के हल होने के बाद, इसकी अनुमति दी जा सकती है.
अगर --output_base विकल्प बताया गया है, तो आउटपुट बेस को कैलकुलेट करने के लिए, --output_user_root का इस्तेमाल किया जाता है.
इंस्टॉल की गई जगह का हिसाब --output_user_root के साथ-साथ, Basel में एम्बेड की गई बाइनरी की MD5 पहचान के आधार पर लगाया जाता है.
अगर आपके फ़ाइल सिस्टम लेआउट में बेहतर जगह है, तो Basel के सभी आउटपुट (इंस्टॉल बेस और आउटपुट बेस) के लिए कोई अन्य बेस लोकेशन चुनने के लिए, --output_user_root विकल्प का इस्तेमाल करें.
--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 आर्ग्युमेंट माना जाएगा, लेकिन जल्द ही यह सुविधा रोक दी जाएगी.
हालांकि, इससे Baज़ल की सबप्रोसेस, ऐप्लिकेशन, टेस्ट, टूल वगैरह में इस्तेमाल होने वाले किसी भी JVM पर असर नहीं पड़ता है.
JVM विकल्पों को एक्ज़ीक्यूटेबल Java प्रोग्राम में पास करने के लिए, आपको --jvm_flags आर्ग्युमेंट का इस्तेमाल करना चाहिए
जो सभी java_binary और java_test प्रोग्राम
पर काम करता है. भले ही, इन्हें bazel
run या कमांड लाइन पर चलाया जा रहा हो. टेस्ट के लिए, bazel test --test_arg=--jvm_flags=foo ... का इस्तेमाल करें.
--host_jvm_debug
इस विकल्प की वजह से Java वर्चुअल मशीन को Bazz के मुख्य तरीके को कॉल करने से पहले, JDWP की शर्तों के हिसाब से डीबगर से कनेक्शन मिलने का इंतज़ार करना पड़ता है. इसे मुख्य रूप से, Basel डेवलपर के इस्तेमाल के लिए बनाया गया है.
--autodetect_server_javabase
इस विकल्प से Ba ज़रिए, इंस्टॉल किए गए JDK को स्टार्टअप पर अपने-आप खोज जाता है.
साथ ही, एम्बेड किया गया JRE उपलब्ध न होने पर, वह इंस्टॉल किए गए JRE पर वापस चला जाता है.
--explicit_server_javabase का इस्तेमाल करके, किसी खास JRE को चुना जा सकता है, ताकि Basel का इस्तेमाल किया जा सके.
--batch
बैच मोड की वजह से बेज़ल स्टैंडर्ड क्लाइंट/सर्वर मोड का इस्तेमाल नहीं करता, लेकिन वह एक निर्देश के लिए बेज़ल JavaScript प्रोसेस चलाता है. इसका इस्तेमाल सिग्नल हैंडलिंग, जॉब कंट्रोल, और एनवायरमेंट वैरिएबल इनहेरिटेंस के लिए ज़्यादा अनुमान लगाने लायक सिमेंटिक्स के लिए किया जाता है. साथ ही, Chrome जेल में बेज़ल चलाने के लिए ज़रूरी है.
बैच मोड, एक ही आउटपुट_base में सही सूची बनाए रखता है. इसका मतलब है कि लोगों को एक साथ प्रोसेस करने की प्रोसेस, बिना किसी ओवरलैप के क्रम में की जाएगी. अगर बैच मोड Basel को ऐसे क्लाइंट पर चलाया जाता है जिसके पास एक रनिंग सर्वर है, तो वह कमांड को प्रोसेस करने से पहले सर्वर को खत्म कर देता है.
Baज़ल, बैच मोड में या ऊपर बताए गए विकल्पों के साथ धीमा चलेगा. ऐसा इसलिए होता है, क्योंकि अन्य चीज़ों के साथ-साथ, बिल्ड फ़ाइल की कैश मेमोरी में सेव किया जाता है. इसलिए, क्रम में चलने वाले बैच को शुरू करने के दौरान, उसे सेव नहीं किया जाता. इसलिए, उन मामलों में बैच मोड का इस्तेमाल करना ज़्यादा फ़ायदेमंद होता है जहां परफ़ॉर्मेंस कम ज़रूरी होती है, जैसे कि लगातार बिल्ड.
--max_idle_secs=n
इस विकल्प से यह तय होता है कि Basel सर्वर प्रोसेस को क्लाइंट के आखिरी अनुरोध के बाद, कितनी देर तक इंतज़ार करना चाहिए. इससे पहले कि वह बाहर निकलें. डिफ़ॉल्ट तौर पर, यह वैल्यू 10800 (तीन घंटे) की होती है. --max_idle_secs=0 की वजह से, बैज सर्वर प्रोसेस हमेशा के लिए बनी रहेगी.
इस विकल्प का इस्तेमाल उन स्क्रिप्ट में किया जा सकता है जो Basel को शुरू करती हैं. इससे यह पक्का किया जा सकता है कि जब वह किसी उपयोगकर्ता की मशीन पर नहीं चल रहा हो, तो वे Baज़र के सर्वर की प्रोसेस को उसकी मशीन पर न छोड़ें.
उदाहरण के लिए, हो सकता है कि पहले से सबमिट की जाने वाली स्क्रिप्ट, bazel query को शुरू करने की कोशिश करे. इससे यह पक्का किया जा सकता है कि किसी उपयोगकर्ता के किए गए बदलाव की वजह से, अनचाही डिपेंडेंसी लागू नहीं हो रही है. हालांकि, अगर उपयोगकर्ता ने उस फ़ाइल फ़ोल्डर में हाल ही का बिल्ड नहीं किया है, तो पहले से सबमिट की गई स्क्रिप्ट के लिए बेज़ेल सर्वर को चालू करना सही नहीं होगा, ताकि वह दिन के बाकी समय तक इस्तेमाल में न रहे.
क्वेरी अनुरोध में --max_idle_secs की एक छोटी वैल्यू तय करने पर, स्क्रिप्ट यह पक्का कर सकती है कि if इसकी वजह से कोई नया सर्वर चालू होता है, तो वह सर्वर तुरंत बंद हो जाएगा. हालांकि, अगर पहले से ही कोई सर्वर चल रहा हो, तो वह सर्वर तब तक चलता रहेगा, जब तक वह आम तौर पर इस्तेमाल नहीं किया जाता. बेशक, मौजूदा सर्वर का
इस्तेमाल में न होने वाला टाइमर रीसेट कर दिया जाएगा.
--[no]shutdown_on_low_sys_mem
अगर यह नीति चालू है और --max_idle_secs को पॉज़िटिव समय पर सेट किया गया है, तो बिल्ड सर्वर के कुछ समय के लिए इस्तेमाल में न रहने पर, सिस्टम की मेमोरी कम होने पर सर्वर को बंद कर दें. सिर्फ़ Linux के लिए.
Max_idle_secs के हिसाब से कुछ समय से इस्तेमाल में न होने की जांच करने के अलावा, बिल्ड सर्वर उपलब्ध सिस्टम मेमोरी की निगरानी करना भी शुरू कर देगा. ऐसा तब होगा, जब सर्वर कुछ समय से इस्तेमाल में न हो. अगर उपलब्ध सिस्टम मेमोरी बहुत कम हो जाती है, तो सर्वर बंद हो जाएगा.
--[no]block_for_lock
अगर यह सुविधा चालू है, तो आगे बढ़ने से पहले Basel को, सर्वर लॉक को होल्ड करके रखने वाले दूसरे Basel के निर्देशों के पूरा होने का इंतज़ार करना होगा. अगर इसे बंद किया जाता है, तो अगर बैज तुरंत लॉक को हासिल करके आगे नहीं बढ़ पाता है, तो वह गलती से बाहर निकल जाएगा.
डेवलपर इसका इस्तेमाल पहले से सबमिट की जाने वाली जांच में कर सकते हैं, ताकि उसी क्लाइंट में दूसरे Basel कमांड की वजह से लंबे समय तक इंतज़ार करने से बचा जा सके.
--io_nice_level=n
IO को आसानी से शेड्यूल करने के लिए, इसे 0 से 7 के बीच का लेवल सेट करता है. 0 को सबसे ज़्यादा और 7 को सबसे कम अहमियत दी जाती है. हो सकता है कि शेड्यूल करने वाला वह प्रोग्राम, सिर्फ़ चौथी प्राथमिकता तक का हो. नेगेटिव वैल्यू को अनदेखा किया जाता है.
--batch_cpu_scheduling
Basel के लिए, batch सीपीयू शेड्यूलिंग का इस्तेमाल करें. यह नीति उन वर्कलोड के लिए काम की है जो नॉन-इंटरैक्टिव होते हैं, लेकिन उनकी अच्छी वैल्यू को कम नहीं करना चाहते.
देखें 'पुरुष 2 sched_setScheduler'. इस नीति की मदद से, बेज़ल थ्रूपुट कम पड़ सकता है और इससे सिस्टम पर
बेहतर तरीके से बातचीत की जा सकती है.
अन्य विकल्प
--[no]announce_rc
यह नीति कंट्रोल करती है कि चालू होने पर, Basel की फ़ाइलें
--color (yes|no|auto)
इस विकल्प से यह तय होता है कि Basel, अपने आउटपुट को स्क्रीन पर हाइलाइट करने के लिए कलर का इस्तेमाल करेगा या नहीं.
अगर यह विकल्प yes पर सेट किया जाता है, तो कलर आउटपुट चालू हो जाता है.
अगर यह विकल्प auto पर सेट है, तो Basel कलर आउटपुट का इस्तेमाल सिर्फ़ तब करेगा, जब आउटपुट को किसी टर्मिनल पर भेजा जा रहा हो और TERM एनवायरमेंट वैरिएबल dumb, emacs या xterm-mono के बजाय किसी दूसरी वैल्यू पर सेट किया गया हो.
अगर यह विकल्प no पर सेट है, तो कलर आउटपुट बंद हो जाता है. भले ही, आउटपुट किसी टर्मिनल पर जा रहा हो और TERM एनवायरमेंट वैरिएबल की सेटिंग कुछ भी हो.
--config=name
आरसी फ़ाइलों से अतिरिक्त कॉन्फ़िगरेशन सेक्शन चुनता है. मौजूदा command के लिए, अगर ऐसा सेक्शन मौजूद है, तो यह command:name में मौजूद विकल्पों को भी चुनता है. कई कॉन्फ़िगरेशन सेक्शन से फ़्लैग जोड़ने के लिए, कई बार तय किया जा सकता है. एक्सपेंशंस अन्य परिभाषाओं को रेफ़र कर सकते हैं
उदाहरण के लिए, एक्सपेंशन को एक-दूसरे से जोड़ा जा सकता है.
--curses (yes|no|auto)
इस विकल्प से यह तय होता है कि Basel को स्क्रीन आउटपुट में
कर्सर कंट्रोल का इस्तेमाल करने की सुविधा मिलेगी या नहीं. इससे, स्क्रोल करने वाला डेटा कम होता है. साथ ही, Basel से मिलने वाले आउटपुट की छोटी और पढ़ने में आसान स्ट्रीम होती है. यह --color के साथ अच्छे से काम करता है.
अगर यह विकल्प yes पर सेट है, तो कर्सर कंट्रोल का इस्तेमाल चालू हो जाता है.
अगर यह विकल्प no पर सेट है, तो कर्सर कंट्रोल का इस्तेमाल बंद हो जाता है.
अगर यह विकल्प auto पर सेट है, तो वही शर्तें --color=auto के लिए भी चालू हो जाएंगी जहां कर्सर कंट्रोल की सुविधा चालू होगी.
--[no]show_timestamps
अगर बताया गया हो, तो बेज़ल से जनरेट होने वाले हर मैसेज में एक टाइमस्टैंप जोड़ा जाता है. इससे यह पता चलता है कि मैसेज किस समय दिखाया गया.