इस पेज पर कई विकल्पों के बारे में बताया गया है, जैसे कि bazel build
, bazel run
, और bazel test
. यह पेज, Build with Bazel में, Bazel के निर्देशों की सूची का साथी है.
टारगेट सिंटैक्स
build
या test
जैसे कुछ निर्देश, टारगेट की सूची पर काम कर सकते हैं. इनमें लेबल के मुकाबले सिंटैक्स का इस्तेमाल ज़्यादा लचीला होता है. इसे बनाने के लिए टारगेट तय करना सेक्शन में बताया गया है.
विकल्प
नीचे दिए गए सेक्शन में बिल्ड के दौरान उपलब्ध विकल्पों के बारे में बताया
गया है. जब किसी सहायता निर्देश में --long
का इस्तेमाल किया जाता है, तब ऑन-लाइन सहायता मैसेज में हर विकल्प के मतलब, प्रकार, और डिफ़ॉल्ट वैल्यू की खास जानकारी दी जाती है.
ज़्यादातर विकल्प सिर्फ़ एक बार दिए जा सकते हैं. कई बार बताए जाने पर, पिछला इंस्टेंस जीतता है. जिन विकल्पों के बारे में कई बार बताया जा सकता है उनकी पहचान ऑन-लाइन सहायता में 'कई बार इस्तेमाल किया जा सकता है' टेक्स्ट के साथ की जाती है.
पैकेज की जगह की जानकारी
--package_path
यह विकल्प उन डायरेक्ट्री के सेट को तय करता है जिन्हें किसी दिए गए पैकेज की BUILD फ़ाइल ढूंढने के लिए खोजा जाता है.
Bazel, पैकेज पाथ में खोजकर पैकेज ढूंढता है. यह बैजल डायरेक्ट्री की कोलन से अलग की गई क्रम वाली सूची है. हर डायरेक्ट्री, आंशिक सोर्स ट्री का रूट है.
--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
में बड़ा कर दिया जाता है. - वर्किंग डायरेक्ट्री से संबंधित कोई भी अन्य चीज़ ली जाती है.
आम तौर पर, यह आपका इरादा नहीं होता.
अगर bazel वर्कस्पेस के नीचे मौजूद डायरेक्ट्री से Bazel का इस्तेमाल किया जाता है, तो यह अनचाहे तरीके से काम कर सकता है.
उदाहरण के लिए, अगर पैकेज-पाथ एलिमेंट
.
का इस्तेमाल किया जाता है और फिर cd को डायरेक्ट्री में डाला जाता है/home/bob/clients/bob_client/bazel/foo
, तो पैकेज को/home/bob/clients/bob_client/bazel/foo
डायरेक्ट्री से रिज़ॉल्व किया जाएगा.
अगर पैकेज पाथ डिफ़ॉल्ट रूप से सेट नहीं है, तो इसकी जानकारी Bazel कॉन्फ़िगरेशन फ़ाइल में दें.
Bazel के लिए यह ज़रूरी नहीं है कि किसी पैकेज को मौजूदा डायरेक्ट्री में शामिल किया जाए. इसलिए, अगर सभी ज़रूरी पैकेज, पैकेज पाथ में किसी और जगह मिल जाते हैं, तो किसी खाली बैजल फ़ाइल फ़ोल्डर से भी बिल्ड किया जा सकता है.
उदाहरण: किसी खाली क्लाइंट से बनाना
% mkdir -p foo/bazel % cd foo/bazel % touch WORKSPACE % bazel build --package_path /some/other/path //foo
--deleted_packages
इस विकल्प में उन पैकेज की कॉमा-सेपरेटेड लिस्ट होती है जिन्हें Bazel को मिटाया जाना चाहिए. साथ ही, पैकेज पाथ पर किसी भी डायरेक्ट्री से लोड करने की कोशिश नहीं करनी चाहिए. इसका इस्तेमाल, पैकेज को मिटाए बिना सिम्युलेट करने के लिए किया जा सकता है. इस विकल्प को कई बार इस्तेमाल किया जा सकता है, इस स्थिति में अलग-अलग सूचियां एक साथ जोड़ी जाती हैं.
गड़बड़ी की जांच की जा रही है
इन विकल्पों से, Bazel की गड़बड़ी की जांच करने और/या चेतावनियों को कंट्रोल किया जाता है.
--[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` | कुछ न दिखाएं. |
टूल फ़्लैग
इन विकल्पों से यह तय होता है कि Bazel, दूसरे टूल को कौनसे विकल्प देगा.
--copt=cc-option
इस विकल्प में आर्ग्युमेंट की ज़रूरत होती है, जिसे कंपाइलर को भेजा जाता है. जब भी प्रीप्रोसेस, कंपाइलिंग, और/या C, C++ या असेंबलर कोड को असेंबल किया जाएगा, तब आर्ग्युमेंट को कंपाइलर में पास किया जाएगा. लिंक करते समय, यह जानकारी पास नहीं होगी.
इस विकल्प का इस्तेमाल एक से ज़्यादा बार किया जा सकता है. उदाहरण के लिए:
% bazel build --copt="-g0" --copt="-fpic" //foo
foo
लाइब्रेरी को बिना डीबग टेबल के कंपाइल करेगा. इससे
पोज़िशन-इंडिपेंडेंट कोड जनरेट होगा.
--host_copt=cc-option
यह विकल्प एक आर्ग्युमेंट लेता है, जिसे कंपाइलर को उन सोर्स फ़ाइलों के लिए भेजा जाता है जिन्हें एक्ज़ीक्यूट की गई कॉन्फ़िगरेशन में कंपाइल किया जाता है. यह --copt
विकल्प के जैसा है, लेकिन सिर्फ़ कॉन्फ़िगरेशन पर लागू होता है.
--host_conlyopt=cc-option
इस विकल्प में एक आर्ग्युमेंट का इस्तेमाल किया जाता है, जिसे कॉन्फ़िगरेशन में कंपाइल की गई C सोर्स फ़ाइलों
के लिए कंपाइलर को भेजा जाता है. यह --conlyopt
विकल्प के जैसा है, लेकिन सिर्फ़ एक्सपोर्ट कॉन्फ़िगरेशन पर लागू होता है.
--host_cxxopt=cc-option
यह विकल्प एक आर्ग्युमेंट लेता है, जिसे दूसरी बार कॉन्फ़िगरेशन में कंपाइल की गई C++ सोर्स फ़ाइलों के लिए, कंपाइलर को भेजा जाता है. यह --cxxopt
विकल्प के जैसा है, लेकिन सिर्फ़ कॉन्फ़िगरेशन पर लागू होता है.
--host_linkopt=linker-option
यह विकल्प एक आर्ग्युमेंट लेता है, जिसे exec कॉन्फ़िगरेशन में कंपाइल की गई सोर्स फ़ाइलों के लिए, लिंकर को भेजा जाता है. यह --linkopt
विकल्प के जैसा है, लेकिन सिर्फ़ exec कॉन्फ़िगरेशन पर लागू होता है.
--conlyopt=cc-option
इस विकल्प में एक आर्ग्युमेंट का इस्तेमाल किया जाता है, जिसे C सोर्स फ़ाइलों को कंपाइल करते समय, कंपाइलर को भेजा जाता है.
यह --copt
की तरह है, लेकिन सिर्फ़ C कंपाइलेशन पर लागू होता है. C++ कंपाइलेशन या लिंकिंग पर नहीं. इसलिए, --conlyopt
का इस्तेमाल करके सी-खास विकल्प
(जैसे, -Wno-pointer-sign
) पास किए जा सकते हैं.
--cxxopt=cc-option
इस विकल्प में एक आर्ग्युमेंट इस्तेमाल किया जाता है, जिसे C++ सोर्स फ़ाइलों को कंपाइल करते समय, कंपाइलर को भेजा जाता है.
यह --copt
की तरह है, लेकिन सिर्फ़ C++ कंपाइलेशन पर लागू होता है,
C कंपाइलेशन या लिंकिंग पर नहीं. इसलिए, --cxxopt
का इस्तेमाल करके C++ के खास विकल्प
(जैसे कि -fpermissive
या -fno-implicit-templates
) पास किए जा सकते हैं.
उदाहरण के लिए:
% bazel build --cxxopt="-fpermissive" --cxxopt="-Wno-error" //foo/cruddy_code
--linkopt=linker-option
यह विकल्प एक आर्ग्युमेंट लेता है, जिसे लिंक करते समय कंपाइलर को भेजा जाता है.
यह --copt
से मिलता-जुलता है. हालांकि, यह सिर्फ़ लिंक करने पर लागू होता है, कंपाइलेशन पर नहीं. इसलिए, ऐसे कंपाइलर विकल्प पास किए जा सकते हैं जो --linkopt
का इस्तेमाल करके, लिंक करने के समय ही काम के होते हैं (जैसे कि -lssp
या -Wl,--wrap,abort
). उदाहरण के लिए:
% bazel build --copt="-fmudflap" --linkopt="-lmudflap" //foo/buggy_code
बिल्ड के नियम भी अपने एट्रिब्यूट में लिंक के विकल्प तय कर सकते हैं. इस विकल्प की सेटिंग को हमेशा प्राथमिकता दी जाती है. cc_library.linkopts भी देखें.
--strip (always|never|sometimes)
यह विकल्प तय करता है कि क्या Bazel, लिंकर को -Wl,--strip-debug
विकल्प की मदद से शुरू करके, सभी बाइनरी और शेयर की गई लाइब्रेरी से डीबग करने की जानकारी मिटा देगा.
--strip=always
का मतलब है कि डीबग करने की जानकारी को हमेशा हटा दें.
--strip=never
का मतलब है कि डीबग करने की जानकारी कभी भी न हटाएं.
--strip=sometimes
की डिफ़ॉल्ट वैल्यू का मतलब है कि अगर --compilation_mode
fastbuild
है, तो हटाएं.
% bazel build --strip=always //foo:bar
जनरेट की गई सभी बाइनरी से डीबग करने की जानकारी हटाकर, टारगेट को कंपाइल करेगा.
Bazel का --strip
विकल्प, ld के --strip-debug
विकल्प से मेल खाता है:
यह सिर्फ़ डीबग करने की जानकारी को हटाता है. अगर किसी वजह से सिर्फ़ डीबग सिंबल ही नहीं, बल्कि सभी सिंबल को हटाना है, तो आपको ld के --strip-all
विकल्प का इस्तेमाल करना होगा. यह विकल्प, --linkopt=-Wl,--strip-all
को Bazel के पास भेजकर किया जा सकता है. साथ ही,
ध्यान रखें कि Bazel का --strip
फ़्लैग सेट करने पर,
--linkopt=-Wl,--strip-all
बदल जाएगा. इसलिए, आपको सिर्फ़ एक या दोनों को ही सेट करना चाहिए.
अगर आपको सिर्फ़ एक बाइनरी बनानी है और सभी सिंबल को हटाना है, तो आपके पास --stripopt=--strip-all
को पास करने और टारगेट का //foo:bar.stripped
वर्शन बनाने का विकल्प भी है. जैसा कि --stripopt
के सेक्शन में बताया गया है, यह फ़ाइनल बाइनरी के लिंक होने के बाद, स्ट्रिप से जुड़ी कार्रवाई लागू करता है. इसके लिए, बिल्ड के सभी लिंक से जुड़ी कार्रवाइयों को शामिल नहीं किया जाता.
--stripopt=strip-option
*.stripped
बाइनरी जनरेट करते समय, यह strip
कमांड को पास करने का एक और विकल्प है. डिफ़ॉल्ट
-S -p
है. इस विकल्प का इस्तेमाल एक से ज़्यादा बार किया जा सकता है.
--fdo_instrument=profile-output-dir
--fdo_instrument
विकल्प, बनी हुई C/C++ बाइनरी को एक्ज़ीक्यूट करने पर, एफ़डीओ (फ़ीडबैक से आने वाले ऑप्टिमाइज़ेशन) प्रोफ़ाइल आउटपुट को जनरेट करने की सुविधा देता है. जीसीसी के लिए दिए गए तर्क का इस्तेमाल, .gcda फ़ाइलों के हर ऑब्जेक्ट फ़ाइल डायरेक्ट्री ट्री के लिए डायरेक्ट्री प्रीफ़िक्स के तौर पर किया जाता है. इस ट्री में हर .o फ़ाइल की प्रोफ़ाइल जानकारी होती है.
प्रोफ़ाइल डेटा ट्री जनरेट होने के बाद, प्रोफ़ाइल ट्री
को zip किया जाना चाहिए. इसके बाद,
--fdo_optimize=profile-zip
FDO के लिए ऑप्टिमाइज़ किए गए कंपाइलेशन को चालू करने के लिए, Bazel का विकल्प दिया जाना चाहिए.
LLVM कंपाइलर के लिए, आर्ग्युमेंट वह डायरेक्ट्री भी है जिसके तहत रॉ LLVM प्रोफ़ाइल
डेटा फ़ाइल(फ़ाइलों) को डंप किया जाता है. उदाहरण के लिए:
--fdo_instrument=/path/to/rawprof/dir/
.
एक ही समय पर --fdo_instrument
और --fdo_optimize
विकल्प इस्तेमाल नहीं किए जा सकते.
--fdo_optimize=profile-zip
--fdo_optimize
विकल्प, कंपाइल करते समय एफ़डीओ (फ़ीडबैक
डायरेक्ट ऑप्टिमाइज़ेशन) ऑप्टिमाइज़ेशन करने के लिए, हर ऑब्जेक्ट फ़ाइल प्रोफ़ाइल की जानकारी का इस्तेमाल करता है. जीसीसी के लिए दिया गया तर्क,
वह ZIP फ़ाइल है जिसमें .gcda फ़ाइलों के लिए, पहले से जनरेट की गई
फ़ाइल ट्री होती है. इस फ़ाइल में हर .o फ़ाइल की प्रोफ़ाइल जानकारी होती है.
इसके अलावा, दिया गया तर्क, .afdo एक्सटेंशन से पहचानी गई ऑटो प्रोफ़ाइल की ओर इशारा कर सकता है.
LLVM कंपाइलर के लिए, दिया गया आर्ग्युमेंट, इंडेक्स की गई 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 स्पेसिफ़िकेशन के साथ काम करने वाले कंस्ट्रक्ट को कंपाइल करता है और उन्हें अनुमति देता है.
डिफ़ॉल्ट वैल्यू 11 है. -->
संभावित वैल्यू हैं: 8, 9, 10, 11, 14, और 15. इन्हें default_java_toolchain
का इस्तेमाल करके, कस्टम Java टूलचेन में रजिस्टर करके बढ़ाया जा सकता है.
--tool_java_language_version=version
Java लैंग्वेज वर्शन, जिसका इस्तेमाल ऐसे टूल बनाने के लिए किया जाता है जिन्हें बिल्ड के दौरान इस्तेमाल किया जाता है. डिफ़ॉल्ट वैल्यू 11 है.
--java_runtime_version=version
यह विकल्प कोड को एक्ज़ीक्यूट करने और टेस्ट चलाने के लिए, JVM का वर्शन तय करता है. जैसे:
% bazel run --java_runtime_version=remotejdk_11 java/com/example/common/foo:java_application
यह रिमोट रिपॉज़िटरी (डेटा स्टोर करने की जगह) से JDK 11 डाउनलोड करता है और उसका इस्तेमाल करके Java ऐप्लिकेशन चलाता है.
डिफ़ॉल्ट वैल्यू local_jdk
है.
इसकी वैल्यू डाली जा सकती हैं: local_jdk
, local_jdk_version
,
remotejdk_11
, और remotejdk_17
.
local_java_repository
या remote_java_repository
रिपॉज़िटरी के नियमों का इस्तेमाल करके, कस्टम जेवीएम को रजिस्टर करके वैल्यू बढ़ाई जा सकती है.
--tool_java_runtime_version=version
यह जेवीएम का वर्शन है, जिसका इस्तेमाल बिल्ड के दौरान ज़रूरी टूल चलाने के लिए किया जाता है.
डिफ़ॉल्ट वैल्यू remotejdk_11
है.
--jvmopt=jvm-option
इस विकल्प की मदद से, विकल्प के तर्कों को Java वीएम में भेजा जा सकता है. इसका इस्तेमाल एक बड़े तर्क के साथ या अलग-अलग तर्कों के साथ कई बार किया जा सकता है. उदाहरण के लिए:
% bazel build --jvmopt="-server -Xms256m" java/com/example/common/foo:all
सभी Java बाइनरी को लॉन्च करने के लिए, सर्वर वीएम का इस्तेमाल करेगा और वीएम के लिए स्टार्टअप हीप साइज़ को 256 एमबी पर सेट करेगा.
--javacopt=javac-option
यह विकल्प, विकल्प के तर्कों को javac में पास करने की अनुमति देता है. इसका इस्तेमाल एक बड़े तर्क के साथ या अलग-अलग तर्कों के साथ कई बार किया जा सकता है. उदाहरण के लिए:
% bazel build --javacopt="-g:source,lines" //myprojects:prog
javac डिफ़ॉल्ट डीबग जानकारी के साथ java_binary फिर से बनाएगा (बज़ल डिफ़ॉल्ट के बजाय).
यह विकल्प, javac को पास किया जाता है. ऐसा, Javac के लिए बिल्ट-इन डिफ़ॉल्ट विकल्पों के बाद और हर नियम के विकल्पों से पहले किया जाता है. javac जीत के लिए किसी भी विकल्प की आखिरी विशेषता. javac के लिए डिफ़ॉल्ट विकल्प हैं:
-source 8 -target 8 -encoding UTF-8
--strict_java_deps (default|strict|off|warn|error)
इस विकल्प से यह कंट्रोल किया जाता है कि javac छूटी हुई डायरेक्ट डिपेंडेंसी के लिए जांच करता है या नहीं. Java टारगेट को सीधे तौर पर इस्तेमाल किए जाने वाले सभी टारगेट को, डिपेंडेंसी के तौर पर बताना होगा. यह फ़्लैग javac को हर JavaScript फ़ाइल के टाइप की जांच करने के लिए इस्तेमाल किए गए जार तय करने का निर्देश देता है. साथ ही, अगर वे मौजूदा टारगेट के आउटपुट डायरेक्ट डिपेंडेंसी के आउटपुट नहीं हैं, तो उसे चेतावनी देने/गड़बड़ी करने का निर्देश देता है.
off
का मतलब है कि जांच करने की सुविधा बंद है.warn
का मतलब है कि javac हर डायरेक्ट डिपेंडेंसी के लिए,[strict]
टाइप की स्टैंडर्ड JavaScript चेतावनियां जनरेट करेगा.default
,strict
, औरerror
सभी मीन JavaScript, चेतावनियों के बजाय गड़बड़ियां जनरेट करेंगे. इसकी वजह से, कोई भी छूटी हुई डायरेक्ट डिपेंडेंसी मिलने पर मौजूदा टारगेट, पूरा नहीं हो पाएगा. फ़्लैग के तय न होने पर भी यह डिफ़ॉल्ट तरीका होता है.
सिमेंटिक्स बनाएं
ये विकल्प, बिल्ड कमांड और/या आउटपुट फ़ाइल के कॉन्टेंट पर असर डालते हैं.
--compilation_mode (fastbuild|opt|dbg)
(-c)
--compilation_mode
विकल्प (अक्सर -c
, खास तौर पर -c opt
में छोटा किया जाता है) fastbuild
, dbg
या opt
का एक आर्ग्युमेंट लेता है. यह कई C/C++ कोड जनरेट करने वाले विकल्पों पर असर डालता है, जैसे कि ऑप्टिमाइज़ेशन का लेवल और डीबग टेबल का पूरा होना. Bazel हर अलग तरह के कंपाइलेशन मोड के लिए, एक अलग आउटपुट डायरेक्ट्री का इस्तेमाल करता है. इससे, आपको हर बार पूरी तरह से फिर से बिल्ड करने की ज़रूरत बिना मोड के बीच स्विच करने में मदद मिलती है.
fastbuild
का मतलब है, जल्द से जल्द कॉन्टेंट बनाना: डीबग करने की कम से कम जानकारी जनरेट करें (-gmlt -Wl,-S
) और ऑप्टिमाइज़ न करें. यह डिफ़ॉल्ट है. ध्यान दें:-DNDEBUG
को सेट नहीं किया जाएगा.dbg
का मतलब है कि डीबग करने की सुविधा चालू करके बिल्ड (-g
) किया जा सकता है, ताकि आप gdb (या किसी दूसरे डीबगर) का इस्तेमाल कर सकें.opt
का मतलब है कि ऑप्टिमाइज़ेशन चालू के साथ औरassert()
कॉल बंद (-O2 -DNDEBUG
) के साथ. डीबग करने की जानकारीopt
मोड में जनरेट नहीं होगी, जब तक कि आप--copt -g
को पास नहीं कर लेते.
--cpu=cpu
यह विकल्प, टारगेट सीपीयू आर्किटेक्चर के बारे में बताता है, इसका इस्तेमाल बिल्ड के दौरान बाइनरी को कंपाइल करने के लिए किया जाता है.
--action_env=VAR=VALUE
सभी कार्रवाइयों के दौरान उपलब्ध एनवायरमेंट वैरिएबल के सेट को तय करता है.
वैरिएबल को नाम से तय किया जा सकता है. इस मामले में, वैल्यू को शुरू करने वाले एनवायरमेंट से या name=value
जोड़े से लिया जाएगा, जो वैल्यू को शुरू करने वाले एनवायरमेंट से अलग सेट करता है.
इस --action_env
फ़्लैग के बारे में एक से ज़्यादा बार बताया जा सकता है. अगर एक से ज़्यादा --action_env
फ़्लैग में एक ही वैरिएबल को कोई वैल्यू असाइन की जाती है, तो सबसे नया असाइनमेंट मिलेगा.
--experimental_action_listener=label
experimental_action_listener
विकल्प, बज़ल को बिल्ड ग्राफ़ में extra_actions
डालने के लिए, label में बताए गए action_listener
नियम की जानकारी का इस्तेमाल करने का निर्देश देता है.
--[no]experimental_extra_action_top_level_only
अगर यह विकल्प 'सही है' पर सेट है, तो --experimental_action_listener
कमांड लाइन विकल्प से तय की गई
अतिरिक्त कार्रवाइयां, सिर्फ़ टॉप लेवल टारगेट के लिए शेड्यूल की जाएंगी.
--experimental_extra_action_filter=regex
यह experimental_extra_action_filter
विकल्प, Bazel को टारगेट के सेट को फ़िल्टर करने का निर्देश देता है, ताकि extra_actions
को शेड्यूल किया जा सके.
इस फ़्लैग को सिर्फ़
--experimental_action_listener
फ़्लैग के साथ इस्तेमाल किया जा सकता है.
जिस टारगेट को बनाने के लिए अनुरोध किया गया है उसके ट्रांज़िटिव सेशन में मौजूद सभी extra_actions
, डिफ़ॉल्ट रूप से एक्ज़ीक्यूट होने के लिए शेड्यूल हो जाते हैं.
--experimental_extra_action_filter
शेड्यूल को extra_actions
तक सीमित करेगा, जिसमें से मालिक का लेबल तय रेगुलर एक्सप्रेशन से मेल खाता है.
इस उदाहरण में, extra_actions
का शेड्यूलिंग तय करने का विकल्प सिर्फ़ उन कार्रवाइयों पर लागू होगा जिनमें मालिक के लेबल में '/bar/' शामिल हो:
% bazel build --experimental_action_listener=//test:al //foo/... \ --experimental_extra_action_filter=.*/bar/.*
--host_cpu=cpu
यह विकल्प उस सीपीयू आर्किटेक्चर का नाम बताता है जिसका इस्तेमाल होस्ट टूल बनाने के लिए किया जाना चाहिए.
--android_platforms=platform[,platform]*
android_binary
के ट्रांज़िटिव deps
नियमों को बनाने वाले प्लैटफ़ॉर्म (खास तौर पर C++ जैसी नेटिव डिपेंडेंसी के लिए). उदाहरण
के लिए, अगर किसी android_binary
नियम के ट्रांज़िटिव deps
में cc_library
दिखता है, तो इसे android_binary
नियम के लिए --android_platforms
के साथ बताए गए हर प्लैटफ़ॉर्म के लिए एक बार बनाया जाता है और आखिरी
आउटपुट में शामिल किया जाता है.
इस फ़्लैग के लिए कोई डिफ़ॉल्ट मान नहीं है: कस्टम Android प्लैटफ़ॉर्म तय करके इस्तेमाल किया जाना चाहिए.
--android_platforms
में बताए गए हर प्लैटफ़ॉर्म के लिए, APK में एक .so
फ़ाइल बनाई और पैकेज की जाती है. .so
फ़ाइल का नाम,
android_binary
नियम के नाम के आगे "lib" लगा होता है. उदाहरण के लिए, अगर android_binary
का नाम "foo" है, तो फ़ाइल libfoo.so
होगी.
--per_file_copt=[+-]regex[,[+-]regex]...@option[,option]...
मौजूद होने पर, लेबल या एक्ज़ीक्यूशन पाथ वाली कोई भी C++ फ़ाइल दिए गए विकल्पों के साथ बनाई जाएगी. लेबल मैचिंग करने के लिए, लेबल के कैननिकल फ़ॉर्म का इस्तेमाल किया जाता है
(जैसे, //package
:label_name
).
एक्ज़ीक्यूशन पाथ आपकी फ़ाइल फ़ोल्डर की डायरेक्ट्री से जुड़ा पाथ होता है. इसमें C++ फ़ाइल का बेस नाम (एक्सटेंशन के साथ) भी शामिल होता है. इसमें प्लैटफ़ॉर्म पर निर्भर करने वाले प्रीफ़िक्स भी शामिल हैं.
जनरेट की गई फ़ाइलों (जैसे कि genrule आउटपुट) से मैच करने के लिए,
Bazel सिर्फ़ प्रोग्राम चलाने के पाथ का इस्तेमाल कर सकता है. इस मामले में 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
फ़ाइलों के लिए, file.cc
को छोड़कर, -O0
और -fprofile-arcs
विकल्प को C++ कंपाइलर की कमांड लाइन में जोड़ता है.
--dynamic_mode=mode
बिल्ड के नियमों पर linkstatic एट्रिब्यूट के साथ इंटरैक्ट करते हुए, तय करता है कि C++ बाइनरी को डाइनैमिक तौर पर लिंक किया जाएगा या नहीं.
मोड:
auto
: प्लैटफ़ॉर्म पर निर्भर मोड में अनुवाद करता है. लिनक्स के लिएdefault
और साइगविन के लिएoff
.default
: इससे bazel यह चुन सकता है कि डाइनैमिक रूप से लिंक करना है या नहीं. ज़्यादा जानकारी के लिए linkstatic देखें.fully
: सभी टारगेट को डाइनैमिक तौर पर लिंक करता है. इससे, लिंक करने में लगने वाला समय तेज़ी से होगा और जनरेट होने वाली बाइनरी की संख्या भी कम हो जाएगी.off
: सभी टारगेट को ज़्यादातर स्टैटिक मोड में लिंक करता है. अगर-static
को लिंकऑप्ट में सेट किया गया है, तो टारगेट पूरी तरह से स्टैटिक हो जाएंगे.
--fission (yes|no|[dbg][,opt][,fastbuild])
Fission को चालू करता है, जो C++ डीबग जानकारी को .o फ़ाइलों के बजाय खास .dwo फ़ाइलों में लिखता है, जहां ऐसा नहीं होता है. इससे लिंक का इनपुट साइज़ काफ़ी कम हो जाता है और लिंक का समय कम हो सकता है.
अगर वैल्यू को [dbg][,opt][,fastbuild]
(उदाहरण:
--fission=dbg,fastbuild
) पर सेट किया जाता है, तो कॉन्फ़िगरेशन सिर्फ़ कंपाइलेशन मोड के तय सेट के लिए चालू होता है. यह bazelrc सेटिंग
के लिए फ़ायदेमंद है. yes
पर सेट करने पर, Fission
सभी के लिए चालू हो जाता है. जब no
पर सेट किया जाता है, तो Fission सभी के लिए
बंद हो जाता है. डिफ़ॉल्ट वैल्यू no
है.
--force_ignore_dash_static
अगर यह फ़्लैग सेट किया जाता है, तो
cc_*
नियमों के लिंक की सुविधा में मौजूद -static
के किसी भी विकल्प को अनदेखा कर दिया जाता है. इसका मकसद सिर्फ़ C++ के मज़बूत बिल्ड के लिए है.
--[no]force_pic
अगर यह नीति चालू होती है, तो सभी C++ कंपाइलेशन पोज़िशन-इंडिपेंडेंट कोड ("-fPIC") बनाते हैं. लिंक, गैर-पीआईसी लाइब्रेरी के बजाय पहले से बनी लाइब्रेरी पीआईसी को प्राथमिकता देते हैं और लिंक, रैंक पर निर्भर एक्ज़ीक्यूटेबल ("-पाई") बनाते हैं. डिफ़ॉल्ट रूप से बंद होती है.
--android_resource_shrinking
चुनें कि android_binary नियमों के लिए रिसॉर्स को छोटा करना है या नहीं. android_binary नियमों पर shrink_resources एट्रिब्यूट के लिए डिफ़ॉल्ट सेट किया जाता है. ज़्यादा जानकारी के लिए उस नियम से जुड़े दस्तावेज़ देखें. डिफ़ॉल्ट तौर पर, यह बंद रहता है.
--custom_malloc=malloc-library-target
जब भी तय किया जाए, तब सभी malloc="target"
एट्रिब्यूट को बदलते हुए, दिए गए
maloc इंप्लीमेंटेशन का इस्तेमाल करें. इसमें वे टारगेट भी शामिल हैं जो डिफ़ॉल्ट
को इस्तेमाल करते हैं. इसके लिए, malloc
एट्रिब्यूट की वैल्यू शामिल न करें.
--crosstool_top=label
यह विकल्प क्रॉसटूल कंपाइलर सुइट की जगह के बारे में बताता है,
जिसे बिल्ड के दौरान सभी C++ कंपाइलेशन के लिए इस्तेमाल किया जाना चाहिए. Bazel, CROSSTOOL फ़ाइल के लिए उस जगह को देखेगा और उसका इस्तेमाल करके, --compiler
के लिए अपने-आप सेटिंग तय करेगा.
--host_crosstool_top=label
अगर इसके बारे में नहीं बताया गया है, तो Bazel, एक्ज़ीक्यूटेबल कॉन्फ़िगरेशन में कोड कंपाइल करने के लिए --crosstool_top
की वैल्यू इस्तेमाल करता है, जैसे कि बिल्ड के दौरान चलने वाले टूल. इस फ़्लैग का मुख्य मकसद
क्रॉस-कंपाइलेशन को चालू करना है.
--apple_crosstool_top=label
objc*, ios*, और apple* के नियमों के ट्रांज़िटिव deps
में, C/C++ नियमों को कंपाइल करने के लिए इस्तेमाल किया जाने वाला क्रॉसटूल. उन टारगेट के लिए, यह फ़्लैग
--crosstool_top
को बदल देता है.
--android_crosstool_top=label
android_binary
में से deps
नियमों में, C/C++ नियमों को कंपाइल करने के लिए इस्तेमाल किया जाने वाला क्रॉसटूल. यह तब काम आता है, जब बिल्ड में मौजूद अन्य टारगेट के लिए किसी
दूसरे क्रॉसटूल की ज़रूरत हो. डिफ़ॉल्ट तौर पर, Workspace की फ़ाइल में android_ndk_repository
नियम से जनरेट किए गए
क्रॉसटूल का इस्तेमाल किया जाता है.
--android_platforms
भी देखें.
--compiler=version
यह विकल्प, C/C++ कंपाइलर वर्शन (जैसे कि gcc-4.1.0
) के बारे में बताता है, जिसका इस्तेमाल बिल्ड के दौरान बाइनरी को कंपाइल करने के लिए किया जाना चाहिए. अगर आपको कोई कस्टम क्रॉसटूल
बनाना है, तो इस फ़्लैग के बारे में बताने के बजाय,
आपको CROSSTOOL फ़ाइल का इस्तेमाल करना चाहिए.
--android_sdk=label
समर्थन नहीं होना या रुकना. यह सीधे तौर पर नहीं बताया जाना चाहिए.
इस विकल्प से Android SDK/प्लैटफ़ॉर्म टूलचेन और Android रनटाइम लाइब्रेरी के बारे में पता चलता है. इनका इस्तेमाल Android से जुड़े किसी भी नियम को बनाने के लिए किया जाएगा.
अगर workspace फ़ाइल में android_sdk_repository
नियम तय किया गया है, तो Android SDK अपने-आप चुन लिया जाएगा.
--java_toolchain=label
यह विकल्प, Java सोर्स फ़ाइलों को कंपाइल करने के लिए इस्तेमाल किए जाने वाले java_toolchain के लेबल के बारे में बताता है.
--host_java_toolchain=label
अगर इसके बारे में बताया नहीं गया है, तो bazel कॉन्फ़िगरेशन में कोड को कंपाइल करने के लिए, --java_toolchain
की वैल्यू का इस्तेमाल करता है, जैसे कि बिल्ड के दौरान चलने वाले टूल के लिए. इस फ़्लैग का मुख्य मकसद
क्रॉस-कंपाइलेशन को चालू करना है.
--javabase=(label)
इस विकल्प से, बेस Java इंस्टॉलेशन का लेबल सेट किया जाता है, ताकि bazel Run, bazel टेस्ट, और java_binary
और
java_test
नियमों के बनाए गए Java बाइनरी के लिए उसका इस्तेमाल किया जा सके. JAVABASE
और JAVA
"Make" वैरिएबल इस विकल्प से लिए जाते हैं.
--host_javabase=label
यह विकल्प, बेस Java इंस्टॉलेशन का लेबल सेट करता है, ताकि उसे exec कॉन्फ़िगरेशन में इस्तेमाल किया जा सके. उदाहरण के लिए, JavaBuilder और SingleJ जैसी होस्ट करने वाली कंपनियों के होस्ट के लिए इस्तेमाल होने वाले टूल.
यह Java सोर्स फ़ाइलों को कंपाइल करने के लिए इस्तेमाल होने वाले Java कंपाइलर को नहीं चुनता है. कंपाइलर को,
--java_toolchain
विकल्प की सेटिंग में जाकर चुना जा सकता है.
स्क्रिप्ट रन करने की रणनीति
इन विकल्पों से तय होता है कि Bazel, बिल्ड को कैसे लागू करेगा. बिल्ड से जनरेट की गई आउटपुट फ़ाइलों पर कोई खास असर नहीं होना चाहिए. आम तौर पर, उनका मुख्य असर बिल्डिंग की स्पीड पर होता है.
--spawn_strategy=strategy
इस विकल्प से यह कंट्रोल किया जाता है कि निर्देश कहां और कैसे लागू होते हैं.
standalone
की वजह से कमांड, लोकल सबप्रोसेस के तौर पर लागू होते हैं. यह मान अब सेवा में नहीं है. इसके बजाय, कृपयाlocal
का इस्तेमाल करें.sandboxed
की वजह से, लोकल मशीन पर सैंडबॉक्स में निर्देश लागू होते हैं. इसके लिए ज़रूरी है कि सभी इनपुट फ़ाइलें, डेटा डिपेंडेंसी, और टूलsrcs
,data
, औरtools
एट्रिब्यूट में डायरेक्ट डिपेंडेंसी के तौर पर लिस्ट किए गए हों. Bazel, डिफ़ॉल्ट रूप से लोकल सैंडबॉक्सिंग की सुविधा चालू करता है. यह सुविधा उन सिस्टम पर काम करती है जो सैंडबॉक्स किए गए एक्ज़ीक्यूशन के साथ काम करते हैं.local
की वजह से कमांड, लोकल सबप्रोसेस के तौर पर लागू होते हैं.- अगर उपलब्ध हो, तो
worker
किसी स्थायी वर्कर का इस्तेमाल करके, निर्देश लागू करता है. docker
की वजह से, लोकल मशीन पर डॉकर सैंडबॉक्स में, निर्देश लागू होते हैं. इसके लिए ज़रूरी है कि डॉकर इंस्टॉल किया गया हो.remote
की वजह से, निर्देश रिमोट तरीके से चलाए जाते हैं. यह सिर्फ़ तब उपलब्ध होता है, जब रिमोट एक्ज़ीक्यूटर को अलग से कॉन्फ़िगर किया गया हो.
--strategy mnemonic=strategy
इस विकल्प से यह कंट्रोल किया जाता है कि निर्देश कहां और कैसे लागू किए जाते हैं. यह हर मेनेमॉनिक के आधार पर --spawn_strategy (और --genrule_strategy) से बदल दिया जाता है. काम करने वाली रणनीतियों और उनके असर के बारे में जानने के लिए, --spawn_strategy देखें.
--strategy_regexp=<filter,filter,...>=<strategy>
इस विकल्प से तय होता है कि किसी खास regex_filter
से मेल खाने वाले निर्देश चलाने के लिए, किस रणनीति का इस्तेमाल किया जाना चाहिए. रेगुलर एक्सप्रेशन फ़िल्टर को मैच कराने के बारे में ज़्यादा जानने के लिए,
--per_file_copt
देखें. काम करने वाली रणनीतियों और उनके असर के बारे में जानने के लिए,
--spawn_strategy देखें.
ब्यौरे से मेल खाने वाले आखिरी regex_filter
का इस्तेमाल किया गया है. यह विकल्प, रणनीति तय करने के लिए दूसरे फ़्लैग को बदल देता है.
- उदाहरण:
--strategy_regexp=//foo.*\\.cc,-//foo/bar=local
का मतलब,local
रणनीति का इस्तेमाल करके कार्रवाइयां तब चलाना है, जब उनकी जानकारी //foo.*.cc से मेल खाती हो, लेकिन //foo/bar नहीं. - उदाहरण:
--strategy_regexp='Compiling.*/bar=local' --strategy_regexp=Compiling=sandboxed
sandboxed
रणनीति के साथ 'Compiling //foo/bar/baz' करता है, लेकिन क्रम में बदलाव करने पर यहlocal
के साथ चलता है. - उदाहरण:
--strategy_regexp='Compiling.*/bar=local,sandboxed'
, '//foo/Bar/baz' कोlocal
रणनीति के साथ चलाता है और काम न करने पर,sandboxed
पर वापस चला जाता है.
--genrule_strategy=strategy
यह --strategy=Genrule=strategy
के लिए अब काम नहीं करता शॉर्ट-हैंड है.
--jobs=n
(-j)
यह विकल्प, इंटीजर आर्ग्युमेंट की मदद से, उन जॉब की संख्या की सीमा तय करता है जिन्हें बिल्ड के रनिंग फ़ेज़ के दौरान एक साथ लागू किया जाना चाहिए.
--progress_report_interval=n
Bazel, समय-समय पर उन कामों की प्रोग्रेस रिपोर्ट प्रिंट करता है जो अभी पूरी नहीं हुई हैं (जैसे, लंबे समय तक चलने वाले टेस्ट). यह विकल्प रिपोर्टिंग की फ़्रीक्वेंसी सेट करता है. प्रोग्रेस को हर n
सेकंड में प्रिंट किया जाएगा.
डिफ़ॉल्ट 0 है. इसका मतलब है कि इंक्रीमेंटल एल्गोरिदम: पहली रिपोर्ट 10 सेकंड के बाद प्रिंट की जाएगी. इसके बाद, 30 सेकंड के बाद और प्रोसेस को हर मिनट में एक बार रिपोर्ट किया जाएगा.
जब बाज़ल, कर्सर कंट्रोल का इस्तेमाल कर रहा हो, जैसा कि --curses
में बताया गया है, तब प्रोग्रेस की जानकारी हर सेकंड के हिसाब से दी जाती है.
--local_{ram,cpu}_resources resources or resource expression
ये विकल्प ऐसे लोकल रिसॉर्स की संख्या (एमबी में रैम और सीपीयू लॉजिकल कोर की संख्या) की संख्या तय करते हैं जिन्हें Bazel, स्थानीय तौर पर चलाने के लिए बिल्ड और टेस्ट गतिविधियों को शेड्यूल करते समय ध्यान में रख सकता है. वे
एक पूर्णांक या कीवर्ड (Host_RAM या Host_CPUS) लेते हैं, जिसके बाद [-|*
फ़्लोट]
होता है
(उदाहरण के लिए, --local_cpu_resources=2
, --local_ram_resources=HOST_RAM*.5
,
--local_cpu_resources=HOST_CPUS-1
).
फ़्लैग अलग-अलग होते हैं; एक या दोनों सेट किए जा सकते हैं. डिफ़ॉल्ट रूप से, Bazel स्थानीय सिस्टम के कॉन्फ़िगरेशन से सीधे
रैम की मात्रा और सीपीयू कोर की संख्या का अनुमान लगाता है.
--[no]build_runfile_links
यह विकल्प डिफ़ॉल्ट रूप से चालू होता है. इससे पता चलता है कि टेस्ट और बाइनरी के लिए रनफ़ाइल सिमलिंक, आउटपुट डायरेक्ट्री में बनाए जाने चाहिए या नहीं.
--nobuild_runfile_links
का इस्तेमाल करके यह पुष्टि की जा सकती है कि सभी टारगेट इकट्ठा किए जाते हैं या नहीं. इसके लिए, रनफ़ाइल ट्री बनाने के लिए कोई खर्च नहीं करना पड़ता.
जब टेस्ट (या ऐप्लिकेशन) लागू किए जाते हैं, तो उनकी रन-टाइम डेटा डिपेंडेंसी एक ही जगह पर इकट्ठा हो जाती हैं. Bazel के आउटपुट ट्री में, इस "रनफ़ाइल" ट्री को आम तौर पर उससे जुड़े बाइनरी या टेस्ट के सिबलिंग के तौर पर रूट किया जाता है.
टेस्ट करने के दौरान, रनफ़ाइल को $TEST_SRCDIR/workspace/packagename/filename
फ़ॉर्म के पाथ का इस्तेमाल करके ऐक्सेस किया जा सकता है.
रनफ़ाइल ट्री यह पक्का करता है कि टेस्ट के पास उन सभी फ़ाइलों का ऐक्सेस हो
जिन पर वे निर्भरता का एलान करते हैं और कुछ नहीं. डिफ़ॉल्ट रूप से, रनफ़ाइल ट्री लागू करने के लिए ज़रूरी फ़ाइलों के लिए सिंबॉलिक लिंक का सेट बनाया जाता है. जैसे-जैसे लिंक का सेट बढ़ता है,
इस तरह की कार्रवाई की लागत भी बढ़ती है. कुछ बड़े बिल्ड के लिए यह
बिल्डिंग के कुल समय में अहम योगदान दे सकता है.
ऐसा खास तौर पर इसलिए होता है, क्योंकि हर जांच (या ऐप्लिकेशन) के लिए अपने रनफ़ाइल ट्री की ज़रूरत होती है.
--[no]build_runfile_manifests
यह विकल्प डिफ़ॉल्ट रूप से चालू होता है. इससे पता चलता है कि रनफ़ाइल मेनिफ़ेस्ट को आउटपुट ट्री में लिखा जाना चाहिए या नहीं.
इसे बंद करने का मतलब है कि --nobuild_runfile_links
.
रिमोट तरीके से टेस्ट एक्ज़ीक्यूट करते समय, इसे बंद किया जा सकता है, क्योंकि रनफ़ाइल ट्री, इन-मेमोरी मेनिफ़ेस्ट की मदद से रिमोट तरीके से बनाए जाएंगे.
--[no]discard_analysis_cache
इस विकल्प के चालू होने पर, Bazel, स्क्रिप्ट रन करने से ठीक पहले, विश्लेषण वाली कैश मेमोरी को मिटा देगा इससे एक्ज़ीक्यूशन फ़ेज़ के लिए करीब 10% ज़्यादा मेमोरी खाली हो जाती है. इसकी कमी यह है कि इसके बढ़ने की रफ़्तार धीमी होगी. मेमोरी बचाने वाला मोड भी देखें.
--[no]keep_going
(-k)
GNU मेक की तरह ही, पहली गड़बड़ी का सामना होने पर बिल्ड का एक्ज़ीक्यूट होना रुक जाता है. कभी-कभी, गड़बड़ियों का सामना करने के बाद भी जितना हो सके उतना बड़ा बनाने से मदद मिलती है. इस विकल्प से वह व्यवहार चालू होता है. इसके बारे में बताने पर बिल्ड, हर उस टारगेट को बनाने की कोशिश करेगा जिसकी ज़रूरी शर्तें पूरी कर ली गई थीं. हालांकि, वह गड़बड़ियों को अनदेखा कर देगा.
आम तौर पर, यह विकल्प बिल्ड के चलने वाले फ़ेज़ से जुड़ा होता है, लेकिन यह विश्लेषण के चरण पर भी असर डालता है: अगर बिल्ड कमांड में कई टारगेट तय किए गए हैं, लेकिन उनमें से सिर्फ़ कुछ का ही सही तरीके से विश्लेषण किया जा सकता है, तो बिल्ड एक गड़बड़ी के साथ बंद रहेगा. अगर --keep_going
को तय नहीं किया गया है, तो बिल्ड, एक्ज़ीक्यूशन फ़ेज़ में चला जाएगा. हालांकि, सिर्फ़ उन टारगेट के लिए होगा जिनका सही तरीके से विश्लेषण किया गया हो.
--[no]use_ijars
यह विकल्प, Bazel से java_library
के टारगेट को इकट्ठा करने का तरीका बदल देता है. डिपेंडेंट java_library
टारगेट को कंपाइल करने के लिए,
java_library
के आउटपुट का इस्तेमाल करने के बजाय, Bazel, इंटरफ़ेस जार बनाएगा. इनमें सिर्फ़ गैर-निजी सदस्यों (सार्वजनिक, सुरक्षित, और डिफ़ॉल्ट (पैकेज) ऐक्सेस के तरीकों और फ़ील्ड
के सिग्नेचर होंगे. साथ ही, डिपेंडेंट टारगेट को कंपाइल करने के लिए इंटरफ़ेस जार का इस्तेमाल करेंगे. ऐसा करने से, जब बदलाव सिर्फ़ तरीके की संस्थाओं या क्लास के निजी सदस्यों में किए जाते हैं, तो इन्हें दोबारा कंपाइल नहीं किया जा सकता.
--[no]interface_shared_objects
इस विकल्प से इंटरफ़ेस शेयर किए गए ऑब्जेक्ट चालू किए जाते हैं, जिससे बाइनरी और शेयर की गई अन्य लाइब्रेरी, लागू करने के बजाय किसी शेयर किए गए ऑब्जेक्ट के इंटरफ़ेस पर निर्भर करती हैं. सिर्फ़ लागू करने की प्रोसेस में बदलाव होने पर, Bazel ग़ैर-ज़रूरी बदलाव के साथ शेयर की गई लाइब्रेरी पर निर्भर टारगेट को फिर से बनाने से बच सकता है.
आउटपुट चुनना
इन विकल्पों से यह तय होता है कि क्या बनाना या टेस्ट करना है.
--[no]build
इस विकल्प से बिल्ड का एक्ज़ीक्यूशन फ़ेज़ होती है; यह डिफ़ॉल्ट रूप से चालू रहता है. जब इसे बंद किया जाता है, तो एक्ज़ीक्यूशन फ़ेज़ को छोड़ दिया जाता है और सिर्फ़ पहले दो चरण, लोडिंग और विश्लेषण होते हैं.
यह विकल्प BUILD फ़ाइलों की पुष्टि करने और इनपुट में गड़बड़ियों का पता लगाने के लिए उपयोगी हो सकता है, बिना कुछ बनाए भी.
--[no]build_tests_only
अगर बताया गया है, तो Bazel सिर्फ़ वही कॉन्टेंट बनाएगा जो *_test
और test_suite
के उन नियमों को चलाने के लिए ज़रूरी है जिन्हें उनके साइज़, समय खत्म होने, टैग या भाषा की वजह से फ़िल्टर नहीं किया गया है.
तय किए जाने पर, Bazel कमांड लाइन पर दिए गए अन्य टारगेट को अनदेखा कर देगा.
डिफ़ॉल्ट रूप से, यह विकल्प बंद होता है और Bazel, अनुरोध किए गए सभी कॉन्टेंट बना लेगा. इनमें *_test
और test_suite
नियम शामिल हैं, जो जांच से फ़िल्टर किए गए हैं. यह काम का है, क्योंकि हो सकता है कि bazel test --build_tests_only foo/...
को चलाने से, foo
ट्री में सभी बिल्ड ब्रेकेज का पता न चले.
--[no]check_up_to_date
इस विकल्प से Bazel, बिल्ड परफ़ॉर्म नहीं करता. हालांकि, यह सिर्फ़ यह जांच करता है कि बताए गए सभी टारगेट अप-टू-डेट हैं या नहीं. अगर ऐसा है, तो बिल्ड आम तौर पर पूरी तरह हो जाता है. हालांकि, अगर कोई फ़ाइल पुरानी है, तो बनाने की बजाय एक गड़बड़ी की रिपोर्ट की जाती है और बिल्ड फ़ेल हो जाता है. इस विकल्प से यह पता किया जा सकता है कि किसी बिल्ड को स्रोत में बदलाव (उदाहरण के लिए, पहले से सबमिट की जांच के लिए) के मुकाबले हाल ही में पूरा किया गया है या नहीं. इससे बिल्ड की लागत का शुल्क नहीं लिया जाता.
--check_tests_up_to_date
भी देखें.
--[no]compile_one_dependency
आर्ग्युमेंट फ़ाइलों की एक डिपेंडेंसी कंपाइल करें. यह आईडीई में सोर्स फ़ाइलों की सिंटैक्स जांच करने के लिए उपयोगी है. उदाहरण के लिए, बदलाव/बिल्डिंग/टेस्ट साइकल में गड़बड़ियों का जल्द से जल्द पता लगाने के लिए, सोर्स फ़ाइल पर निर्भर एक टारगेट को फिर से दोबारा बनाना. इस तर्क से, सभी बिना फ़्लैग वाले आर्ग्युमेंट की व्याख्या करने के तरीके पर असर पड़ता है: हर आर्ग्युमेंट, किसी फ़ाइल का टारगेट लेबल या मौजूदा डायरेक्ट्री से मिलता-जुलता कोई सादा फ़ाइल नाम होना चाहिए. साथ ही, हर सोर्स फ़ाइल नाम के आधार पर एक नियम बनाया जाना चाहिए. C++ और Java सोर्स के लिए, एक ही लैंग्वेज स्पेस के नियमों को प्राथमिकता दी जाती है. एक जैसी प्राथमिकता वाले कई नियमों के लिए, बिल्ड फ़ाइल में सबसे पहले दिखने वाले नियम को चुना जाता है. एक ऐसा टारगेट पैटर्न जिसका नाम साफ़ तौर पर दिया गया है, लेकिन सोर्स फ़ाइल का रेफ़रंस नहीं है. इससे गड़बड़ी हो जाती है.
--save_temps
--save_temps
विकल्प की वजह से, कंपाइलर से कुछ समय के लिए मिलने वाले आउटपुट सेव हो जाते हैं. इनमें .s फ़ाइलें (असेंबल कोड), .i (प्रीप्रोसेस की गई C) और .ii (प्रीप्रोसेस की गई C++) फ़ाइलें शामिल हैं. ये आउटपुट, अक्सर डीबग करने में मदद करते हैं. तापमान सिर्फ़ कमांड लाइन में बताए गए टारगेट के सेट के लिए जनरेट किए जाएंगे.
फ़िलहाल, --save_temps
फ़्लैग सिर्फ़ cc_* नियमों के लिए काम करता है.
यह पक्का करने के लिए कि Bazel, दूसरी आउटपुट फ़ाइलों की जगह की जानकारी प्रिंट करे, देखें कि
आपकी --show_result n
सेटिंग ज़रूरत के मुताबिक है या नहीं.
--build_tag_filters=tag[,tag]*
अगर बताया गया है, तो Bazel सिर्फ़ ऐसे टारगेट बनाएगा जिनमें कम से कम एक ज़रूरी टैग मौजूद हो (अगर उनमें से किसी के बारे में बताया गया हो). साथ ही, इसमें बाहर रखा गया कोई टैग शामिल न हो. बिल्ड टैग फ़िल्टर को टैग कीवर्ड की कॉमा-डीलिमिटेड सूची के तौर पर बताया जाता है. वैकल्पिक रूप से, इसके पहले '-' चिह्न होता है, जिसका इस्तेमाल बाहर रखे गए टैग को दिखाने के लिए किया जाता है. ज़रूरी टैग में '+' का निशान पहले से लगा हो सकता है.
टेस्ट चलाते समय, Bazel, टेस्ट टारगेट के लिए --build_tag_filters
को नज़रअंदाज़ कर देता है. ये टेस्ट, इस फ़िल्टर से मैच न होने पर भी बनाए और चलाए जाते हैं. ऐसा न हो, इसके लिए --test_tag_filters
का इस्तेमाल करके या टेस्ट टारगेट को साफ़ तौर पर बाहर रखकर, उन्हें फ़िल्टर करें.
--test_size_filters=size[,size]*
अगर बारे में बताया गया है, तो Bazel सिर्फ़ दिए गए साइज़ वाले टारगेट की जांच करेगा (या अगर --build_tests_only
तय की गई है, तो बिल्ड बनाएगा). टेस्ट साइज़ फ़िल्टर को,
टेस्ट साइज़ की वैल्यू (छोटे, मीडियम, बड़े या बहुत बड़े) की कॉमा से डीलिमिटेड सूची के तौर पर दिखाया जाता है. वैकल्पिक रूप से, इसके पहले '-' चिह्न होता है,
जिसे शामिल न किए गए टेस्ट साइज़ों के लिए इस्तेमाल किया जाता है. उदाहरण के लिए,
% bazel test --test_size_filters=small,medium //foo:all
और
% bazel test --test_size_filters=-large,-enormous //foo:all
//foo के अंदर सिर्फ़ छोटे और मध्यम टेस्ट टेस्ट करेगा.
डिफ़ॉल्ट रूप से, टेस्ट साइज़ को फ़िल्टर करने की सुविधा लागू नहीं होती.
--test_timeout_filters=timeout[,timeout]*
अगर तय किया गया है, तो Bazel सिर्फ़ दिए गए टाइम आउट वाले टारगेट की जांच करेगा (या अगर --build_tests_only
तय किया गया है, तो बिल्ड) भी जांच करेगा. टेस्ट टाइम आउट फ़िल्टर को, अनुमति पा चुके टाइम आउट वैल्यू (छोटी, सामान्य, ज़्यादा लंबी या हमेशा के लिए) की कॉमा से डीलिमिटेड सूची के तौर पर बताया जाता है. वैकल्पिक रूप से, इसके पहले '-' निशान लगाया जाता है, जिसका इस्तेमाल
बाहर रखे गए टेस्ट टाइम आउट को बताने के लिए किया जाता है. उदाहरण के लिए, --test_size_filters
देखें.
डिफ़ॉल्ट रूप से, जांच के लिए टाइम आउट फ़िल्टर करने की सुविधा लागू नहीं होती.
--test_tag_filters=tag[,tag]*
तय किए जाने पर, Bazel सिर्फ़ उन टारगेट की जांच करेगा (या अगर --build_tests_only
बताया गया है, तो बिल्ड) सिर्फ़ ऐसे टारगेट की जांच करेगा जिनमें कम से कम एक ज़रूरी टैग मौजूद हो
(अगर उनमें से किसी के बारे में बताया गया हो). साथ ही, इसमें बाहर रखा गया कोई टैग मौजूद नहीं है. टेस्ट टैग
फ़िल्टर को टैग कीवर्ड की कॉमा-डीलिमिटेड सूची के तौर पर बताया गया है. वैकल्पिक रूप से, इसके पहले '-' चिह्न होता है, जिसका इस्तेमाल बाहर रखे गए टैग को दिखाने के लिए किया जाता है. ज़रूरी टैग में '+' का निशान पहले से लगा हो सकता है.
उदाहरण के लिए,
% bazel test --test_tag_filters=performance,stress,-flaky //myproject:all
उन टारगेट की जांच करेगा जिन्हें performance
या
stress
टैग से टैग किया गया है, लेकिन flaky
टैग से टैग नहीं किया गया है.
डिफ़ॉल्ट रूप से, टेस्ट टैग फ़िल्टर लागू नहीं किया जाता है. ध्यान दें कि इस तरह टेस्ट के size
और local
टैग पर भी फ़िल्टर लगाया जा सकता है.
--test_lang_filters=string[,string]*
टेस्ट के नियम वाली क्लास के नाम का हवाला देते हुए स्ट्रिंग की कॉमा-सेपरेटेड लिस्ट तय करता है. foo_test
रूल क्लास का रेफ़रंस देने के लिए, "foo" स्ट्रिंग का इस्तेमाल करें. Bazel, सिर्फ़ रेफ़र किए गए रूल क्लास के टारगेट की
जांच करेगा (या अगर --build_tests_only
तय की गई है, तो भी बनाया जाएगा). इसके बजाय, उन टारगेट को बाहर रखने के लिए,
"-foo" स्ट्रिंग का इस्तेमाल करें. उदाहरण के लिए,
% bazel test --test_lang_filters=foo,bar //baz/...
//baz/...
में सिर्फ़ ऐसे टारगेट टेस्ट करेगा जो
foo_test
या bar_test
के इंस्टेंस हैं
% bazel test --test_lang_filters=-foo,-bar //baz/...
foo_test
और
bar_test
इंस्टेंस को छोड़कर, //baz/...
में सभी टारगेट की जांच की जाएगी.
--test_filter=filter-expression
इस नीति से ऐसे फ़िल्टर के बारे में पता चलता है जिसका इस्तेमाल टेस्ट रनर, दौड़ने के लिए टेस्ट का सबसेट चुनने के लिए कर सकता है. शुरू करने की प्रक्रिया में बताए गए सभी टारगेट बनाए जाते हैं, लेकिन एक्सप्रेशन के आधार पर उनमें से सिर्फ़ कुछ को ही चलाया जाता है. कुछ मामलों में, सिर्फ़ टेस्ट के कुछ तरीके ही चलाए जाते हैं.
filter-expression की खास परिभाषा,
टेस्ट चलाने के लिए ज़िम्मेदार टेस्ट फ़्रेमवर्क पर निर्भर करती है. यह कोई ग्लोब, सबस्ट्रिंग या रेगुलर एक्सप्रेशन
हो सकता है. --test_filter
की मदद से, अलग-अलग --test_arg
फ़िल्टर आर्ग्युमेंट को पास किया जा सकता है. हालांकि, सभी फ़्रेमवर्क इस सुविधा के साथ काम नहीं करते.
कितने शब्दों में जानकारी दी जाए
ये विकल्प, टर्मिनल या दूसरी लॉग फ़ाइलों में, Bazel के आउटपुट की वर्बोसिटी को कंट्रोल करते हैं.
--explain=logfile
इस विकल्प के लिए, फ़ाइल नाम आर्ग्युमेंट की ज़रूरत होती है. इसकी वजह से, bazel build
के एक्ज़ीक्यूशन फ़ेज़ में
डिपेंडेंसी चेकर हर बिल्ड चरण के लिए यह बताता है कि
इसे क्यों चलाया जा रहा है या
यह अप-टू-डेट है. logfile
के लिए एक्सप्लेनेशन लिखा गया है.
अगर आपके काम को अचानक से फिर से बनाया जा रहा है, तो इस विकल्प से समस्या की वजह को समझा जा सकता है. इसे अपने .bazelrc
में जोड़ें, ताकि बाद के सभी बिल्ड के लिए
लॉगिंग होती रहे. इसके बाद, जब आपको कोई एक्ज़ीक्यूटिंग चरण बिना किसी नतीजे के लागू हुआ दिखे, तो
लॉग की जांच करें. इस विकल्प से परफ़ॉर्मेंस पर थोड़ा जुर्माना लग सकता है. इसलिए, ज़रूरत न होने पर इसे हटाएं.
--verbose_explanations
इस विकल्प से, --एक्सप्लेनर विकल्प चालू होने पर, जनरेट हुए एक्सप्लेनेशंस की जानकारी बढ़ जाती है.
खास तौर पर, अगर ज़्यादा शब्दों में जानकारी देने की सुविधा चालू है और आउटपुट फ़ाइल फिर से बनाई जाती है, क्योंकि उसे बनाने के लिए इस्तेमाल किया गया निर्देश बदल गया है, तो एक्सप्लेनेशन फ़ाइल के आउटपुट में नए निर्देश की पूरी जानकारी शामिल होगी (कम से कम ज़्यादातर कमांड के लिए).
इस विकल्प का इस्तेमाल करने से, जनरेट की गई एक्सप्लेनेशन फ़ाइल की लंबाई और --explain
का इस्तेमाल करने से परफ़ॉर्मेंस पर लगने वाला जुर्माना काफ़ी बढ़ सकता है.
अगर --explain
चालू नहीं है, तो
--verbose_explanations
का कोई असर नहीं होता.
--profile=file
इस विकल्प की वजह से, Bazel किसी फ़ाइल में प्रोफ़ाइल बनाने वाला डेटा लिखता है. इस विकल्प की मदद से, फ़ाइल नाम वाला आर्ग्युमेंट इस्तेमाल किया जा सकता है. इसके बाद, bazel analyze-profile
कमांड का इस्तेमाल करके डेटा का विश्लेषण किया जा सकता है या उसे पार्स किया जा सकता है. बिल्ड प्रोफ़ाइल से यह समझने में मदद मिल सकती है कि Bazel का build
निर्देश, कहां अपना समय बिता रहा है.
--[no]show_loading_progress
इस विकल्प से Bazel, पैकेज लोड होने की प्रगति के मैसेज दिखाता है. अगर इसे बंद किया जाता है, तो मैसेज नहीं दिखाए जाएंगे.
--[no]show_progress
इस विकल्प से प्रोग्रेस मैसेज दिखते हैं; यह डिफ़ॉल्ट रूप से चालू रहता है. इस सुविधा के बंद होने पर, प्रोग्रेस मैसेज बंद हो जाते हैं.
--show_progress_rate_limit=n
इस विकल्प से, बैजल में हर n
सेकंड में ज़्यादा से ज़्यादा एक प्रोग्रेस मैसेज दिखता है.
इसमें n एक असली संख्या होती है.
इस विकल्प के लिए डिफ़ॉल्ट वैल्यू 0.02 है. इसका मतलब है कि बैजल, प्रोग्रेस मैसेज को हर 0.02 सेकंड में एक मैसेज पर सीमित कर देगा.
--show_result=n
इस विकल्प से यह कंट्रोल किया जाता है कि bazel build
कमांड के आखिर में नतीजे की जानकारी को प्रिंट किया जाए या नहीं. डिफ़ॉल्ट रूप से, अगर एक बिल्ड टारगेट तय किया गया था, तो Bazel एक मैसेज प्रिंट करता है. इसमें बताया जाता है कि टारगेट अप-टू-डेट हुआ या नहीं. अगर ऐसा है, तो टारगेट की गई आउटपुट फ़ाइलों की सूची. अगर एक से ज़्यादा टारगेट
तय किए गए हैं, तो नतीजे की जानकारी नहीं दिखाई जाती है.
हालांकि, नतीजे की जानकारी एक टारगेट या कुछ टारगेट बनाने के लिए काम की हो सकती है, लेकिन बड़े बिल्ड (जैसे, पूरा टॉप-लेवल प्रोजेक्ट ट्री) के लिए, यह जानकारी परेशान करने वाली हो सकती है और ध्यान भटकाने वाली हो सकती है. इस विकल्प से इसे कंट्रोल किया जा सकता है. --show_result
एक पूर्णांक तर्क लेता है. यह टारगेट की वह ज़्यादा से ज़्यादा संख्या होती है जिसके लिए नतीजे की पूरी जानकारी प्रिंट की जानी चाहिए. डिफ़ॉल्ट रूप से,
वैल्यू 1 होती है. इस थ्रेशोल्ड से ऊपर, अलग-अलग टारगेट के लिए
नतीजे की कोई जानकारी नहीं दिखाई जाती है. इसलिए, शून्य से नतीजे
की जानकारी हमेशा छिपी रहती है और बहुत ज़्यादा वैल्यू की वजह से
नतीजे हमेशा प्रिंट होते रहते हैं.
हो सकता है कि उपयोगकर्ता बीच-बीच में कोई वैल्यू चुनना चाहें, जब वे नियमित तौर पर,
टारगेट का एक छोटा ग्रुप (उदाहरण के लिए, कंपाइल-एडिट-टेस्ट साइकल के दौरान)
और टारगेट के एक बड़े ग्रुप
(उदाहरण के लिए, कोई नया फ़ाइल फ़ोल्डर सेट करते समय या रिग्रेशन टेस्ट चला रहे हों) के बीच
विकल्प चुनना चाहें. पहले वाले मामले में, नतीजे की जानकारी बहुत काम की होती है, जबकि बाद वाले मामले में ऐसा नहीं होता. सभी विकल्पों की तरह, इसे .bazelrc
फ़ाइल की मदद से, किसी और तरीके से बताया जा सकता है.
फ़ाइलों को प्रिंट किया जाता है, ताकि बनाए गए एक्ज़ीक्यूटेबल चलाने के लिए, फ़ाइल नाम को कॉपी करके शेल में चिपकाना आसान हो जाए. हर टारगेट के लिए, "अप-टू-डेट" या "पुष्टि नहीं हो सकी" मैसेज को स्क्रिप्ट से आसानी से पार्स किया जा सकता है. इससे बिल्ड तैयार होता है.
--sandbox_debug
यह विकल्प काम करने के लिए सैंडबॉक्सिंग कार्रवाई का इस्तेमाल करते समय, Bazel डीबग करने से जुड़ी ज़्यादा जानकारी प्रिंट करता है. यह विकल्प सैंडबॉक्स डायरेक्ट्री को भी सुरक्षित रखता है, ताकि चलाने के दौरान कार्रवाइयों को दिखने वाली फ़ाइलों की जांच की जा सके.
--subcommands
(-s
)
इस विकल्प की वजह से, Bazel का एक्ज़ीक्यूशन फ़ेज़, हर कमांड को लागू करने से पहले उस पर पूरी कमांड लाइन प्रिंट कर देता है.
>>>>> # //examples/cpp:hello-world [action 'Linking examples/cpp/hello-world'] (cd /home/johndoe/.cache/bazel/_bazel_johndoe/4c084335afceb392cfbe7c31afee3a9f/bazel && \ exec env - \ /usr/bin/gcc -o bazel-out/local-fastbuild/bin/examples/cpp/hello-world -B/usr/bin/ -Wl,-z,relro,-z,now -no-canonical-prefixes -pass-exit-codes -Wl,-S -Wl,@bazel-out/local_linux-fastbuild/bin/examples/cpp/hello-world-2.params)
जहां संभव हो, कमांड बॉर्न शेल के साथ काम करने वाले सिंटैक्स में प्रिंट किए जाते हैं,
ताकि उन्हें आसानी से कॉपी करके शेल कमांड प्रॉम्प्ट पर चिपकाया जा सके.
(आस-पास के ब्रैकेट दिए गए हैं, ताकि आपके शेल को
cd
और exec
कॉल से बचाया जा सके; उन्हें कॉपी करना न भूलें!)
हालांकि, कुछ निर्देश Bazel में अंदरूनी तौर पर लागू किए जाते हैं, जैसे कि
सिमलिंक ट्री बनाना. इनके लिए, कोई कमांड लाइन नहीं होती.
निर्देश के तर्कों को एक सूची के तौर पर प्रिंट करने के लिए, --subcommands=pretty_print
को पास किया जा सकता है. इससे लंबी कमांड लाइन को ज़्यादा आसानी से पढ़ने लायक बनाने में मदद मिल सकती है.
नीचे --verbose_failures भी देखें.
टूल-फ़्रेंडली फ़ॉर्मैट में, किसी फ़ाइल में सबकमांड लॉग करने के लिए, --execution_log_json_file और --execution_log_binary_file देखें.
--verbose_failures
इस विकल्प की वजह से, Bazel का एक्ज़ीक्यूशन फ़ेज़, पूरे न होने वाले कमांड के लिए पूरी कमांड लाइन प्रिंट कर देता है. फ़ेल हो रहे बिल्ड को डीबग करने के लिए यह बहुत अहम हो सकता है.
काम न करने वाले निर्देशों को बॉर्न शेल के साथ काम करने वाले सिंटैक्स में प्रिंट किया जाता है. यह शेल प्रॉम्प्ट पर कॉपी कर चिपकाने के लिए सही होता है.
फ़ाइल फ़ोल्डर की स्थिति
Bazel से बनी बाइनरी को "स्टैंप" करने के लिए इन विकल्पों का इस्तेमाल करें: अतिरिक्त जानकारी को बाइनरी में एम्बेड करने के लिए, जैसे कि सोर्स कंट्रोल में बदलाव करना या वर्कस्पेस से जुड़ी अन्य जानकारी. इस तरीके का इस्तेमाल stamp
एट्रिब्यूट के साथ काम करने वाले नियमों के साथ किया जा सकता है, जैसे कि genrule
, cc_binary
वगैरह.
--workspace_status_command=program
इस फ़्लैग से, आपको एक बाइनरी फ़ाइल तय करने में मदद मिलती है कि Bazel, हर बिल्ड से पहले चलता है. यह कार्यक्रम, फ़ाइल फ़ोल्डर की स्थिति के बारे में जानकारी दे सकता है, जैसे कि मौजूदा सोर्स कंट्रोल में बदलाव.
फ़्लैग की वैल्यू, नेटिव प्रोग्राम का पाथ होनी चाहिए. Linux/macOS पर, इसे किसी भी तरह से एक्ज़ीक्यूट किया जा सकता है. Windows पर, यह एक नेटिव बाइनरी होनी चाहिए. आम तौर पर, इसमें ".exe", ".bat" या ".cmd" फ़ाइल का इस्तेमाल किया जाता है.
प्रोग्राम को स्टैंडर्ड आउटपुट में शून्य या उससे ज़्यादा कुंजी/वैल्यू पेयर, हर लाइन पर एक एंट्री, फिर शून्य के साथ एग्ज़िट करना चाहिए, नहीं तो बिल्ड काम नहीं करेगा. कुंजी के नाम कुछ भी हो सकते हैं, लेकिन उनमें सिर्फ़ अंग्रेज़ी के बड़े अक्षर और अंडरस्कोर इस्तेमाल किए जा सकते हैं. कुंजी के नाम के बाद का पहला स्पेस, उसे वैल्यू से अलग करता है. वैल्यू, लाइन का बाकी हिस्सा है. इसमें खाली सफ़ेद जगह भी शामिल है. न तो कुंजी और न ही मान एक से ज़्यादा पंक्तियों में हो सकता है. कुंजियों की डुप्लीकेट कॉपी नहीं बनाई जानी चाहिए.
Bazel, कुंजियों को दो बकेट में बांट देता है: "स्टेबल" और "वोलाटाइल". ("स्टेबल" और "वोलाटाइल" नाम थोड़ा मुश्किल लगते हैं, इसलिए उनके बारे में ज़्यादा न सोचें.)
इसके बाद, Bazel, की-वैल्यू पेयर को दो फ़ाइलों में लिखता है:
bazel-out/stable-status.txt
इसमें वे सभी कुंजियां और मान शामिल होते हैं जहां कुंजी का नामSTABLE_
से शुरू होता हैbazel-out/volatile-status.txt
इसमें बाकी कुंजियां और उनकी वैल्यू शामिल होती हैं
कानूनी समझौता:
अगर हो सके, तो "स्टेबल" कुंजियों की वैल्यू बहुत कम ही बदलनी चाहिए. अगर
bazel-out/stable-status.txt
का कॉन्टेंट बदल जाता है, तो Bazel उन कार्रवाइयों को अमान्य कर देता है जो उन पर निर्भर हैं. दूसरे शब्दों में, अगर किसी स्थिर कुंजी की वैल्यू में बदलाव होता है, तो Bazel स्टैंप वाली कार्रवाइयां फिर से चला देगा. इसलिए, स्टेबल स्टेटस में टाइमस्टैंप जैसी चीज़ें नहीं होनी चाहिए, क्योंकि ये हर समय बदलती रहती हैं. साथ ही, इससे Bazel हर बिल्ड के साथ स्टैंप वाली कार्रवाइयों को फिर से चला सकता है.Bazel हमेशा ये स्टेबल बटन देता है:
BUILD_EMBED_LABEL
:--embed_label
की वैल्यूBUILD_HOST
: उस होस्ट मशीन का नाम जिस पर Bazel चल रहा हैBUILD_USER
: उस उपयोगकर्ता का नाम जिसके तौर पर Bazel का इस्तेमाल किया जा रहा है
"वोलाटाइल" कुंजियों की वैल्यू अक्सर बदल सकती हैं. Bazel चाहता है कि वह समय-समय पर बदलता रहे, जैसे कि टाइमस्टैंप पर. साथ ही, वह
bazel-out/volatile-status.txt
फ़ाइल को सही तरीके से अपडेट करता रहेगा. स्टैंप वाली कार्रवाइयों को हर समय फिर से चलाने से बचने के लिए, बज़ल यह दिखाता है कि बार-बार अपडेट होने वाली फ़ाइल में कोई बदलाव नहीं होता. दूसरे शब्दों में, अगर सिर्फ़ वही फ़ाइल है जिसके कॉन्टेंट में बदलाव हुआ है, तो Bazel उन कार्रवाइयों को खारिज नहीं करेगा जो उस पर निर्भर हैं. अगर कार्रवाइयों के दूसरे इनपुट बदल गए हैं, तो Bazel उस कार्रवाई को फिर से करता है. इसके बाद, कार्रवाई को अपडेट किया गया वाेलाटाइल स्टेटस दिखेगा. हालांकि, सिर्फ़ उतार-चढ़ाव वाले स्टेटस के बदलने से, कार्रवाई अमान्य नहीं होगी.Bazel हमेशा नीचे दी गई, बार-बार बदलती रहने वाली कुंजियों का आउटपुट देता है:
BUILD_TIMESTAMP
: Unix Epoch के बाद के सेकंड में बनने का समय (System.currentTimeMillis()
की वैल्यू को हज़ार से भाग देने पर)FORMATTED_DATE
: बिल्ड का समय यूटीसी में फ़ॉर्मैट किया गयाyyyy MMM d HH mm ss EEE
(उदाहरण के लिए, 2023 जून 2023 2 01 44 29 शुक्रवार).
Linux/macOS पर, फ़ाइल फ़ोल्डर की स्थिति को वापस पाने के लिए --workspace_status_command=/bin/true
पास की जा सकती है, क्योंकि true
कुछ नहीं करता है और शून्य के साथ
बाहर निकल जाता है और कोई आउटपुट प्रिंट नहीं करता है. Windows पर, इसी इफ़ेक्ट के लिए MSYS के true.exe
का पाथ पास किया जा सकता है.
अगर किसी वजह से वर्कस्पेस का स्टेटस कमांड काम नहीं करता है, तो यह ज़ीरो से बाहर हो जाता है. ऐसे में, बिल्ड फ़ेल हो जाएगा.
Git का इस्तेमाल करने वाले Linux पर प्रोग्राम का उदाहरण:
#!/bin/bash echo "CURRENT_TIME $(date +%s)" echo "RANDOM_HASH $(cat /proc/sys/kernel/random/uuid)" echo "STABLE_GIT_COMMIT $(git rev-parse HEAD)" echo "STABLE_USER_NAME $USER"
--workspace_status_command
के साथ इस प्रोग्राम के पाथ को पास करें. साथ ही, स्टेबल स्टेटस फ़ाइल में STABLE लाइन और वोलाटाइल स्टेटस फ़ाइल में बाकी लाइनें शामिल होंगी.
--[no]stamp
stamp
नियम एट्रिब्यूट के साथ इस विकल्प से यह कंट्रोल किया जाता है कि बिल्ड की जानकारी को बाइनरी में एम्बेड करना है या नहीं.
stamp
एट्रिब्यूट का इस्तेमाल करके, हर नियम के हिसाब से स्टैंप को अलग से चालू या बंद किया जा सकता है. ज़्यादा जानकारी के लिए, कृपया बिल्ड एन्साइक्लोपीडिया देखें. जब कोई नियम stamp = -1
(*_binary
नियमों के लिए डिफ़ॉल्ट) सेट करता है, तो यह विकल्प तय करता है कि स्टैंपिंग चालू है या नहीं.
Bazel उन बाइनरी पर कभी स्टैंप नहीं करता है जिन्हें कॉन्फ़िगरेशन के लिए बनाया गया हो, चाहे यह विकल्प या stamp
एट्रिब्यूट कुछ भी हो. stamp =
0
(*_test
नियमों के लिए डिफ़ॉल्ट) को सेट करने वाले नियमों के लिए, स्टैंप मिलने की सुविधा बंद होती है, भले ही --[no]stamp
पर ध्यान न दिया जाए. अगर टारगेट की डिपेंडेंसी में कोई बदलाव नहीं हुआ है, तो --stamp
को तय करने से, टारगेट को फिर से बनाना ज़रूरी नहीं होता.
आम तौर पर, --nostamp
को सेट करना परफ़ॉर्मेंस को बेहतर बनाने के लिए ज़रूरी होता है, क्योंकि इससे इनपुट का उतार-चढ़ाव कम होता है और बिल्ड कैश मेमोरी में बढ़ोतरी होती है.
प्लैटफ़ॉर्म
इन विकल्पों का इस्तेमाल उन होस्ट और टारगेट प्लैटफ़ॉर्म को कंट्रोल करने के लिए करें जो बिल्ड के काम करने के तरीके को कॉन्फ़िगर करते हैं. साथ ही, इनका इस्तेमाल यह कंट्रोल करने के लिए करें कि Bazel के नियमों के लिए, कौनसा एक्ज़ीक्यूशन प्लैटफ़ॉर्म और टूलचेन उपलब्ध हैं.
कृपया प्लैटफ़ॉर्म और टूलचेन के बारे में बैकग्राउंड की जानकारी देखें.
--platforms=labels
प्लैटफ़ॉर्म के नियमों के लेबल, जिनमें मौजूदा कमांड के लिए टारगेट प्लैटफ़ॉर्म के बारे में जानकारी दी गई होती है.
--host_platform=label
प्लैटफ़ॉर्म के नियम का लेबल, जो होस्ट सिस्टम की जानकारी देता है.
--extra_execution_platforms=labels
ऐसे प्लैटफ़ॉर्म जो कार्रवाइयां करने के लिए, प्रोग्राम चलाने वाले प्लैटफ़ॉर्म के तौर पर उपलब्ध हैं. प्लैटफ़ॉर्म को सटीक टारगेट या टारगेट पैटर्न के तौर पर बताया जा सकता है. इन प्लैटफ़ॉर्म को WorkSPACE फ़ाइल में register_execution_platforms() की ओर से एलान किए जाने से पहले स्वीकार किया जाएगा. यह विकल्प प्राथमिकता के हिसाब से प्लैटफ़ॉर्म की कॉमा-सेपरेटेड लिस्ट स्वीकार करता है. अगर फ़्लैग एक से ज़्यादा बार पास किया जाता है, तो सबसे हाल के बदलाव.
--extra_toolchains=labels
टूलचेन रिज़ॉल्यूशन के दौरान ध्यान में रखे जाने वाले टूलचेन नियम. टूलचेन को, सटीक टारगेट या टारगेट पैटर्न के तौर पर दिखाया जा सकता है. इन टूलचेन को WORKSPACE फ़ाइल में register_toolchains() से एलान किए जाने से पहले लागू किया जाएगा.
--toolchain_resolution_debug=regex
अगर टूलचेन का टाइप, रेगुलर एक्सप्रेशन से मेल खाता है, तो टूलचेन ढूंढने के दौरान डीबग करने की जानकारी प्रिंट करें. एक से ज़्यादा रेगुलर एक्सप्रेशन को कॉमा लगाकर अलग किया जा सकता है. -
का इस्तेमाल करके, रेगुलर एक्सप्रेशन को हटाया जा सकता है. इससे, टूलचेन मौजूद न होने की वजह से डीबग न हो पाने वाले, Bazel या Starlark के नियमों के डेवलपर को मदद मिल सकती है.
अन्य सूचनाएं
--flag_alias=alias_name=target_path
सुविधा फ़्लैग का इस्तेमाल, Starlark की बिल्ड सेटिंग को छोटे नाम के साथ बाइंड करने के लिए किया जाता है. ज़्यादा जानकारी के लिए, Starlark कॉन्फ़िगरेशन देखें.
--symlink_prefix=string
जनरेट किए गए सुविधा सिमलिंक का प्रीफ़िक्स बदलता है. सिमलिंक प्रीफ़िक्स के लिए डिफ़ॉल्ट वैल्यू bazel-
है. इससे सिमलिंक bazel-bin
, bazel-testlogs
, और
bazel-genfiles
बनेंगे.
अगर किसी वजह से सिंबल वाले लिंक नहीं बनाए जा सकते हैं, तो चेतावनी दी जाती है, लेकिन बिल्ड को अब भी कामयाब माना जाता है. खास तौर पर, इससे आपको रीड-ओनली डायरेक्ट्री बनाने की सुविधा मिलती है या ऐसी डायरेक्ट्री बनाई जा सकती है जिसमें लिखने की अनुमति आपके पास न हो. बिल्ड के खत्म होने पर जानकारी देने वाले मैसेज में प्रिंट किया गया कोई भी पाथ सिर्फ़ तब सिमलिंक-रिलेटिव शॉर्ट फ़ॉर्म का इस्तेमाल करेगा, जब सिमलिंक अनुमानित जगह की जानकारी देते हैं; दूसरे शब्दों में, आप उन पाथ के सही होने पर भरोसा कर सकते हैं, भले ही आप बनाए जा रहे सिमलिंक पर भरोसा न कर सकते हों.
इस विकल्प की कुछ सामान्य वैल्यू:
सिमलिंक बनाना रोकें:
--symlink_prefix=/
की वजह से Bazel,bazel-out
औरbazel-<workspace>
सिमलिंक के साथ कोई भी सिमलिंक नहीं बनाएगा या अपडेट नहीं करेगा. सिमलिंक बनाने की प्रोसेस को पूरी तरह से रोकने के लिए, इस विकल्प का इस्तेमाल करें.ज़रूरी चीज़ों को कम करें:
--symlink_prefix=.bazel/
की वजह से Bazel, छिपी हुई डायरेक्ट्री.bazel
मेंbin
(वगैरह) नाम के सिमलिंक बना देगा.
--platform_suffix=string
कॉन्फ़िगरेशन के छोटे नाम में एक सफ़िक्स जोड़ता है. इसका इस्तेमाल आउटपुट डायरेक्ट्री तय करने के लिए किया जाता है. इस विकल्प को अलग-अलग वैल्यू पर सेट करने से फ़ाइलें अलग-अलग डायरेक्ट्री में डाल दी जाती हैं. उदाहरण के लिए, बिल्ड के लिए कैश हिट रेट को बेहतर बनाने के लिए, ताकि दूसरे आउटपुट फ़ाइलों को कॉपी किया जा सके या आउटपुट फ़ाइलों को तुलना के लिए रखा जा सके.
--default_visibility=(private|public)
बाज़ल के लिए डिफ़ॉल्ट तौर पर दिखने वाले बदलावों की जांच करने के लिए, कुछ समय के लिए फ़्लैग किया गया फ़्लैग. यह सामान्य इस्तेमाल के लिए नहीं है, लेकिन पूरी जानकारी के लिए इसे दस्तावेज़ में पेश किया गया है.
--starlark_cpu_profile=_file_
इस फ़्लैग की वैल्यू फ़ाइल का नाम है. इससे Bazel, सभी Starlark थ्रेड के सीपीयू के इस्तेमाल के बारे में आंकड़े इकट्ठा करता है. साथ ही, नाम वाली फ़ाइल में प्रोफ़ाइल को pprof फ़ॉर्मैट में लिखता है.
इस विकल्प का इस्तेमाल Starlark के उन फ़ंक्शन की पहचान करने में मदद करने के लिए करें जो बहुत ज़्यादा कंप्यूटेशन की वजह से, लोड होने और विश्लेषण करने की प्रक्रिया को धीमा कर देते हैं. उदाहरण के लिए:
$ bazel build --nobuild --starlark_cpu_profile=/tmp/pprof.gz my/project/... $ pprof /tmp/pprof.gz (pprof) top Type: CPU Time: Feb 6, 2020 at 12:06pm (PST) Duration: 5.26s, Total samples = 3.34s (63.55%) Showing nodes accounting for 3.34s, 100% of 3.34s total flat flat% sum% cum cum% 1.86s 55.69% 55.69% 1.86s 55.69% sort_source_files 1.02s 30.54% 86.23% 1.02s 30.54% expand_all_combinations 0.44s 13.17% 99.40% 0.44s 13.17% range 0.02s 0.6% 100% 3.34s 100% sorted 0 0% 100% 1.38s 41.32% my/project/main/BUILD 0 0% 100% 1.96s 58.68% my/project/library.bzl 0 0% 100% 3.34s 100% main
एक ही डेटा के अलग-अलग व्यू के लिए, pprof
निर्देश svg
,
web
, और list
आज़माएं.
रिलीज़ के लिए Bazel का इस्तेमाल करना
सॉफ़्टवेयर इंजीनियर, Bazel का इस्तेमाल डेवलपमेंट साइकल के दौरान करते हैं. वहीं, रिलीज़ इंजीनियर इसे प्रोडक्शन में डिप्लॉयमेंट के लिए बाइनरी तैयार करते समय इस्तेमाल करते हैं. इस सेक्शन में, Bazel का इस्तेमाल करने वाले रिलीज़ इंजीनियर के लिए सलाह की सूची दी गई है.
अहम विकल्प
रिलीज़ बिल्ड के लिए Bazel का इस्तेमाल करते समय, वही समस्याएं आती हैं जो बिल्ड परफ़ॉर्म करने वाली अन्य स्क्रिप्ट के लिए आती हैं. ज़्यादा जानकारी के लिए, स्क्रिप्ट से Bazel को कॉल करें देखें. खास तौर पर, नीचे दिए गए विकल्पों का सुझाव दिया जाता है:
ये विकल्प भी अहम हैं:
--package_path
--symlink_prefix
: एक से ज़्यादा कॉन्फ़िगरेशन के बिल्ड मैनेज करने के लिए, हर बिल्ड को एक अलग आइडेंटिफ़ायर से अलग अलग करना आसान हो सकता है, जैसे कि "64 बिट" बनाम "32 बिट". यह विकल्पbazel-bin
(वगैरह) सिमलिंक को अलग करता है.
टेस्ट करना
बैजल की मदद से टेस्ट बनाने और चलाने के लिए, bazel test
टाइप करने के बाद
टेस्ट टारगेट का नाम लिखें.
डिफ़ॉल्ट रूप से, यह निर्देश सभी तय टारगेट (कमांड लाइन पर बताए गए नॉन-टेस्ट टारगेट भी शामिल हैं) बनाते हैं. साथ ही, ज़रूरी शर्तें पूरी होते ही *_test
और test_suite
टारगेट को टेस्ट करता है. इसका मतलब है कि टेस्ट पूरा होने की प्रोसेस, बिल्डिंग के साथ खत्म हो जाती है. ऐसा करने से आम तौर पर रफ़्तार
काफ़ी बढ़ जाती है.
bazel test
के लिए विकल्प
--cache_test_results=(yes|no|auto)
(-t
)
अगर यह विकल्प 'अपने-आप' (डिफ़ॉल्ट) पर सेट है, तो Bazel दोबारा जांच करेगा, अगर नीचे दी गई कोई भी शर्त लागू होती है:
- Bazel, टेस्ट में हुए बदलावों या उसकी डिपेंडेंसी का पता लगाता है
- टेस्ट को
external
के तौर पर मार्क किया गया है --runs_per_test
के साथ कई टेस्ट रन का अनुरोध किया गया- जांच नहीं हो सकी.
अगर 'नहीं' लिखा है, तो सभी जांच बिना किसी शर्त के लागू की जाएंगी.
अगर 'हां' पर सेट किया जाता है, तो कैश मेमोरी का इस्तेमाल, अपने-आप होने वाले तरीके जैसा ही होगा. हालांकि, इससे जांच में गड़बड़ी को कैश मेमोरी में सेव किया जा सकता है और --runs_per_test
के साथ टेस्ट चलाया जा सकता है.
जिन उपयोगकर्ताओं ने अपनी .bazelrc
फ़ाइल में
इस विकल्प को डिफ़ॉल्ट रूप से चालू किया है उन्हें
किसी खास रन पर डिफ़ॉल्ट को बदलने के लिए छोटा नाम -t
(चालू) या -t-
(बंद)
मिल सकता है.
--check_tests_up_to_date
यह विकल्प, Bazel को जांच नहीं करने, बल्कि सिर्फ़ कैश मेमोरी में सेव किए गए टेस्ट के नतीजों की जांच करने और उसकी शिकायत करने के लिए कहता है. अगर कोई ऐसा टेस्ट है जिसे पहले नहीं बनाया और चलाया गया है या जिसके टेस्ट के नतीजे पुराने हैं (उदाहरण के लिए, सोर्स कोड या बिल्ड के विकल्प बदल गए हैं), तो Bazel एक गड़बड़ी का मैसेज ("टेस्ट का नतीजा अप-टू-डेट नहीं है") दिखाएगा, टेस्ट की स्थिति "कोई स्थिति नहीं" (अगर रंग आउटपुट चालू है, तो लाल रंग में) के तौर पर शून्य कोड दिखाएगा.
यह विकल्प [--check_up_to_date](#check-up-to-date)
व्यवहार की जानकारी देता है.
यह विकल्प, पहले से सबमिट की जाने वाली जांचों के लिए फ़ायदेमंद हो सकता है.
--test_verbose_timeout_warnings
इस विकल्प की मदद से, Bazel को उपयोगकर्ता को साफ़ तौर पर चेतावनी देने के लिए कहा जाता है. ऐसा तब किया जाता है, जब जांच के खत्म होने का समय, टेस्ट के पूरा होने के समय से काफ़ी ज़्यादा हो. टेस्ट के टाइम आउट को इस तरह सेट किया जाना चाहिए कि उसमें कोई गड़बड़ी न हो. हालांकि, जिस टेस्ट में टाइम आउट बहुत ज़्यादा होता है उसे असल में अचानक दिखने वाली समस्याओं को छिपाया जा सकता है.
उदाहरण के लिए, आम तौर पर एक या दो मिनट में एक्ज़ीक्यूट होने वाले टेस्ट के लिए, ETERNAL या लॉन्ग टाइम आउट नहीं होना चाहिए, क्योंकि ये बहुत बड़े होते हैं.
यह विकल्प, टाइम आउट की सही वैल्यू तय करने में उपयोगकर्ताओं की मदद करता है. इसके अलावा, इससे टाइम आउट की मौजूदा वैल्यू की जांच करने में भी मदद मिलती है.
--[no]test_keep_going
डिफ़ॉल्ट रूप से, सभी टेस्ट पूरे होने तक चलाए जाते हैं. अगर यह फ़्लैग बंद कर दिया जाता है,
तो बिल्ड को पास न होने वाले टेस्ट के लिए रद्द कर दिया जाता है. बाद के बिल्ड चरण और
टेस्टिंग को नहीं चलाया जाता और फ़्लाइट में शुरू करने की प्रक्रिया रद्द कर दी जाती है.
--notest_keep_going
और --keep_going
, दोनों का ज़िक्र न करें.
--flaky_test_attempts=attempts
इस विकल्प से पता चलता है कि किसी वजह से जांच
नहीं हो पाने पर, उसे ज़्यादा से ज़्यादा कितनी बार कोशिश करनी चाहिए. कोई टेस्ट शुरू में तो काम नहीं करता, लेकिन
आखिर में सफल हो जाता है. उसे टेस्ट की खास जानकारी में FLAKY
के तौर पर रिपोर्ट किया जाता है. हालांकि, Bazel के एग्ज़िट कोड या पास किए गए टेस्ट की
कुल संख्या की पहचान करने में इसे पास माना जाता है. सभी मान्य कोशिशों के दौरान फ़ेल होने वाली जांचों को फ़ेल माना जाता है.
डिफ़ॉल्ट रूप से (जब यह विकल्प तय न किया गया हो या जब यह डिफ़ॉल्ट पर सेट हो), सामान्य जांच के लिए सिर्फ़ एक बार कोशिश करने की अनुमति होती है. साथ ही, flaky
एट्रिब्यूट सेट वाले जांच के नियमों के लिए, सिर्फ़ एक बार कोशिश करने की अनुमति होती है. जांच करने की ज़्यादा से ज़्यादा सीमा को बदलने के लिए, एक पूरी संख्या (इंटीजर) वैल्यू दी जा सकती है. सिस्टम के गलत इस्तेमाल को रोकने के लिए, Bazel ज़्यादा से ज़्यादा
10 जांच करने की अनुमति देता है.
--runs_per_test=[regex@]number
इस विकल्प से पता चलता है कि हर जांच कितनी बार लागू की जानी चाहिए. सभी टेस्ट एक्ज़ीक्यूशन को अलग-अलग टेस्ट के तौर पर माना जाता है (सभी पर फ़ॉलबैक फ़ंक्शन अलग-अलग लागू होंगे).
काम नहीं कर रहे टारगेट की स्थिति --runs_per_test_detects_flakes
फ़्लैग की वैल्यू पर निर्भर करती है:
- अगर यह पेज मौजूद नहीं है, तो पूरा टेस्ट फ़ेल हो जाता है.
- अगर मौजूद हो और दो बार एक ही शार्ड रिटर्न PASS और फ़ेल से चलता है, तो टेस्ट की स्थिति फ़्लैकी की होगी (जब तक कि दूसरी बार असफल होने की वजह से वह फ़ेल न हो जाए).
अगर एक संख्या बताई गई है, तो सभी टेस्ट कई बार चलेंगे.
इसके अलावा, सिंटैक्स का इस्तेमाल करके रेगुलर एक्सप्रेशन तय किया जा सकता है
regex@number. यह रेगुलर एक्सप्रेशन से मेल खाने वाले टारगेट पर --runs_per_test
के असर को रोकता है (--runs_per_test=^//pizza:.*@4
सभी टेस्ट को //pizza/
से कम बार करता है).
--runs_per_test
के इस फ़ॉर्म को एक से ज़्यादा बार बताया जा सकता है.
--[no]runs_per_test_detects_flakes
अगर यह विकल्प दिया गया है (डिफ़ॉल्ट रूप से ऐसा नहीं है), तो Bazel --runs_per_test
के ज़रिए, अस्थिर टेस्ट शार्ड का पता लगाएगा. अगर एक शार्ड फ़ेल होने के लिए एक या एक से ज़्यादा रन मिलते हैं और एक ही शार्ड पास के लिए एक या एक से ज़्यादा रन, तो फ़्लैग वाला टारगेट फ़्लैकी माना जाएगा. अगर इसकी जानकारी नहीं दी गई, तो टारगेट 'काम नहीं कर रहा' स्टेटस
की जानकारी देगा.
--test_summary=output_style
तय करता है कि जांच के नतीजे की खास जानकारी कैसे दिखाई जाए.
- अगर जांच पूरी नहीं हो पाती है, तो
short
हर जांच के नतीजों को टेस्ट आउटपुट वाली फ़ाइल के नाम के साथ प्रिंट करता है. यह डिफ़ॉल्ट वैल्यू है. terse
की तरह,short
, लेकिन इससे भी छोटी: सिर्फ़ उन टेस्ट के बारे में जानकारी प्रिंट करें जो पास नहीं हुए.detailed
हर जांच के लिए प्रिंट नहीं करता है, बल्कि जांच के लिए इस्तेमाल होने वाले हर मामले को प्रिंट करता है. टेस्ट आउटपुट फ़ाइलों के नाम शामिल नहीं किए जाते.none
, जांच की खास जानकारी प्रिंट नहीं करता.
--test_output=output_style
इससे पता चलता है कि टेस्ट आउटपुट कैसे दिखना चाहिए:
summary
यह खास जानकारी दिखाता है कि हर टेस्ट पास हो गया या फ़ेल हो गया. फ़ेल हुए टेस्ट के लिए आउटपुट लॉग फ़ाइल का नाम भी दिखाता है. जवाब को बिल्ड के आखिर में प्रिंट किया जाएगा (बनाने के दौरान, टेस्ट शुरू, पास या फ़ेल होने पर, उपयोगकर्ता को बस प्रोग्रेस के आसान मैसेज दिखेंगे. यह डिफ़ॉल्ट व्यवहार है.errors
, टेस्ट पूरा होने के तुरंत बाद, पूरे न हो पाने वाले टेस्ट से मिले stdout/stderr आउटपुट को सिर्फ़ stdout में भेजता है. इससे, यह पक्का किया जाता है कि एक साथ होने वाले टेस्ट के आउटपुट आउटपुट को एक-दूसरे के साथ इंटरलीव न किया जाए. ऊपर दिए गए जवाब के आउटपुट के हिसाब से, बिल्ड पर खास जानकारी प्रिंट करता है.all
,errors
की तरह ही है, लेकिन पास होने वाली जांचों सहित सभी टेस्ट के लिए आउटपुट प्रिंट करता है.streamed
, हर टेस्ट से stdout/stderr आउटपुट को रीयल-टाइम में स्ट्रीम करता है.
--java_debug
इस विकल्प की वजह से, JavaScript टेस्ट की Java वर्चुअल मशीन को टेस्ट शुरू करने से पहले,
JDWP का पालन करने वाले डीबगर के कनेक्शन का इंतज़ार करना पड़ता है. इसका मतलब है --test_output=streamed
.
--[no]verbose_test_summary
डिफ़ॉल्ट रूप से यह विकल्प चालू होता है, जिससे जांच में लगने वाले समय और अन्य अतिरिक्त जानकारी (जैसे कि जांच की कोशिश) को जांच की खास जानकारी में प्रिंट किया जाता है. अगर
--noverbose_test_summary
दिया गया है, तो टेस्ट की खास जानकारी में सिर्फ़
टेस्ट का नाम, टेस्ट का स्टेटस, और कैश मेमोरी में सेव किया गया टेस्ट इंंडिकेटर शामिल होगा. साथ ही, जहां तक हो सके, 80 वर्णों के अंदर बने रहने के लिए फ़ॉर्मैट किया जाएगा.
--test_tmpdir=path
यह नीति, स्थानीय तौर पर किए जाने वाले टेस्ट के लिए अस्थायी डायरेक्ट्री तय करती है. हर टेस्ट को इस डायरेक्ट्री के अंदर एक अलग सबडायरेक्ट्री में चलाया जाएगा. इस डायरेक्ट्री को हर bazel test
कमांड की शुरुआत में ही साफ़ किया जाएगा.
डिफ़ॉल्ट रूप से, bazel इस डायरेक्ट्री को Bazel आउटपुट बेस डायरेक्ट्री के नीचे रखता है.
--test_timeout=seconds
या --test_timeout=seconds,seconds,seconds,seconds
सेकंड की तय संख्या का इस्तेमाल करके, सभी जांचों के लिए टाइम आउट वैल्यू को नई टाइम आउट वैल्यू के तौर पर बदल देता है. अगर सिर्फ़ एक वैल्यू दी जाती है, तो उसका इस्तेमाल टेस्ट टाइम आउट की सभी कैटगरी के लिए किया जाएगा.
इसके अलावा, कॉमा लगाकर अलग की गई चार वैल्यू दी जा सकती हैं. इसमें छोटी, मध्यम, लंबी, और हमेशा चलने वाली जांच (इस क्रम में) के लिए अलग-अलग टाइम आउट तय किए जाते हैं. किसी भी टेस्ट साइज़ की वैल्यू, शून्य या नेगेटिव में हो सकती है. इसे दी गई टाइम आउट कैटगरी के लिए डिफ़ॉल्ट टाइम आउट से बदल दिया जाएगा, जैसा कि राइटिंग टेस्ट पेज पर बताया गया है. डिफ़ॉल्ट रूप से, Bazel सभी टेस्ट के लिए, इन टाइम आउट का इस्तेमाल करेगा. इसके लिए, वह टेस्ट के साइज़ से टाइम आउट की सीमा का पता लगाएगा. भले ही, साइज़ पूरी तरह से सेट किया गया हो या साफ़ तौर पर सेट किया गया हो.
जो टेस्ट साफ़ तौर पर टाइम आउट की कैटगरी को अपने साइज़ से अलग बताते हैं उन्हें भी वही वैल्यू मिलेगी जो साइज़ टैग से साफ़ तौर पर सेट की गई हो. इसलिए, 'छोटे' साइज़ वाले किसी टेस्ट में, 'लंबे' टाइम आउट के बारे में बताया जाता है. किसी जांच के लिए, 'लंबे' टाइम आउट की तरह ही असरदार टाइम आउट होगा.
--test_arg=arg
हर जांच की प्रोसेस के लिए, कमांड-लाइन के विकल्प/फ़्लैग/तर्क पास करता है. कई तर्क पास करने के लिए, इस विकल्प का इस्तेमाल एक से ज़्यादा बार किया जा सकता है. उदाहरण के लिए,
--test_arg=--logtostderr --test_arg=--v=3
.
--test_env=variable=_value_
या --test_env=variable
हर टेस्ट के लिए, टेस्ट एनवायरमेंट में इंजेक्ट किए जाने वाले अतिरिक्त वैरिएबल तय करता है. अगर value की जानकारी नहीं दी गई है, तो इसे bazel test
कमांड को शुरू करने के लिए इस्तेमाल किए गए शेल एनवायरमेंट से इनहेरिट किया जाएगा.
System.getenv("var")
(Java), getenv("var")
(C या C++) का इस्तेमाल करके एनवायरमेंट को टेस्ट से ऐक्सेस किया जा सकता है
--run_under=command-prefix
इससे उस प्रीफ़िक्स के बारे में पता चलता है जिसे टेस्ट रनर, टेस्ट कमांड को चलाने से पहले उसके सामने डालता है. command-prefix को बॉर्न शेल टोकन बनाने के नियमों का इस्तेमाल करके शब्दों में बांटा जाता है. इसके बाद, शब्दों की सूची को उस निर्देश के पहले जोड़ा जाता है जो लागू किया जाएगा.
अगर पहला शब्द पूरी तरह क्वालिफ़ाइड लेबल (//
से शुरू होता है) है, तो यह बनाया गया है. इसके बाद लेबल को संबंधित एक्ज़ीक्यूटेबल जगह से बदल दिया जाता है जो कमांड के पहले जोड़ी जाती है और इसे दूसरे शब्दों के साथ लागू किया जाएगा.
कुछ चेतावनियां लागू होती हैं:
- टेस्ट चलाने के लिए इस्तेमाल किया जाने वाला PATH, आपके एनवायरमेंट में मौजूद PATH से अलग हो सकता है. इसलिए, आपको
--run_under
कमांड (command-prefix में पहला शब्द) के लिए, ऐब्सलूट पाथ का इस्तेमाल करना पड़ सकता है. stdin
कनेक्ट नहीं है, इसलिए--run_under
का इस्तेमाल इंटरैक्टिव कमांड के लिए नहीं किया जा सकता.
उदाहरण:
--run_under=/usr/bin/strace --run_under='/usr/bin/strace -c' --run_under=/usr/bin/valgrind --run_under='/usr/bin/valgrind --quiet --num-callers=20'
टेस्ट के विकल्प चुनें
आउटपुट चुनने के विकल्पों के तहत, टेस्ट को साइज़, समय खत्म, टैग या भाषा के हिसाब से फ़िल्टर किया जा सकता है. सुविधा सामान्य नाम वाला फ़िल्टर, खास फ़िल्टर आर्ग्युमेंट को टेस्ट रनर पर फ़ॉरवर्ड कर सकता है.
bazel test
के लिए अन्य विकल्प
सिंटैक्स और बाकी विकल्प,
bazel build
जैसे ही हैं.
एक्ज़ीक्यूटेबल चल रहे हैं
bazel run
कमांड, bazel build
की तरह ही है. हालांकि, इसका इस्तेमाल एक टारगेट बनाने और चलाने के लिए किया जाता है. यह एक सामान्य सेशन है:
% bazel run java/myapp:myapp -- --arg1 --arg2 Welcome to Bazel INFO: Loading package: java/myapp INFO: Loading package: foo/bar INFO: Loading complete. Analyzing... INFO: Found 1 target... ... Target //java/myapp:myapp up-to-date: bazel-bin/java/myapp:myapp INFO: Elapsed time: 0.638s, Critical Path: 0.34s INFO: Running command line: bazel-bin/java/myapp:myapp --arg1 --arg2 Hello there $EXEC_ROOT/java/myapp/myapp --arg1 --arg2
bazel run
की तरह ही, यह बाज़ेल की बनाई गई बाइनरी को सीधे तौर पर शुरू करता है. इसका काम करने का तरीका इस बात पर निर्भर करता है कि शुरू की जाने वाली बाइनरी फ़ाइल कोई टेस्ट है या नहीं.
जब बाइनरी कोई टेस्ट नहीं है, तो मौजूदा वर्क डायरेक्ट्री, बाइनरी का रनफ़ाइल ट्री होगी.
जब बाइनरी कोई टेस्ट होता है, तो मौजूदा डायरेक्टरी ही एक्सपायर रूट होती है. साथ ही, यह कोशिश की जाती है कि पर्यावरण से जुड़े टेस्ट आम तौर पर किए जाते रहें. हालांकि, एम्युलेशन सटीक नहीं होता है और कई शार्ड वाले टेस्ट इस तरह नहीं चलाए जा सकते (इसे ठीक करने के लिए --test_sharding_strategy=disabled
कमांड लाइन विकल्प का इस्तेमाल किया जा सकता है)
नीचे दिए गए एनवायरमेंट वैरिएबल, बाइनरी के लिए भी उपलब्ध हैं:
BUILD_WORKSPACE_DIRECTORY
: उस फ़ाइल फ़ोल्डर का रूट जहां बिल्ड चलाया गया था.BUILD_WORKING_DIRECTORY
: वह मौजूदा डायरेक्ट्री जहां से Bazel को चलाया गया था.
उदाहरण के लिए, इनका इस्तेमाल करके, कमांड लाइन पर मौजूद फ़ाइल के नामों को उपयोगकर्ता के लिए आसान बनाया जा सकता है.
bazel run
के लिए विकल्प
--run_under=command-prefix
इसका असर
bazel test
(ऊपर देखें) के लिए --run_under
विकल्प की तरह ही होता है. हालांकि, यह bazel test
की ओर से चलाए जा रहे टेस्ट पर लागू नहीं होता, न कि bazel
run
से चलाए जा रहे निर्देश पर. इसे लेबल के तहत नहीं चलाया जा सकता.
Bazel से मिले लॉग के आउटपुट फ़िल्टर करना
bazel run
के साथ बाइनरी को शुरू करते समय, Bazel खुद से Bazel से मिले आउटपुट और
कॉलिंग में बाइनरी को प्रिंट करता है. लॉग का शोर कम करने के लिए,
--ui_event_filters
और
--noshow_progress
फ़्लैग की मदद से, Bazel के आउटपुट को बंद किया जा सकता है.
उदाहरण के लिए:
bazel run --ui_event_filters=-info,-stdout,-stderr --noshow_progress //java/myapp:myapp
टेस्ट चलाना
bazel run
, टेस्ट बाइनरी भी एक्ज़ीक्यूट कर सकता है. इससे, टेस्ट को
टेस्टिंग में बताए गए एनवायरमेंट की करीबी अनुमानित संख्या के साथ चलाने का असर पड़ता है. ध्यान दें कि इस तरीके से टेस्ट चलाने पर,
--test_arg
के अलावा किसी भी --test_*
आर्ग्युमेंट का असर नहीं होता .
बिल्ड आउटपुट साफ़ करना
clean
निर्देश
Bazel के पास clean
निर्देश है, जो मेक से मिलता-जुलता है.
यह Bazel इंस्टेंस से बनाए गए सभी बिल्ड कॉन्फ़िगरेशन के लिए आउटपुट डायरेक्ट्री मिटाता है या इस Bazel इंस्टेंस से बनाए गए पूरे वर्क ट्री को मिटाता है और अंदरूनी कैश रीसेट करता है. अगर इसे बिना किसी निर्देश-लाइन के
विकल्प के चलाया जाता है, तो सभी कॉन्फ़िगरेशन के लिए आउटपुट डायरेक्ट्री
हटा दी जाएगी.
याद रखें कि हर Bazel इंस्टेंस किसी एक फ़ाइल फ़ोल्डर से जुड़ा होता है. इसलिए,
clean
कमांड, उस फ़ाइल फ़ोल्डर में Bazel इंस्टेंस के लिए बनाए गए सभी बिल्ड के सभी आउटपुट मिटा देगा.
Bazel इंस्टेंस से बनाए गए पूरे वर्क ट्री को पूरी तरह से हटाने के लिए, --expunge
विकल्प चुना जा सकता है. --expunge
के साथ
इस्तेमाल किए जाने पर, क्लीन कमांड सिर्फ़
पूरे आउटपुट बेस ट्री को हटा देती है. इसमें बिल्ड आउटपुट के साथ-साथ, Bazel की बनाई गई सभी अस्थायी फ़ाइलें शामिल होती हैं. सफ़ाई पूरी होने के बाद, यह Bazel सर्वर भी बंद कर देता है. यह shutdown
कमांड की तरह काम करता है. उदाहरण के लिए, किसी Bazel इंस्टेंस की सभी डिस्क और मेमोरी ट्रेस को मिटाने के लिए, आपको यह जानकारी देनी होगी:
% bazel clean --expunge
इसके अलावा, बैकग्राउंड में इसे मिटाने के लिए,
--expunge_async
का इस्तेमाल किया जा सकता है. एसिंक्रोनस पावर के चलते रहने के दौरान, उसी क्लाइंट में Bazel कमांड को शुरू करना सुरक्षित होता है.
clean
निर्देश, मुख्य रूप से उन फ़ाइल फ़ोल्डर के लिए डिस्क स्टोरेज फिर से पाने के लिए दिया जाता है जिनकी अब ज़रूरत नहीं है.
हो सकता है कि Bazel के इंंक्रीमेंटल रीमेक बढ़िया न हों. इसलिए, समस्याओं के आने पर clean
का इस्तेमाल एक जैसा स्टेटस वापस पाने के लिए किया जा सकता है.
Bazel का डिज़ाइन ऐसा है कि इन समस्याओं को ठीक किया जा सकता है और
इन गड़बड़ियों को ठीक करना बेहद ज़रूरी है. अगर आपको कभी भी गलत इंक्रीमेंटल (बढ़ने वाला) बिल्ड मिलता है, तो गड़बड़ी की रिपोर्ट दर्ज करें और clean
का इस्तेमाल करने के बजाय टूल का इस्तेमाल करके गड़बड़ियों की शिकायत करें.
डिपेंडेंसी ग्राफ़ की क्वेरी करना
Bazel में, बिल्ड के दौरान इस्तेमाल किए गए डिपेंडेंसी ग्राफ़ के बारे में सवाल पूछने के लिए, एक क्वेरी लैंग्वेज शामिल है. क्वेरी की भाषा का इस्तेमाल दो कमांड में किया जाता है: query और cquery. इन दोनों कमांड के बीच का बड़ा अंतर यह है कि क्वेरी, लोडिंग फ़ेज़ के बाद चलती है और cquery, विश्लेषण के फ़ेज़ के बाद चलता है. ये टूल, सॉफ़्टवेयर इंजीनियरिंग से जुड़े कई कामों में बहुत मदद करते हैं.
क्वेरी की भाषा, ग्राफ़ के ऊपर बीजगणितीय संचार के विचार पर आधारित है; इसे
Bazel क्वेरी रेफ़रंस. उदाहरण के लिए, और क्वेरी से जुड़े कमांड लाइन विकल्पों के लिए, कृपया वह दस्तावेज़ देखें.
क्वेरी टूल कई कमांड-लाइन
विकल्प स्वीकार करता है. --output
आउटपुट फ़ॉर्मैट चुनता है.
--[no]keep_going
(डिफ़ॉल्ट रूप से बंद होता है) की वजह से क्वेरी टूल, गड़बड़ियों को ठीक करने के तरीके
पर काम करता रहता है. अगर गड़बड़ी की स्थिति में अधूरा नतीजा स्वीकार नहीं किया जाता, तो यह व्यवहार बंद किया जा सकता है.
डिफ़ॉल्ट रूप से चालू होने वाले --[no]tool_deps
विकल्प की वजह से, नॉन-टारगेट कॉन्फ़िगरेशन में डिपेंडेंसी, उस डिपेंडेंसी ग्राफ़ में शामिल होती है जिस पर क्वेरी ऑपरेट की जाती है.
--[no]implicit_deps
विकल्प, डिफ़ॉल्ट रूप से चालू होता है. इससे क्वेरी ऑपरेट करने वाले डिपेंडेंसी ग्राफ़ में इंप्लिसिट डिपेंडेंसी शामिल होती है. इंप्लिसिट डिपेंडेंसी ऐसी है जो BUILD फ़ाइल में साफ़ तौर पर नहीं बताई गई है, लेकिन bazel से जोड़ी गई है.
उदाहरण: "PEBL ट्री में सभी टेस्ट बनाने के लिए ज़रूरी सभी जेनरूल की परिभाषाओं की जगह (BUILD फ़ाइलों में) दिखाएं."
bazel query --output location 'kind(genrule, deps(kind(".*_test rule", foo/bar/pebl/...)))'
ऐक्शन ग्राफ़ की क्वेरी करना
aquery
कमांड की मदद से, बिल्ड ग्राफ़ में कार्रवाइयों के लिए क्वेरी की जा सकती है.
यह विश्लेषण के बाद कॉन्फ़िगर किए गए टारगेट ग्राफ़ पर काम करता है और कार्रवाइयों, आर्टफ़ैक्ट, और उनके संबंधों के बारे में जानकारी दिखाता है.
टूल कई कमांड-लाइन विकल्प स्वीकार करता है.
--output
आउटपुट फ़ॉर्मैट चुनता है. डिफ़ॉल्ट आउटपुट फ़ॉर्मैट
(text
) को लोग पढ़ सकते हैं. मशीन से पढ़ने लायक फ़ॉर्मैट के लिए, proto
या textproto
का इस्तेमाल करें.
खास तौर पर, aquery कमांड, सामान्य Bazel बिल्ड के ऊपर चलती है और बिल्ड के दौरान उपलब्ध विकल्पों के सेट को इनहेरिट करती है.
यह फ़ंक्शन के उन ही सेट के साथ काम करता है जो पारंपरिक
query
के लिए भी उपलब्ध हैं, लेकिन siblings
, buildfiles
, और
tests
.
ज़्यादा जानकारी के लिए, ऐक्शन ग्राफ़ क्वेरी देखें.
अन्य निर्देश और विकल्प
help
help
निर्देश से, ऑन-लाइन मदद मिलती है. डिफ़ॉल्ट रूप से, यह उपलब्ध निर्देशों और सहायता विषयों की खास जानकारी दिखाता है, जैसा कि Bzel के साथ बनाना में दिखाया गया है.
किसी तर्क को तय करने से किसी विशेष विषय के लिए विस्तृत सहायता
दिखती है. ज़्यादातर विषय Bazel के निर्देश होते हैं, जैसे कि build
या query
. हालांकि, मदद के कुछ और विषय भी होते हैं, जो निर्देशों से मेल नहीं खाते.
--[no]long
(-l
)
डिफ़ॉल्ट रूप से, bazel help [topic]
किसी विषय के लिए सिर्फ़ काम के विकल्पों की खास जानकारी प्रिंट करता है. अगर --long
विकल्प के बारे में बताया गया है, तो हर विकल्प का टाइप, डिफ़ॉल्ट वैल्यू, और पूरी जानकारी भी प्रिंट की जाती है.
shutdown
shutdown
कमांड का इस्तेमाल करके, Bazel सर्वर की प्रोसेस रोकी जा सकती हैं. इस निर्देश से Bazel सर्वर, इस्तेमाल में न होने पर बंद हो जाता है. उदाहरण के लिए, किसी बिल्ड या दूसरे निर्देश के पूरा होने के बाद जो अभी काम कर रहा है. ज़्यादा जानकारी के लिए, क्लाइंट/सर्वर लागू करना देखें.
कुछ समय से इस्तेमाल में न होने पर, Bazel सर्वर अपने-आप बंद हो जाते हैं. इसलिए, इस निर्देश की ज़रूरत शायद ही कभी पड़ती है. हालांकि, जब यह पता चलता है कि किसी फ़ाइल फ़ोल्डर में कोई और बिल्ड नहीं होगा, तो यह स्क्रिप्ट में काम आ सकता है.
shutdown
एक विकल्प, --iff_heap_size_greater_than _n_
स्वीकार करता है, जिसके लिए एक पूर्णांक आर्ग्युमेंट (एमबी में) ज़रूरी होता है. अगर बताया गया है, तो यह पहले से इस्तेमाल की गई मेमोरी की मात्रा के हिसाब से शटडाउन कर देता है. यह उन स्क्रिप्ट के लिए काम का होता है जो कई बिल्ड की शुरुआत करती हैं, क्योंकि Bazel सर्वर में किसी भी मेमोरी के लीक होने पर, कभी-कभी यह गलती से बंद हो सकती है. कंडीशनल रीस्टार्ट करने से, यह स्थिति पहले से खत्म हो जाती है.
info
info
कमांड, Bazel सर्वर इंस्टेंस या किसी खास बिल्ड कॉन्फ़िगरेशन से जुड़ी अलग-अलग वैल्यू को प्रिंट करता है.
(इसका इस्तेमाल बिल्ड बढ़ाने वाली स्क्रिप्ट में किया जा सकता है.)
info
निर्देश, सिंगल (ज़रूरी नहीं) आर्ग्युमेंट की भी अनुमति देता है. यह नीचे दी गई सूची में से किसी एक बटन का नाम है.
इस मामले में, bazel info key
सिर्फ़ उस एक कुंजी
की वैल्यू प्रिंट करेगा. (Bzel को स्क्रिप्ट करते समय यह खास तौर पर सुविधाजनक होता है, क्योंकि इससे नतीजे को sed -ne /key:/s/key://p
से पाइप करने की ज़रूरत नहीं पड़ती:
कॉन्फ़िगरेशन-इंडिपेंडेंट डेटा
release
: इस Bazel इंस्टेंस के लिए रिलीज़ लेबल. अगर यह रिलीज़ किया गया बाइनरी नहीं है, तो "डेवलपमेंट वर्शन" का.workspace
बेस वर्कस्पेस डायरेक्ट्री का ऐब्सलूट पाथ है.install_base
: इंस्टॉलेशन डायरेक्ट्री का पूरा पाथ, जिसका इस्तेमाल मौजूदा उपयोगकर्ता के लिए, इस Bazel इंस्टेंस में किया जाता है. Bazel इस डायरेक्ट्री के नीचे, अंदरूनी तौर पर ज़रूरी एक्ज़ीक्यूटेबल इंस्टॉल करता है.output_base
: यह बेस आउटपुट डायरेक्ट्री का ऐब्सलूट पाथ है जिसका इस्तेमाल मौजूदा उपयोगकर्ता और फ़ाइल फ़ोल्डर के कॉम्बिनेशन के लिए, इस Bazel इंस्टेंस में किया जाता है. Bazel अपने सभी स्क्रैच और बिल्ड आउटपुट को इस डायरेक्ट्री के नीचे रखता है.execution_root
: आउटपुट_base के तहत, एक्ज़ीक्यूटेबल रूट डायरेक्ट्री का ऐब्सलूट पाथ. यह डायरेक्ट्री उन सभी फ़ाइलों के लिए रूट है जिन्हें बिल्ड के दौरान एक्ज़ीक्यूट किए गए कमांड से ऐक्सेस किया जा सकता है. साथ ही, यह उन कमांड के लिए काम करने वाली डायरेक्ट्री है. अगर फ़ाइल फ़ोल्डर की डायरेक्ट्री में बदलाव किया जा सकता है, तोbazel-<workspace>
नाम का एक सिमलिंक वहां मौजूद होगा, जो इस डायरेक्ट्री को दिखाता है.output_path
: यह बिल्ड कमांड की वजह से जनरेट हुई सभी फ़ाइलों के लिए इस्तेमाल किए जाने वाले एक्ज़ीक्यूशन रूट के नीचे मौजूद आउटपुट डायरेक्ट्री का ऐब्सलूट पाथ है. अगर वर्कस्पेस की डायरेक्ट्री लिखी जा सकती है, तो उसमेंbazel-out
नाम का सिमलिंक मौजूद होगा, जो इस डायरेक्ट्री की ओर ले जाएगा.server_pid
: Bazel सर्वर प्रोसेस का प्रोसेस आईडी.server_log
: यह Bazel सर्वर के डीबग लॉग फ़ाइल का पूरा पाथ है. इस फ़ाइल में, Bazel सर्वर के अब तक के सभी कमांड के लिए, डीबग करने से जुड़ी जानकारी मौजूद है. यह जानकारी, Bazel डेवलपर और जानकार उपयोगकर्ताओं के लोगों के इस्तेमाल के लिए है.command_log
: कमांड लॉग फ़ाइल का पूरा पाथ; इसमें हाल ही के Bazel कमांड की इंटरलीव्ड stdout और stderr स्ट्रीम शामिल हैं. ध्यान दें किbazel info
चलाने से इस फ़ाइल का कॉन्टेंट, ओवरराइट हो जाएगा. ऐसा होने पर, यह सबसे हाल का Bazel कमांड बन जाएगा. हालांकि, कमांड लॉग फ़ाइल की जगह तब तक नहीं बदलेगी, जब तक कि आप--output_base
या--output_user_root
विकल्पों की सेटिंग नहीं बदलते.used-heap-size
,committed-heap-size
,max-heap-size
: यह अलग-अलग जेवीएम हीप साइज़ पैरामीटर की रिपोर्ट करता है. सही तरीक़े से: फ़िलहाल, इस्तेमाल की जा रही मेमोरी, फ़िलहाल मेमोरी में सिस्टम से जेवीएम को उपलब्ध होने की गारंटी दी जाती है. यह ज़्यादा से ज़्यादा ऐलोकेशन दे सकता है.gc-count
,gc-time
: इस Bazel सर्वर के शुरू होने से लेकर, अब तक ट्रैश इकट्ठा करने की कुल संख्या और इन्हें पूरा करने में लगा समय. ध्यान दें कि ये वैल्यू हर बिल्ड की शुरुआत में रीसेट नहीं की जाती हैं.package_path
: पाथ की कोलन से अलग की गई सूची, जिसे बाज़ल से पैकेज के लिए खोजा जाएगा. इसका फ़ॉर्मैट,--package_path
बिल्ड कमांड लाइन आर्ग्युमेंट जैसा ही है.
उदाहरण: Bazel सर्वर का प्रोसेस आईडी.
% bazel info server_pid 1285
कॉन्फ़िगरेशन के हिसाब से डेटा
इस डेटा पर, bazel info
को दिए गए कॉन्फ़िगरेशन के विकल्पों, जैसे कि --cpu
, --compilation_mode
वगैरह से असर पड़ सकता है. info
कमांड, डिपेंडेंसी के विश्लेषण को कंट्रोल करने वाले सभी विकल्पों को स्वीकार करता है. ऐसा इसलिए होता है, क्योंकि इनमें से कुछ निर्देश किसी बिल्ड की आउटपुट डायरेक्ट्री की जगह, कंपाइलर की पसंद वगैरह को तय करते हैं.
bazel-bin
,bazel-testlogs
,bazel-genfiles
: उनbazel-*
डायरेक्ट्री के ऐब्सलूट पाथ की जानकारी देता है जिनमें बिल्ड से जनरेट किए गए प्रोग्राम मौजूद होते हैं. आम तौर पर, यह संख्या एक जैसी होती है. हालांकि, यह हमेशा एक ही तरह का नहीं होता है. जैसे, किसी बिल्ड के सफल होने के बाद, बेस वर्कस्पेस डायरेक्ट्री में बनाए गएbazel-*
सिमलिंक. हालांकि, अगर वर्कस्पेस डायरेक्ट्री को सिर्फ़ पढ़ा जा सकता है, तोbazel-*
सिमलिंक नहीं बनाए जा सकते. सिमलिंक उपलब्ध होने का अनुमान लगाने के बजाय,bazel info
की रिपोर्ट की गई वैल्यू का इस्तेमाल करने वाली स्क्रिप्ट ज़्यादा बेहतर होंगी.- पूरा "मेक" एनवायरमेंट. अगर
--show_make_env
फ़्लैग बताया गया है, तो मौजूदा कॉन्फ़िगरेशन के "बनाएं" एनवायरमेंट के सभी वैरिएबल भी दिखते हैं (जैसे किCC
,GLIBC_VERSION
वगैरह). ये वे वैरिएबल होते हैं जिन्हें BUILD फ़ाइलों के अंदर$(CC)
याvarref("CC")
सिंटैक्स का इस्तेमाल करके ऐक्सेस किया जाता है.
उदाहरण: मौजूदा कॉन्फ़िगरेशन के लिए C++ कंपाइलर.
यह "बनाएं" एनवायरमेंट में $(CC)
वैरिएबल है,
इसलिए --show_make_env
फ़्लैग की ज़रूरत है.
% bazel info --show_make_env -c opt COMPILATION_MODE opt
उदाहरण: मौजूदा कॉन्फ़िगरेशन के लिए, bazel-bin
आउटपुट डायरेक्ट्री. ऐसे मामलों में भी इसके सही होने की गारंटी दी जाती है,
जब किसी वजह से bazel-bin
सिमलिंक नहीं बनाए जा सकते
(जैसे कि सिर्फ़ रीड-ओनली डायरेक्ट्री से बनाया जा रहा हो).
% bazel info --cpu=piii bazel-bin /var/tmp/_bazel_johndoe/fbd0e8a34f61ce5d491e3da69d959fe6/execroot/io_bazel/bazel-out/piii-opt/bin % bazel info --cpu=k8 bazel-bin /var/tmp/_bazel_johndoe/fbd0e8a34f61ce5d491e3da69d959fe6/execroot/io_bazel/bazel-out/k8-opt/bin
version
और --version
वर्शन कमांड, बैजल बाइनरी के वर्शन की जानकारी प्रिंट करता है. इसमें, वर्शन की जानकारी में बदलाव करने की सूची और उसकी तारीख भी शामिल होती है. इनसे यह पता लगाने में मदद मिलती है कि क्या आपके पास सबसे नया वर्शन है. इसके अलावा, अगर किसी गड़बड़ी की शिकायत की जा रही है, तो इससे मदद भी मिलती है. कुछ दिलचस्प वैल्यू ये हैं:
changelist
: वह बदलाव सूची जिस पर बज़ल का यह वर्शन रिलीज़ किया गया था.label
: इस Bazel इंस्टेंस के लिए रिलीज़ लेबल. अगर यह रिलीज़ किया गया बाइनरी नहीं है, तो "डेवलपमेंट वर्शन" का. बग की शिकायत करने के लिए बहुत उपयोगी होती है.
bazel --version
, जिसमें कोई अन्य आर्ग्युमेंट नहीं है, bazel version --gnu_format
जैसा आउटपुट देगा. हालांकि, Bazel सर्वर को शुरू करने या सर्वर संग्रह को अनपैक करने पर होने वाले खराब असर के अलावा, ऐसा नहीं होगा. bazel --version
को कहीं से भी चलाया जा सकता है - इसके लिए किसी फ़ाइल फ़ोल्डर डायरेक्ट्री की ज़रूरत नहीं होती.
mobile-install
mobile-install
निर्देश, मोबाइल डिवाइसों पर ऐप्लिकेशन इंस्टॉल करता है.
फ़िलहाल, ART पर चलने वाले Android डिवाइस ही यह सुविधा उपलब्ध कराते हैं.
ज़्यादा जानकारी के लिए, bazel मोबाइल-इंस्टॉल देखें.
नीचे दिए गए विकल्प इस्तेमाल किए जा सकते हैं:
--incremental
सेट होने पर, Bazel ऐप्लिकेशन को धीरे-धीरे इंस्टॉल करने की कोशिश करता है. इसका मतलब है कि
सिर्फ़ उन हिस्सों को इंस्टॉल किया गया है जिनमें पिछले बिल्ड के बाद से बदलाव हुए हैं. इससे AndroidManifest.xml
, नेटिव कोड या Java रिसॉर्स (जैसे कि Class.getResource()
में बताए गए संसाधन) से रेफ़र किए गए संसाधनों को अपडेट नहीं किया जा सकता. अगर इनमें बदलाव होता है, तो इस विकल्प को शामिल नहीं करना होगा. Bazel की भावना के उलट, Android प्लैटफ़ॉर्म की सीमाओं की वजह से,
यह जानना उपयोगकर्ता की ज़िम्मेदारी है कि यह निर्देश कब काम का है
और कब पूरी तरह से इंस्टॉल करने की ज़रूरत है.
अगर आप Marshmallow या इसके बाद के किसी डिवाइस का इस्तेमाल कर रहे हैं, तो
--split_apks
फ़्लैग देखें.
--split_apks
डिवाइस पर ऐप्लिकेशन को इंस्टॉल और अपडेट करने के लिए, स्प्लिट APK का इस्तेमाल करना है या नहीं.
यह सुविधा सिर्फ़ उन डिवाइसों पर काम करती है जिनमें Marshmallow या इसके बाद के वर्शन मौजूद हैं. ध्यान दें कि --split_apks
का इस्तेमाल करते समय --incremental
फ़्लैग की ज़रूरत नहीं है.
--start_app
इंस्टॉल होने के बाद, ऐप्लिकेशन साफ़ स्थिति में शुरू होता है. --start=COLD
के बराबर.
--debug_app
इंस्टॉल करने के बाद साफ़ स्थिति में ऐप्लिकेशन को शुरू करने से पहले डीबगर के अटैच होने का इंतज़ार करता है.
--start=DEBUG
के बराबर.
--start=_start_type_
ऐप्लिकेशन को इंस्टॉल करने के बाद उसे कैसे शुरू करना चाहिए. काम करने वाले _start_type_s ये हैं:
NO
ऐप्लिकेशन चालू नहीं करता. यह डिफ़ॉल्ट सेटिंग है.COLD
इंस्टॉल होने के बाद, यह ऐप्लिकेशन को पूरी तरह से चालू करता है.WARM
यह ऐप्लिकेशन इंस्टॉल किए जाने की संख्या बढ़ने पर, ऐप्लिकेशन की स्थिति को सुरक्षित रखता है और उसे पहले जैसा करता है.DEBUG
इंस्टॉल होने के बाद, ऐप्लिकेशन को साफ़ स्थिति में शुरू करने से पहले डीबगर का इंतज़ार करता है.
--adb=path
इस्तेमाल की जाने वाली adb
बाइनरी के बारे में बताता है.
डिफ़ॉल्ट तौर पर,
--android_sdk
के बताए गए Android SDK में adb का इस्तेमाल किया जाता है.
--adb_arg=serial
adb
के लिए अतिरिक्त तर्क. ये कमांड लाइन में मौजूद सबकमांड से पहले आते हैं. आम तौर पर, इनका इस्तेमाल यह तय करने के लिए किया जाता है कि किस डिवाइस पर इंस्टॉल करना है.
उदाहरण के लिए, जिस Android डिवाइस या एम्युलेटर का इस्तेमाल करना है उसे चुनने के लिए:
% bazel mobile-install --adb_arg=-s --adb_arg=deadbeef
adb
को इस तरह शुरू करता है
adb -s deadbeef install ...
--incremental_install_verbosity=number
इंंक्रीमेंटल इंस्टॉल के लिए वर्बोसिटी. डीबग लॉग को कंसोल में प्रिंट करने के लिए, इसे 1 पर सेट करें.
dump
dump
कमांड, Bazel सर्वर की अंदरूनी स्थिति के
डंप को छोटा करने के लिए प्रिंट करता है. यह निर्देश मुख्य रूप से Bazel डेवलपर के इस्तेमाल के लिए है. इसलिए, इस निर्देश का आउटपुट तय नहीं किया गया है और इसमें बदलाव किया जा सकता है.
डिफ़ॉल्ट रूप से, कमांड सिर्फ़ संभावित विकल्पों के बारे में बताने वाला सहायता मैसेज प्रिंट करेगा और Bazel की कुछ जगहों को डंप करेगा. अंदरूनी स्थिति को डंप करने के लिए, कम से कम एक विकल्प तय किया जाना ज़रूरी है.
नीचे दिए गए विकल्पों का इस्तेमाल किया जा सकता है:
--action_cache
, ऐक्शन कैश मेमोरी में मौजूद कॉन्टेंट को डंप करता है.--packages
, पैकेज की कैश मेमोरी में मौजूद कॉन्टेंट को डंप करता है.--skyframe
, Bazel डिपेंडेंसी के अंदरूनी ग्राफ़ की स्थिति को डंप करता है.--rules
हर नियम और आसपेक्ट क्लास के लिए, नियम की खास जानकारी डंप करता है, जिसमें गिनती और कार्रवाई की गिनती शामिल हैं. इसमें नेटिव और स्टारलार्क, दोनों के नियम शामिल हैं. अगर मेमोरी को ट्रैक करने की सुविधा चालू है, तो नियमों की मेमोरी के इस्तेमाल की जानकारी भी प्रिंट हो जाती है.--skylark_memory
, pprof काम करने वाली .gz फ़ाइल को बताए गए पाथ पर डंप करता है. यह काम करे, इसके लिए आपको मेमोरी ट्रैकिंग चालू करनी होगी.
मेमोरी ट्रैकिंग
कुछ dump
निर्देशों के लिए मेमोरी ट्रैकिंग की ज़रूरत होती है. इसे चालू करने के लिए, आपको Bazel को
स्टार्टअप फ़्लैग पास करने होंगे:
--host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar
--host_jvm_args=-DRULE_MEMORY_TRACKER=1
Java-एजेंट को,
third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar
पर Bazel में चेक किया गया है. इसलिए,
$BAZEL
को उस जगह के हिसाब से सेट करें जहां आपको Bazel का डेटा स्टोर करने की जगह रखनी है.
हर निर्देश के लिए, इन विकल्पों को Bazel के पास भेजना न भूलें. ऐसा न करने पर, सर्वर रीस्टार्ट हो जाएगा.
उदाहरण:
% bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar \ --host_jvm_args=-DRULE_MEMORY_TRACKER=1 \ build --nobuild <targets> # Dump rules % bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar \ --host_jvm_args=-DRULE_MEMORY_TRACKER=1 \ dump --rules # Dump Starlark heap and analyze it with pprof % bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar \ --host_jvm_args=-DRULE_MEMORY_TRACKER=1 \ dump --skylark_memory=$HOME/prof.gz % pprof -flame $HOME/prof.gz
analyze-profile
analyze-profile
कमांड, एक ऐसी
JSON ट्रेस प्रोफ़ाइल का विश्लेषण करता है जिसे पहले
बेज़ल को शुरू करने के दौरान इकट्ठा किया गया था.
canonicalize-flags
canonicalize-flags
कमांड, जो Bazel कमांड के विकल्पों की सूची लेता है और
उन विकल्पों की सूची दिखाता है जिनका एक जैसा असर होता है. विकल्पों की नई सूची कैननिकल है. जैसे,
एक जैसे असर वाले विकल्पों की दो सूचियों को एक ही नई सूची में कैननिकल के तौर पर सेट किया जाता है.
अलग-अलग निर्देशों में से किसी एक को चुनने के लिए,
--for_command
विकल्प का इस्तेमाल किया जा सकता है. फ़िलहाल, सिर्फ़ build
और test
का इस्तेमाल
किया जा सकता है. वे विकल्प जिनमें दिया गया निर्देश काम नहीं करता, गड़बड़ी पैदा करते हैं.
उदाहरण के लिए:
% bazel canonicalize-flags -- --config=any_name --test_tag_filters="-lint" --config=any_name --test_tag_filters=-lint
स्टार्टअप के विकल्प
इस सेक्शन में बताए गए विकल्प, Bazel सर्वर प्रोसेस में इस्तेमाल होने वाली Java वर्चुअल मशीन के चालू होने पर असर डालते हैं. साथ ही, ये विकल्प उस सर्वर से मैनेज किए जाने वाले बाद के सभी कमांड पर लागू होते हैं. अगर कोई Bazel सर्वर पहले से चल रहा है और शुरू करने के विकल्प मेल नहीं खाते, तो वह रीस्टार्ट हो जाएगा.
इस सेक्शन में बताए गए सभी विकल्पों को
--key=value
या --key value
सिंटैक्स का इस्तेमाल करके बताया जाना चाहिए. साथ ही, ये विकल्प Bazel कमांड के नाम से पहले दिखने चाहिए. इन्हें .bazelrc
फ़ाइल में शामिल करने के लिए, startup --key=value
का इस्तेमाल करें.
--output_base=dir
इस विकल्प के लिए एक पाथ आर्ग्युमेंट ज़रूरी होता है. साथ ही, ऐसी डायरेक्ट्री तय करनी होती है जिसे लिखा जा सके. Bazel, इस जगह की जानकारी का इस्तेमाल अपने सभी आउटपुट लिखने के लिए करेगा. आउटपुट बेस वह कुंजी भी होती है जिसकी मदद से क्लाइंट, Bazel सर्वर का पता लगाता है. आउटपुट बेस को बदलकर, आप सर्वर बदलते हैं जो कमांड को हैंडल करेगा.
डिफ़ॉल्ट रूप से, आउटपुट बेस उपयोगकर्ता के लॉगिन नाम और वर्कस्पेस डायरेक्ट्री के नाम (असल में इसका MD5 डाइजेस्ट) से लिया जाता है,
इसलिए सामान्य वैल्यू कुछ इस तरह दिखती है:
/var/tmp/google/_bazel_johndoe/d41d8cd98f00b204e9800998ecf8427e
.
उदाहरण के लिए:
OUTPUT_BASE=/var/tmp/google/_bazel_johndoe/custom_output_base % bazel --output_base ${OUTPUT_BASE}1 build //foo & bazel --output_base ${OUTPUT_BASE}2 build //bar
इस निर्देश में, दो Bazel कमांड एक साथ चलते हैं (शेल &
ऑपरेटर की वजह से), और दोनों कमांड में
अलग-अलग Bazel सर्वर इंस्टेंस का इस्तेमाल होता है. ऐसा अलग-अलग आउटपुट बेस की वजह से होता है.
इसके उलट, अगर दोनों कमांड में डिफ़ॉल्ट आउटपुट बेस का इस्तेमाल किया गया था, तो दोनों अनुरोध एक ही सर्वर को भेजे जाएंगे. साथ ही, ये अनुरोध क्रम से भी किए जाएंगे: पहले //foo
बनाना और उसके बाद //bar
का इंक्रीमेंटल (बढ़ने वाला) बिल्ड.
--output_user_root=dir
रूट डायरेक्ट्री पर ले जाता है जहां आउटपुट और इंस्टॉल बेस बनाए जाते हैं. डायरेक्ट्री मौजूद नहीं होनी चाहिए या कॉल करने वाले उपयोगकर्ता के पास उसकी मालिकाना हक होनी चाहिए. पहले, इसे अलग-अलग उपयोगकर्ताओं के बीच शेयर की जाने वाली एक डायरेक्ट्री पर ले जाने की अनुमति थी लेकिन अब इसकी अनुमति नहीं है. समस्या #11100 के हल होने के बाद, इसकी अनुमति दी जा सकती है.
अगर --output_base
विकल्प दिया गया है, तो आउटपुट बेस की गिनती करने के लिए, यह --output_user_root
का इस्तेमाल करता है.
Android SDK के इंस्टॉल की जगह का हिसाब, --output_user_root
और Bazel से एम्बेड की गई बाइनरी की MD5 पहचान
के आधार पर लगाया जाता है.
अगर आपके फ़ाइल सिस्टम के लेआउट में जगह की जानकारी बेहतर है, तो Bazel के सभी आउटपुट (इंस्टॉल बेस और आउटपुट बेस) के लिए, किसी वैकल्पिक बेस जगह को चुनने के लिए --output_user_root
विकल्प का इस्तेमाल किया जा सकता है.
--server_javabase=dir
यह Java वर्चुअल मशीन के बारे में बताता है, जिसमें Bazel खुद चलता है. यह वैल्यू उस डायरेक्ट्री का पाथ होनी चाहिए जिसमें JDK या JRE शामिल हो. यह कोई लेबल नहीं होना चाहिए. यह विकल्प किसी भी Bazel कमांड से पहले दिखना चाहिए, उदाहरण के लिए:
% bazel --server_javabase=/usr/local/buildtools/java/jdk11 build //foo
इस फ़्लैग का असर उन जेवीएम पर नहीं होता है जिन्हें Bazel सबप्रोसेस में इस्तेमाल किया जाता है. जैसे, ऐप्लिकेशन, टेस्ट, टूल वगैरह. इसके बजाय बिल्ड विकल्पों --javabase या --host_javabase का इस्तेमाल करें.
इस फ़्लैग का नाम पहले --host_javabase
था (इसे कभी-कभी 'लेफ़्ट-हैंड साइड' --host_javabase
भी कहा जाता है), लेकिन
बिल्ड फ़्लैग --host_javabase (इसे कभी-कभी 'राइट-हैंड साइड' --host_javabase
भी कहा जाता है) से जुड़ी ग़लतफ़हमी से बचने के लिए, इसका नाम बदल दिया गया है.
--host_jvm_args=string
यह Java वर्चुअल मशीन को पास किए जाने वाले स्टार्टअप विकल्प के बारे में बताती है, जिसमें Bazel खुद चलता है. इसका इस्तेमाल स्टैक साइज़ सेट करने के लिए किया जा सकता है. उदाहरण के लिए:
% bazel --host_jvm_args="-Xss256K" build //foo
इस विकल्प का इस्तेमाल अलग-अलग तर्कों के साथ कई बार किया जा सकता है. ध्यान दें कि इस फ़्लैग को सेट करने की ज़रूरत बहुत कम होती है. आपके पास स्ट्रिंग की स्पेस से अलग की गई सूची को भी पास करने का विकल्प होता है. हर एक आर्ग्युमेंट को अलग JVM आर्ग्युमेंट के तौर पर माना जाएगा. हालांकि, यह सुविधा जल्द ही बंद हो जाएगी.
इसका असर, Bazel के सब-प्रोसेस में इस्तेमाल होने वाले किसी भी JVM पर नहीं पड़ता. जैसे, ऐप्लिकेशन, टेस्ट, टूल वगैरह. जेवीएम के विकल्पों को bazel
run
की मदद से चलाए जाने वाले या कमांड लाइन पर चलाए जा सकने वाले Java प्रोग्राम में पास करने के लिए, आपको --jvm_flags
आर्ग्युमेंट का इस्तेमाल करना होगा जो सभी java_binary
और java_test
प्रोग्राम के साथ काम करता है. जांच के लिए, bazel test --test_arg=--jvm_flags=foo ...
का इस्तेमाल करें.
--host_jvm_debug
इस विकल्प की वजह से Java वर्चुअल मशीन, Bazel के मुख्य तरीके को कॉल करने से पहले JDWP का पालन करने वाले डीबगर से कनेक्शन का इंतज़ार करती है. इसे मुख्य रूप से Bzel डेवलपर के इस्तेमाल के लिए बनाया गया है.
--autodetect_server_javabase
इस विकल्प से Bazel, स्टार्टअप पर इंस्टॉल किया गया JDK अपने-आप खोजता है. साथ ही, एम्बेड किया गया JRE न मिलने पर वह इंस्टॉल किए गए JRE पर वापस चला जाता है.
--explicit_server_javabase
का इस्तेमाल, बैजल को चलाने के लिए कोई खास JRE चुनने के लिए किया जा सकता है.
--batch
बैच मोड, Bazel को स्टैंडर्ड क्लाइंट/सर्वर मोड का इस्तेमाल नहीं करने देता. इसके बजाय, वह एक निर्देश के लिए बेज़ेल JavaScript चलाता है. इसका इस्तेमाल सिग्नल हैंडलिंग, जॉब कंट्रोल, और एनवायरमेंट वैरिएबल इनहेरिटेंस के संबंध में ज़्यादा अनुमान लगाने लायक सिमेंटिक्स के लिए किया जाता है. साथ ही, यह क्रोट जेल में बाज़ार चलाने के लिए ज़रूरी होता है.
बैच मोड, एक ही आउटपुट_base में सही सूची बनाने के सिमेंटिक को बनाए रखता है. इसका मतलब है कि बिना किसी ओवरलैप के, एक साथ शुरू करने की प्रक्रिया को इस क्रम में प्रोसेस किया जाएगा. अगर बैच मोड Bazel को ऐसे क्लाइंट पर चलाया जाता है जिसके सर्वर पर चल रहा है, तो वह कमांड को प्रोसेस करने से पहले, सर्वर को बंद कर देता है.
Bazel, बैच मोड में या ऊपर बताए गए विकल्पों के साथ धीमा चलेगा. ऐसा इसलिए होता है, क्योंकि दूसरी चीज़ों के अलावा, बिल्ड फ़ाइल कैश मेमोरी में सेव होती है. इसलिए, इसे क्रम में चलने वाले बैच के लिए, पुष्टि नहीं की जाती है. इसलिए, बैच मोड का इस्तेमाल करना अक्सर ऐसे मामलों में ज़्यादा कारगर होता है जहां परफ़ॉर्मेंस को कम अहमियत दी जाती है. जैसे, लगातार बिल्ड.
--max_idle_secs=n
इस विकल्प से यह तय होता है कि Bazel सर्वर की प्रोसेस
छोड़ने के लिए, आखिरी क्लाइंट के अनुरोध के बाद कितनी देर तक इंतज़ार करना चाहिए. डिफ़ॉल्ट वैल्यू 10800 (3 घंटे) है. --max_idle_secs=0
की वजह से,
Bazel सर्वर की प्रोसेस लंबे समय तक बनी रहेगी.
इस विकल्प का इस्तेमाल, उन स्क्रिप्ट में किया जा सकता है जो Bazel को शुरू करती हैं. इससे यह पक्का किया जाता है कि अगर वे अलग
अलग तरीके से नहीं चल रहे हैं, तो वे उपयोगकर्ता के मशीन पर Bazel सर्वर की प्रोसेस को
नहीं छोड़ेंगे.
उदाहरण के लिए, हो सकता है कि पहले से सबमिट की गई स्क्रिप्ट bazel query
को शुरू करना चाहे, ताकि यह पक्का किया जा सके कि उपयोगकर्ता के बदलाव को मंज़ूरी मिलने बाकी है. हालांकि, अगर उपयोगकर्ता ने उस फ़ाइल फ़ोल्डर में हाल ही में कोई बिल्ड नहीं बनाया है, तो प्रीसबमिट स्क्रिप्ट के लिए Bazel सर्वर को शुरू करना सही नहीं माना जाएगा.
क्वेरी अनुरोध में --max_idle_secs
की एक छोटी सी वैल्यू तय करके, स्क्रिप्ट यह पक्का कर सकती है कि if इसकी वजह से कोई नया सर्वर चालू हुआ है, तो सर्वर तुरंत बंद हो जाएगा. अगर इसके बजाय, पहले से कोई सर्वर चल रहा है, तो वह तब तक चलता रहेगा, जब तक कि वह आम तौर पर इस्तेमाल नहीं किया जाता. ज़ाहिर है कि मौजूदा सर्वर का
कुछ समय से इस्तेमाल में न होने का टाइमर रीसेट किया जाएगा.
--[no]shutdown_on_low_sys_mem
अगर यह चालू है और --max_idle_secs
किसी पॉज़िटिव अवधि पर सेट है, तो
बिल्ड सर्वर के कुछ समय तक इस्तेमाल न होने पर, सिस्टम की मेमोरी कम होने पर
सर्वर को शट डाउन करें. सिर्फ़ Linux.
max_idle_secs के हिसाब से इस्तेमाल में न होने की जांच करने के अलावा, बिल्ड सर्वर कुछ समय तक सर्वर के इस्तेमाल में न रहने पर, उपलब्ध सिस्टम मेमोरी पर नज़र रखना शुरू कर देगा. अगर उपलब्ध सिस्टम मेमोरी बहुत कम हो जाती है, तो सर्वर बंद हो जाएगा.
--[no]block_for_lock
अगर यह नीति चालू होती है, तो आगे बढ़ने से पहले Bazel, सर्वर लॉक से जुड़े Bazel के अन्य कमांड का इंतज़ार करेगा, ताकि वह पूरा हो सके. अगर बंद हो जाता है, तो अगर Bazel तुरंत लॉक को हासिल नहीं कर पाता और प्रोसेस जारी रहता है, तो वह गलती से बंद हो जाएगा.
डेवलपर इसे पहले से सबमिट की जांच में इस्तेमाल कर सकते हैं, ताकि उसी क्लाइंट में Bazel कमांड की वजह से ज़्यादा इंतज़ार न हो.
--io_nice_level=n
सबसे अच्छी कोशिश वाले IO शेड्यूलिंग के लिए 0 से 7 तक का लेवल सेट करता है. 0 सबसे ऊंची प्राथमिकता है, 7 सबसे कम है. संभावित शेड्यूलर सिर्फ़ प्राथमिकता 4 तक ही काम कर सकता है. नेगेटिव वैल्यू को अनदेखा किया जाता है.
--batch_cpu_scheduling
Bazel के लिए, batch
सीपीयू शेड्यूलिंग का इस्तेमाल करें. यह नीति ऐसे वर्कलोड के लिए फ़ायदेमंद है
जो इंटरैक्टिव नहीं हैं, लेकिन उनकी अच्छी वैल्यू को कम नहीं करना चाहते.
'man 2 sched_setscheduler' देखें. इस नीति से, Bazel थ्रूपुट की लागत पर
सिस्टम में बेहतर तरीके से इंटरैक्ट करने की सुविधा मिल सकती है.
अन्य विकल्प
--[no]announce_rc
यह नीति कंट्रोल करती है कि क्या Bazel, शुरू होने पर bazelrc फ़ाइल से पढ़े गए कमांड के विकल्प की सूचना देता है. (स्टार्टअप विकल्पों की घोषणा बिना किसी शर्त के की जाती है.)
--color (yes|no|auto)
यह विकल्प तय करता है कि Bazel, स्क्रीन पर अपने आउटपुट को हाइलाइट करने के लिए रंगों का इस्तेमाल करेगा या नहीं.
अगर यह विकल्प yes
पर सेट है, तो कलर आउटपुट चालू है.
अगर इस विकल्प को auto
पर सेट किया जाता है, तो Bazel सिर्फ़ तब कलर आउटपुट का इस्तेमाल करेगा, जब
आउटपुट को टर्मिनल पर भेजा जा रहा हो और TERM के एनवायरमेंट वैरिएबल को
dumb
, emacs
या xterm-mono
के अलावा किसी दूसरी वैल्यू पर सेट किया गया हो.
अगर यह विकल्प no
पर सेट किया जाता है, तो कलर आउटपुट बंद है,
भले ही आउटपुट टर्मिनल पर जा रहा हो या नहीं. TERM एनवायरमेंट वैरिएबल की सेटिंग पर ध्यान दिए बिना.
--config=name
rc फ़ाइलों से अतिरिक्त कॉन्फ़िगरेशन सेक्शन चुना जाता है. मौजूदा command
के लिए, अगर ऐसा सेक्शन मौजूद है, तो यह command:name
से भी विकल्प चुनता है. कॉन्फ़िगरेशन के कई सेक्शन से फ़्लैग जोड़ने के लिए, इसे कई बार
बताया जा सकता है. बड़ा करने का मतलब अन्य परिभाषाओं से हो सकता है. उदाहरण के लिए, एक्सपैंशन को चेन किया जा सकता है.
--curses (yes|no|auto)
यह विकल्प तय करता है कि Bazel अपने स्क्रीन आउटपुट में
कर्सर कंट्रोल का इस्तेमाल करेगा या नहीं. इससे, स्क्रोल होने वाला डेटा कम मिलता है. साथ ही, Bazel का आउटपुट
ज़्यादा छोटा और पढ़ने में आसान होता है. यह --color
के साथ बढ़िया काम करता है.
अगर यह विकल्प yes
पर सेट है, तो कर्सर कंट्रोल का इस्तेमाल चालू है.
अगर यह विकल्प no
पर सेट है, तो कर्सर कंट्रोल का इस्तेमाल बंद है.
अगर इस विकल्प को auto
पर सेट किया जाता है, तो कर्सर कंट्रोल का इस्तेमाल --color=auto
की तरह ही चालू हो जाएगा.
--[no]show_timestamps
तय किए जाने पर, बज़ल के जनरेट किए गए हर मैसेज में एक टाइमस्टैंप जोड़ा जाता है. इसमें वह समय बताया जाता है जब मैसेज दिखाया गया था.