Basel के कई विकल्प स्वीकार किए जाते हैं. कुछ विकल्पों में अक्सर बदलाव होता है (उदाहरण के लिए,
--subcommands
), जबकि अन्य विकल्प कई बिल्ड में एक जैसे रहते हैं (जैसे,
--package_path
). हर बिल्ड (और अन्य निर्देशों) के लिए, इन विकल्पों को बताने से बचने के लिए, .bazelrc
नाम की कॉन्फ़िगरेशन फ़ाइल में विकल्पों की जानकारी दी जा सकती है.
.bazelrc
फ़ाइलें कहां हैं?
Bazel, वैकल्पिक कॉन्फ़िगरेशन फ़ाइलों को यहां दी गई जगहों पर ढूंढता है. साथ ही, उन्हें यहां दिए गए क्रम में ढूंढता है. विकल्पों को इस क्रम में समझा जाता है, ताकि किसी विवाद की स्थिति में, बाद की फ़ाइलों के विकल्प, पिछली फ़ाइल की वैल्यू को बदल सकें. इनमें से कौनसी फ़ाइलें लोड होंगी, यह कंट्रोल करने वाले सभी विकल्प, स्टार्टअप विकल्प होते हैं. इसका मतलब है कि ये bazel
के बाद और कमांड (build
, test
वगैरह) से पहले होने चाहिए.
सिस्टम की आरसी फ़ाइल, बशर्ते
--nosystem_rc
मौजूद न हो.पाथ:
- Linux/macOS/Unix पर:
/etc/bazel.bazelrc
- Windows पर:
%ProgramData%\bazel.bazelrc
अगर इस फ़ाइल के मौजूद नहीं हैं, तो यह कोई गड़बड़ी नहीं होगी.
अगर आपको सिस्टम की बताई गई किसी अन्य जगह की ज़रूरत है, तो आपको
//src/main/cpp:option_processor
मेंBAZEL_SYSTEM_BAZELRC_PATH
वैल्यू को बदलकर, कस्टम Bazel बाइनरी बनानी होगी. सिस्टम की तय की गई जगह में, एनवायरमेंट वैरिएबल के रेफ़रंस हो सकते हैं. जैसे, Unix पर${VAR_NAME}
या Windows पर%VAR_NAME%
.- Linux/macOS/Unix पर:
फ़ाइल फ़ोल्डर की आरसी फ़ाइल, बशर्ते
--noworkspace_rc
मौजूद न हो.पाथ: आपकी फ़ाइल फ़ोल्डर डायरेक्ट्री में
.bazelrc
(मुख्यWORKSPACE
फ़ाइल के बगल में).अगर यह फ़ाइल मौजूद नहीं है, तो यह कोई गड़बड़ी नहीं है.
होम आरसी फ़ाइल, जब तक
--nohome_rc
मौजूद न हो.पाथ:
- Linux/macOS/Unixes पर:
$HOME/.bazelrc
- Windows पर:
%USERPROFILE%\.bazelrc
अगर मौजूद है, या%HOME%/.bazelrc
अगर यह फ़ाइल मौजूद नहीं है, तो यह कोई गड़बड़ी नहीं है.
- Linux/macOS/Unixes पर:
उपयोगकर्ता की बताई गई आरसी फ़ाइल, अगर
--bazelrc=file
के साथ बताई गई होयह फ़्लैग वैकल्पिक है, लेकिन इसे एक से ज़्यादा बार भी तय किया जा सकता है.
/dev/null
से पता चलता है कि आगे के सभी--bazelrc
को अनदेखा कर दिया जाएगा. इससे उपयोगकर्ता की आरसी फ़ाइल, जैसे कि रिलीज़ बिल्ड में खोज की सुविधा बंद हो जाती है.उदाहरण के लिए:
--bazelrc=x.rc --bazelrc=y.rc --bazelrc=/dev/null --bazelrc=z.rc
x.rc
औरy.rc
पढ़े जाते हैं.- पहले से मौजूद
/dev/null
की वजह से,z.rc
को अनदेखा किया जाता है.
इस वैकल्पिक कॉन्फ़िगरेशन फ़ाइल के अलावा, Baज़र, ग्लोबल rc फ़ाइल की तलाश में है. ज़्यादा जानकारी के लिए, global bazelrc सेक्शन देखें.
.bazelrc
सिंटैक्स और सिमेंटिक्स
सभी UNIX "rc" फ़ाइलों की तरह, .bazelrc
फ़ाइल भी एक टेक्स्ट फ़ाइल है, जिसमें लाइन पर आधारित व्याकरण का इस्तेमाल किया जाता है. #
(टिप्पणियों) से शुरू होने वाली खाली लाइनों और लाइनों को अनदेखा कर दिया जाता है. हर लाइन में शब्दों का एक क्रम होता है. इन्हें बॉर्न शेल के नियमों के हिसाब से टोकन किया जाता है.
आयात
import
या try-import
से शुरू होने वाली लाइनें खास होती हैं: इनका इस्तेमाल, अन्य "rc" फ़ाइलों को लोड करने के लिए करें. वर्कस्पेस के रूट से जुड़ा पाथ तय करने के लिए, import %workspace%/path/to/bazelrc
लिखें.
import
और try-import
के बीच अंतर यह है कि import
की फ़ाइल मौजूद न होने (या उसे पढ़ा नहीं जा सकता) होने पर Basel काम नहीं करता है. हालांकि, try-import
'ed फ़ाइल के लिए ऐसा नहीं होता है.
इंपोर्ट की प्राथमिकता:
- इंपोर्ट की गई फ़ाइल में मौजूद विकल्प, इंपोर्ट स्टेटमेंट से पहले बताए गए विकल्पों से ज़्यादा प्राथमिकता पाते हैं.
- इंपोर्ट स्टेटमेंट के बाद तय किए गए विकल्पों को, इंपोर्ट की गई फ़ाइल में मौजूद विकल्पों की तुलना में प्राथमिकता दी जाती है.
- बाद में इंपोर्ट की गई फ़ाइलों के विकल्प, पहले इंपोर्ट की गई फ़ाइलों के विकल्पों से ज़्यादा प्राथमिकता पाते हैं.
डिफ़ॉल्ट विकल्प
bazelrc की ज़्यादातर लाइनें, विकल्प की डिफ़ॉल्ट वैल्यू तय करती हैं. हर लाइन का पहला शब्द तय करता है कि ये डिफ़ॉल्ट कब लागू होते हैं:
startup
: स्टार्टअप के विकल्प, जो निर्देश से पहले दिए जाते हैं. इनके बारे मेंbazel help startup_options
में बताया गया है.common
: ऐसे विकल्प जिन्हें उन सभी Bazel निर्देशों पर लागू किया जाना चाहिए जिनमें ये काम करते हैं. अगर कोई कमांड इस तरह से बताए गए विकल्प के साथ काम नहीं करता है, तो विकल्प को तब तक अनदेखा कर दिया जाता है, जब तक कि वह किसी अन्य Bazel कमांड के लिए मान्य है. ध्यान दें कि यह सिर्फ़ विकल्प के नामों पर लागू होता है: अगर मौजूदा निर्देश, तय किए गए नाम वाले विकल्प को स्वीकार करता है, लेकिन तय की गई वैल्यू के साथ काम नहीं करता है, तो वह काम नहीं करेगा.always
: ऐसे विकल्प जो Bazel के सभी निर्देशों पर लागू होते हैं. अगर कोई कमांड इस तरह से बताए गए विकल्प के साथ काम नहीं करता है, तो वह काम नहीं करेगा.command
: Bazel कमांड, जैसे किbuild
याquery
, जिस पर विकल्प लागू होते हैं. ये विकल्प, बताए गए कमांड से इनहेरिट होने वाले सभी कमांड पर भी लागू होते हैं. उदाहरण के लिए,test
,build
से इनहेरिट करता है.
इनमें से हर लाइन का इस्तेमाल एक से ज़्यादा बार किया जा सकता है. साथ ही, पहले शब्द के बाद मौजूद आर्ग्युमेंट को इस तरह जोड़ा जाता है जैसे कि वे एक ही लाइन में मौजूद हों. (सीवीएस के उपयोगकर्ताओं को "स्विस आर्मी चाकू" कमांड-लाइन इंटरफ़ेस वाला एक अन्य टूल मिलेगा. उन्हें .cvsrc
के जैसा ही सिंटैक्स मिलेगा. उदाहरण के लिए, लाइनें:
build --test_tmpdir=/tmp/foo --verbose_failures
build --test_tmpdir=/tmp/bar
इन्हें इस तरह जोड़ा जाता है:
build --test_tmpdir=/tmp/foo --verbose_failures --test_tmpdir=/tmp/bar
इसलिए, सही फ़्लैग --verbose_failures
और --test_tmpdir=/tmp/bar
हैं.
विकल्प की प्राथमिकता:
- कमांड लाइन के विकल्प, आरसी फ़ाइलों के विकल्पों से हमेशा प्राथमिकता पाते हैं.
उदाहरण के लिए, अगर किसी rc फ़ाइल में
build -c opt
है, लेकिन कमांड लाइन फ़्लैग-c dbg
है, तो कमांड लाइन फ़्लैग को प्राथमिकता दी जाती है. rc फ़ाइल में, प्राथमिकता तय करने के लिए यह देखा जाता है कि कमांड कितना सटीक है: ज़्यादा सटीक कमांड की लाइनें, कम सटीक कमांड की लाइनों से ज़्यादा प्राथमिकता पाती हैं.
विशेषता इनहेरिटेंस से तय होती है. कुछ कमांड, दूसरे कमांड से विकल्पों को इनहेरिट करते हैं. इससे, इनहेरिट करने वाला कमांड, मूल कमांड से ज़्यादा खास हो जाता है. उदाहरण के लिए,
test
,build
निर्देश से इनहेरिट करता है. इसलिए, सभीbazel build
फ़्लैगbazel test
के लिए मान्य होते हैं. साथ ही, सभीbuild
लाइनेंbazel test
पर भी लागू होती हैं. ऐसा तब तक होता है, जब तक उसी विकल्प के लिएtest
लाइन मौजूद न हो. अगर rc फ़ाइल में यह जानकारी दिखती है:test -c dbg --test_env=PATH
build -c opt --verbose_failures
तो
bazel build //foo
,-c opt --verbose_failures
का इस्तेमाल करेगा औरbazel test //foo
,--verbose_failures -c dbg --test_env=PATH
का इस्तेमाल करेगा.इनहेरिटेंस (खासियत) ग्राफ़ यह है:
- हर कमांड को
common
से इनहेरिट किया जाता है - ये निर्देश,
build
से इनहेरिट किए जाते हैं और इनमेंbuild
से ज़्यादा जानकारी होती है:test
,run
,clean
,mobile-install
,info
,print_action
,config
,cquery
, औरaquery
coverage
,test
से इनहेरिट करता है
- हर कमांड को
एक ही कमांड के विकल्पों की जानकारी देने वाली दो पंक्तियों को, फ़ाइल में दिखने के क्रम में पार्स किया जाता है.
प्राथमिकता का यह नियम, फ़ाइल के क्रम से मेल नहीं खाता. इसलिए, rc फ़ाइलों में प्राथमिकता के क्रम का पालन करने से, उन्हें पढ़ने में आसानी होती है: सबसे ऊपर
common
विकल्पों से शुरू करें और फ़ाइल के सबसे नीचे सबसे खास निर्देशों के साथ खत्म करें. इस तरह, विकल्पों को पढ़ने का क्रम और लागू करने का क्रम एक ही होता है. यह क्रम, समझने में आसान होता है.
किसी rc फ़ाइल की लाइन में दिए गए आर्ग्युमेंट में, ऐसे आर्ग्युमेंट शामिल हो सकते हैं जो विकल्प नहीं हैं. जैसे, बिल्ड टारगेट के नाम वगैरह. इन फ़ाइलों की तरह, कमांड लाइन पर दिए गए विकल्पों की प्राथमिकता, कमांड लाइन पर मौजूद अपने सिबलिंग की तुलना में कम होती है. साथ ही, इन विकल्पों को गैर-विकल्प आर्ग्युमेंट की खास सूची में हमेशा जोड़ा जाता है.
--config
विकल्पों के डिफ़ॉल्ट तौर पर सेट होने के अलावा, rc फ़ाइल का इस्तेमाल विकल्पों को ग्रुप करने और सामान्य ग्रुपिंग के लिए शॉर्टहैंड देने के लिए किया जा सकता है. ऐसा करने के लिए, निर्देश में :name
सफ़िक्स जोड़कर दिखाया जाता है. इन विकल्पों को डिफ़ॉल्ट रूप से अनदेखा किया जाता है. हालांकि, जब कमांड लाइन या .bazelrc
फ़ाइल में --config=name
विकल्प मौजूद होगा, तब इन्हें शामिल किया जाएगा. ऐसा बार-बार किया जाएगा, भले ही यह किसी दूसरे कॉन्फ़िगरेशन की परिभाषा में हो. command:name
में दिए गए विकल्पों को सिर्फ़ लागू होने वाले निर्देशों के लिए बड़ा किया जाएगा. ऐसा, ऊपर बताए गए प्राथमिकता के क्रम में किया जाएगा.
--config=foo
, rc फ़ाइलों में "जगह पर" तय किए गए विकल्पों में बड़ा हो जाता है, ताकि कॉन्फ़िगरेशन के लिए तय किए गए विकल्पों की प्राथमिकता वही हो जो --config=foo
विकल्प की थी.
यह सिंटैक्स, स्टार्टअप विकल्प सेट करने के लिए startup
के इस्तेमाल पर लागू नहीं होता. .bazelrc में startup:config-name --some_startup_option
को सेट करने पर, उसे अनदेखा कर दिया जाएगा.
उदाहरण
यहां ~/.bazelrc
फ़ाइल का एक उदाहरण दिया गया है:
# Bob's Bazel option defaults
startup --host_jvm_args=-XX:-UseParallelGC
import /home/bobs_project/bazelrc
build --show_timestamps --keep_going --jobs 600
build --color=yes
query --keep_going
# Definition of --config=memcheck
build:memcheck --strip=never --test_timeout=3600
Bazel के काम करने के तरीके को कंट्रोल करने वाली अन्य फ़ाइलें
.bazelignore
Workspace में ऐसी डायरेक्ट्री तय की जा सकती हैं जिनमें Bazel को अनदेखा करना है. जैसे, दूसरे बिल्ड सिस्टम का इस्तेमाल करने वाले मिलते-जुलते प्रोजेक्ट. Workspace के रूट में .bazelignore
नाम की एक फ़ाइल डालें. साथ ही, उन डायरेक्ट्री को जोड़ें जिन्हें आपको Bazel को अनदेखा करने के लिए कहना है. हर डायरेक्ट्री को एक लाइन में जोड़ें. एंट्री, फ़ाइल फ़ोल्डर के रूट से जुड़ी होती हैं.
ग्लोबल bazzrc फ़ाइल
Bazel, वैकल्पिक bazelrc फ़ाइलों को इस क्रम में पढ़ता है:
- सिस्टम की rc-फ़ाइल,
etc/bazel.bazelrc
पर मौजूद है. - Workspace rc-फ़ाइल,
$workspace/tools/bazel.rc
पर मौजूद है. - होम rc-फ़ाइल,
$HOME/.bazelrc
पर मौजूद है
यहां सूची में दी गई हर bagelrc फ़ाइल में एक मिलता-जुलता फ़्लैग होता है, जिसका इस्तेमाल करके उन्हें
बंद किया जा सकता है (जैसे कि --nosystem_rc
, --noworkspace_rc
, --nohome_rc
).
आप --ignore_all_rc_files
स्टार्टअप विकल्प को पास करके, Baselrc को सभी baज़ेनर्क को अनदेखा करने के लिए कह सकते हैं.