Basel के कई विकल्प स्वीकार किए जाते हैं. कुछ विकल्प अक्सर अलग-अलग होते हैं (उदाहरण के लिए,
--subcommands
) जबकि अन्य कई बिल्ड (जैसे कि
--package_path
) में एक जैसे ही रहते हैं. हर बिल्ड (और अन्य निर्देशों) के लिए बिना बदलाव वाले इन विकल्पों की जानकारी देने से बचने के लिए, कॉन्फ़िगरेशन फ़ाइल में .bazelrc
नाम के विकल्प तय किए जा सकते हैं.
.bazelrc
फ़ाइलें कहां हैं?
Basel, नीचे दिए गए क्रम में, वैकल्पिक कॉन्फ़िगरेशन फ़ाइलों को
नीचे दिए गए क्रम में ढूंढती है. विकल्पों की व्याख्या इसी क्रम में की जाती है, ताकि
कोई समस्या होने पर, बाद की फ़ाइलों के विकल्प, पिछली फ़ाइल की वैल्यू को बदल दें. इनमें से किन फ़ाइलों को लोड किया जाए, यह कंट्रोल करने वाले सभी विकल्प, स्टार्टअप विकल्प हैं. इसका मतलब है कि ये bazel
के बाद और
निर्देश (build
, test
वगैरह) से पहले होने चाहिए.
सिस्टम की आरसी फ़ाइल, जब तक
--nosystem_rc
मौजूद न हो.पाथ:
- Linux/macOS/Unixes पर:
/etc/bazel.bazelrc
- Windows पर:
%ProgramData%\bazel.bazelrc
अगर इस फ़ाइल के मौजूद नहीं हैं, तो यह कोई गड़बड़ी नहीं होगी.
अगर सिस्टम से जुड़ी किसी दूसरी जगह की ज़रूरत है, तो आपको
//src/main/cpp:option_processor
मेंBAZEL_SYSTEM_BAZELRC_PATH
वैल्यू को ओवरराइड करते हुए, पसंद के मुताबिक एक बैजल बाइनरी बनाना होगा. सिस्टम की तय की गई जगह में एनवायरमेंट वैरिएबल के रेफ़रंस शामिल हो सकते हैं, जैसे कि Unix पर${VAR_NAME}
या Windows पर%VAR_NAME%
.- Linux/macOS/Unixes पर:
Workspace की आरसी फ़ाइल, जब तक कि
--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
पढ़ी गई हैं.z.rc
को पिछली/dev/null
की वजह से अनदेखा कर दिया गया है.
इस वैकल्पिक कॉन्फ़िगरेशन फ़ाइल के अलावा, Baज़र, ग्लोबल rc फ़ाइल की तलाश में है. ज़्यादा जानकारी के लिए, global bazzrc सेक्शन देखें.
.bazelrc
सिंटैक्स और सिमेंटिक्स
सभी UNIX "rc" फ़ाइलों की तरह, .bazelrc
फ़ाइल भी एक टेक्स्ट फ़ाइल है, जिसमें लाइन पर आधारित व्याकरण का इस्तेमाल किया जाता है. #
(टिप्पणियों) से शुरू होने वाली खाली लाइनों और लाइनों को अनदेखा कर दिया जाता है. हर लाइन में शब्दों का एक क्रम होता है. इन्हें बॉर्न शेल के नियमों के हिसाब से टोकन किया जाता है.
इंपोर्ट
import
या try-import
से शुरू होने वाली लाइनें खास होती हैं: इनका इस्तेमाल अन्य "rc" फ़ाइलों को लोड करने के लिए करें. फ़ाइल फ़ोल्डर के रूट से मिलता-जुलता पाथ तय करने के लिए,
import %workspace%/path/to/bazelrc
लिखें.
import
और try-import
के बीच अंतर यह है कि import
की फ़ाइल मौजूद न होने (या उसे पढ़ा नहीं जा सकता) होने पर Basel काम नहीं करता है. हालांकि, try-import
'ed फ़ाइल के लिए ऐसा नहीं होता है.
इंपोर्ट के लिए प्राथमिकता:
- इंपोर्ट स्टेटमेंट से पहले दिए गए विकल्पों की तुलना में, इंपोर्ट की गई फ़ाइल के विकल्पों को प्राथमिकता दी जाती है.
- इंपोर्ट स्टेटमेंट के बाद तय किए गए विकल्पों को, इंपोर्ट की गई फ़ाइल में मौजूद विकल्पों की तुलना में प्राथमिकता दी जाती है.
- पहले इंपोर्ट की गई फ़ाइलों के मुकाबले, बाद में इंपोर्ट की गई फ़ाइलों के विकल्पों को प्राथमिकता दी जाती है.
विकल्प डिफ़ॉल्ट
baज़लrc की ज़्यादातर लाइनें, डिफ़ॉल्ट विकल्प की वैल्यू को तय करती हैं. हर लाइन का पहला शब्द तय करता है कि ये डिफ़ॉल्ट कब लागू होते हैं:
startup
: स्टार्टअप के विकल्प, जो निर्देश से पहले दिए जाते हैं. इनके बारे मेंbazel help startup_options
में बताया गया है.common
: वे विकल्प जिन्हें Basel के उन सभी कमांड पर लागू किया जाना चाहिए जो इसके साथ काम करते हैं. अगर कोई निर्देश इस तरीके से बताए गए विकल्प के साथ काम नहीं करता है, तो उस विकल्प को तब तक अनदेखा कर दिया जाता है, जब तक कि वह कुछ अन्य Basel कमांड के लिए मान्य हो. ध्यान दें कि यह सिर्फ़ विकल्प के नामों पर लागू होता है: अगर मौजूदा निर्देश, बताए गए नाम वाले विकल्प को स्वीकार करता है, लेकिन बताई गई वैल्यू के साथ काम नहीं करता है, तो वह काम नहीं करेगा.always
: ऐसे विकल्प जो Basel के सभी कमांड पर लागू होते हैं. अगर कोई निर्देश इस तरीके से दिए गए विकल्प के साथ काम नहीं करता है, तो वह काम नहीं करेगा.command
: Basel कमांड, जैसे कि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
से इनहेरिट किए जाते हैं (और इनसे ज़्यादा खास होते हैं):test
,run
,clean
,mobile-install
,info
,print_action
,config
,cquery
, औरaquery
coverage
कोtest
से इनहेरिट किया गया है
- हर निर्देश
एक जैसे कमांड के लिए विकल्पों को तय करने वाली दो लाइनों को उसी क्रम में पार्स किया जाता है जिस क्रम में वे फ़ाइल में दिखती हैं.
प्राथमिकता से जुड़ा यह नियम, फ़ाइल के क्रम से मेल नहीं खाता. इसलिए, अगर आपने rc फ़ाइलों में प्राथमिकता के क्रम का पालन किया है, तो इससे कॉन्टेंट को पढ़ने में आसानी होती है: सबसे ऊपर
common
वाले विकल्प से शुरू करें और फ़ाइल के सबसे नीचे सबसे खास निर्देशों के साथ खत्म करें. इस तरह, विकल्पों को पढ़े जाने का क्रम उन्हें लागू करने के क्रम के समान होता है, जो ज़्यादा आसान होता है.
rc फ़ाइल की लाइन पर दिए गए आर्ग्युमेंट में, ऐसे आर्ग्युमेंट शामिल हो सकते हैं जो विकल्प नहीं हैं. जैसे, बिल्ड टारगेट के नाम वगैरह. एक ही फ़ाइल में दिए गए विकल्पों की तरह, इन विकल्पों की प्राथमिकता, कमांड लाइन पर मौजूद अपने सिबलिंग की तुलना में कम होती है. साथ ही, इन्हें हमेशा बिना विकल्प वाले आर्ग्युमेंट की खास सूची में पहले से जोड़ा जाता है.
--config
विकल्प की डिफ़ॉल्ट सेटिंग के अलावा, rc फ़ाइल का इस्तेमाल विकल्पों को ग्रुप में बांटने और
सामान्य ग्रुप के लिए शॉर्टहैंड की सुविधा देने के लिए किया जा सकता है. ऐसा करने के लिए, निर्देश में :name
सफ़िक्स जोड़कर दिखाया जाता है. इन विकल्पों को डिफ़ॉल्ट रूप से अनदेखा किया जाता है. हालांकि, --config=name
विकल्प मौजूद होने पर इन्हें शामिल किया जाता है. चाहे ये विकल्प कमांड लाइन पर हों या .bazelrc
फ़ाइल में, बार-बार होते हैं. यहां तक कि कॉन्फ़िगरेशन की किसी दूसरी परिभाषा में भी इन्हें शामिल किया जा सकता है. command:name
में दिए गए विकल्पों को सिर्फ़ लागू होने वाले निर्देशों के लिए बड़ा किया जाएगा. ऐसा ऊपर बताए गए प्राथमिकता के क्रम में किया जाएगा.
--config=foo
, "एक जगह पर" रखी गई आरसी फ़ाइलों में बताए गए विकल्पों तक बड़ा हो जाता है, ताकि कॉन्फ़िगरेशन के लिए दिए गए विकल्पों को वही प्राथमिकता दी जाए जो --config=foo
विकल्प की है.
इस सिंटैक्स में स्टार्टअप के विकल्प सेट करने के लिए, startup
का इस्तेमाल नहीं किया जा सकता. .bazzrc में 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
बेज़ल के व्यवहार को कंट्रोल करने वाली अन्य फ़ाइलें
.bazelignore
फ़ाइल फ़ोल्डर में, ऐसी डायरेक्ट्री के बारे में बताया जा सकता है
जिसे आपको बेज़ल से अनदेखा करना है. जैसे,
अन्य बिल्ड सिस्टम का इस्तेमाल करने वाले मिलते-जुलते प्रोजेक्ट. फ़ाइल फ़ोल्डर के रूट में .bazelignore
नाम की फ़ाइल रखें और उन डायरेक्ट्री को जोड़ें जिन्हें आपको Basel को अनदेखा करना है. एक हर लाइन में एक डायरेक्ट्री जोड़ें. एंट्री फ़ाइल फ़ोल्डर के रूट से जुड़ी हैं.
ग्लोबल baezrc फ़ाइल
Baज़र, वैकल्पिक baezrc फ़ाइलों को इस क्रम में पढ़ता है:
- सिस्टम आरसी-फ़ाइल,
etc/bazel.bazelrc
पर मौजूद है. - Workspace rc-फ़ाइल,
$workspace/tools/bazel.rc
पर मौजूद है. - होम आरसी-फ़ाइल,
$HOME/.bazelrc
पर मौजूद है
यहां सूची में दी गई हर baज़ेनrc फ़ाइल में एक मिलता-जुलता फ़्लैग होता है, जिसका इस्तेमाल करके उन्हें
बंद किया जा सकता है (जैसे कि --nosystem_rc
, --noworkspace_rc
, --nohome_rc
).
आप --ignore_all_rc_files
स्टार्टअप विकल्प को पास करके, Bazell को सभी baज़ेनर्क को अनदेखा कर सकते हैं.