Bazel कई विकल्प स्वीकार करता है. कुछ विकल्प अक्सर अलग-अलग होते हैं (उदाहरण के लिए,
--subcommands
), जबकि अन्य विकल्प कई बिल्ड (जैसे
--package_path
) में एक जैसे रहते हैं. हर बिल्ड (और अन्य कमांड) के लिए, बिना बदले गए इन विकल्पों को तय करने से बचने के लिए, कॉन्फ़िगरेशन फ़ाइल में विकल्प तय किए जा सकते हैं, जिसे
.bazelrc
कहते हैं.
.bazelrc
फ़ाइलें कहां हैं?
Bazel नीचे दिए गए क्रम में,
वैकल्पिक कॉन्फ़िगरेशन फ़ाइलें ढूंढता है. विकल्पों की जानकारी इसी क्रम में दी जाती है, इसलिए
अगर कोई विवाद होता है, तो बाद की फ़ाइलों के विकल्प, पिछली फ़ाइल की वैल्यू को बदल सकते हैं. इनमें से लोड की जाने वाली फ़ाइलों को कंट्रोल करने वाले सभी विकल्प,
स्टार्टअप विकल्प हैं. इसका मतलब है कि ये विकल्प 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 पर:
वर्कस्पेस की आरसी फ़ाइल, अगर
--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
को अनदेखा कर दिया गया.
इस वैकल्पिक कॉन्फ़िगरेशन फ़ाइल के अलावा, Bazel एक ग्लोबल आरसी फ़ाइल ढूंढता है. ज़्यादा जानकारी के लिए, global bazelrc सेक्शन देखें.
.bazelrc
सिंटैक्स और सिमैंटिक
सभी UNIX "rc" फ़ाइलों की तरह, .bazelrc
फ़ाइल भी एक टेक्स्ट फ़ाइल होती है, जिसमें लाइन-आधारित व्याकरण होता है. इसमें खाली लाइनों और #
से शुरू होने वाली लाइनों (टिप्पणियां) को अनदेखा किया जाता है. हर लाइन में शब्दों का एक क्रम होता है, जिन्हें बॉर्न शेल वाले नियमों के हिसाब से टोकन दिया जाता है.
इंपोर्ट
import
या try-import
से शुरू होने वाली लाइनें खास होती हैं: इनका इस्तेमाल अन्य "rc" फ़ाइलों को लोड करने के लिए करें. फ़ाइल फ़ोल्डर रूट से मिलता-जुलता पाथ तय करने के लिए import %workspace%/path/to/bazelrc
लिखें.
import
और try-import
के बीच यह अंतर है कि अगर import
वाली फ़ाइल मौजूद नहीं है या उसे पढ़ा नहीं जा सकता, तो Bazel काम नहीं करता. हालांकि, try-import
की फ़ाइल के लिए ऐसा नहीं होता.
इंपोर्ट करने का क्रम:
- इंपोर्ट की गई फ़ाइल के विकल्पों को इंपोर्ट स्टेटमेंट से पहले बताए गए विकल्पों से ज़्यादा अहमियत दी जाती है.
- इंपोर्ट स्टेटमेंट के बाद दिए गए विकल्पों को इंपोर्ट की गई फ़ाइल में मौजूद विकल्पों के मुकाबले ज़्यादा अहमियत दी जाती है.
- पहले इंपोर्ट की गई फ़ाइलों के मुकाबले, बाद में इंपोर्ट की गई फ़ाइलों के विकल्पों को प्राथमिकता दी जाती है.
विकल्प की डिफ़ॉल्ट सेटिंग
bazelrc की ज़्यादातर लाइनें, डिफ़ॉल्ट विकल्प की वैल्यू तय करती हैं. हर लाइन का पहला शब्द बताता है कि ये डिफ़ॉल्ट कब लागू होते हैं:
startup
: शुरू करने के विकल्प, जो निर्देश से पहले दिए जाते हैं. इनके बारे मेंbazel help startup_options
में बताया गया है.common
: ऐसे सभी विकल्प जो इन पर काम करने वाले Bazel कमांड पर लागू होने चाहिए. अगर कोई निर्देश इस तरीके से बताए गए विकल्प के साथ काम नहीं करता, तो विकल्प को तब तक अनदेखा कर दिया जाता है, जब तक कि वह कुछ अन्य Bazel कमांड के लिए मान्य हो. ध्यान दें कि यह सिर्फ़ विकल्प के नामों पर लागू होता है: अगर मौजूदा निर्देश बताए गए नाम वाला विकल्प स्वीकार करता है, लेकिन तय की गई वैल्यू के साथ काम नहीं करता है, तो यह कार्रवाई नहीं की जा सकेगी.always
: वे विकल्प जो सभी Bazel कमांड पर लागू होते हैं. अगर कोई निर्देश इस तरीके से बताए गए विकल्प पर काम नहीं करता, तो वह काम नहीं करेगा.command
: Bazel कमांड, जैसे किbuild
याquery
जिस पर विकल्प लागू होते हैं. ये विकल्प, उन सभी निर्देशों पर भी लागू होते हैं जो किसी खास निर्देश से इनहेरिट किए जाते हैं. (उदाहरण के लिए,test
कोbuild
से इनहेरिट किया जाता है.)
इनमें से हर लाइन को एक से ज़्यादा बार इस्तेमाल किया जा सकता है और पहले शब्द के बाद आने वाले तर्क इस तरह जोड़ दिए जाते हैं जैसे वे एक ही लाइन में दिख रहे हों. ("स्विस आर्मी नाइफ़" कमांड-लाइन इंटरफ़ेस वाला एक अन्य टूल, CVS
के उपयोगकर्ता, .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
असरदार फ़्लैग हैं.
विकल्प की प्राथमिकता:
- आरसी फ़ाइलों में मौजूद कमांड लाइन के विकल्पों के मुकाबले, कमांड लाइन के विकल्पों को हमेशा प्राथमिकता दी जाती है.
उदाहरण के लिए, अगर आरसी फ़ाइल में
build -c opt
लिखा है, लेकिन कमांड लाइन फ़्लैग-c dbg
है, तो कमांड लाइन वाले फ़्लैग को प्राथमिकता दी जाएगी. आरसी फ़ाइल में, प्राथमिकता को प्राथमिकता के हिसाब से तय किया जाता है: ज़्यादा खास निर्देश के लिए लाइनों को कम खास कमांड की लाइनों की तुलना में ज़्यादा प्राथमिकता दी जाती है.
खासियत को इनहेरिटेंस से तय किया जाता है. कुछ कमांड में दूसरे कमांड से विकल्प मिलते हैं, जो इनहेरिटिंग कमांड को बेस कमांड से ज़्यादा सटीक बनाते हैं. उदाहरण के लिए,
test
कोbuild
कमांड से इनहेरिट किया जाता है. इसलिए, सभीbazel build
फ़्लैग,bazel test
के लिए मान्य होते हैं. साथ ही, सभीbuild
लाइनेंbazel test
पर भी लागू होती हैं. ऐसा तब तक होता है, जब तक एक ही विकल्प के लिएtest
लाइन न हो. अगर आरसी फ़ाइल में ऐसा लिखा हो: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
से इनहेरिट किया जाता है
- हर निर्देश
एक जैसे निर्देश के विकल्पों को बराबर अहमियत देने वाली दो लाइनों को उस क्रम में पार्स किया जाता है जिस क्रम में वे फ़ाइल में दिखते हैं.
प्राथमिकता का यह नियम, फ़ाइल के क्रम से मेल नहीं खाता है. इसलिए, अगर आप आरसी फ़ाइलों में प्राथमिकता के क्रम को फ़ॉलो करते हैं, तो इसे पढ़ने में मदद मिलती है: सबसे ऊपर
common
विकल्पों से शुरू करें और फ़ाइल के नीचे दिए गए सबसे खास निर्देशों के साथ खत्म करें. इस तरह से, विकल्पों को उसी क्रम में पढ़ा जाता है जिस क्रम में उन्हें लागू किया जाता है. यह ज़्यादा आसान होता है.
rc फ़ाइल की लाइन में दिए गए आर्ग्युमेंट में, ऐसे आर्ग्युमेंट शामिल हो सकते हैं जो विकल्प नहीं होते. जैसे, बिल्ड टारगेट के नाम वगैरह. इन्हीं फ़ाइलों में बताए गए विकल्पों की तरह ही, इन विकल्पों को कमांड लाइन पर अपने सिबलिंग की तुलना में कम प्राथमिकता दी जाती है. साथ ही, इन्हें विकल्प के तौर पर न दिए जाने वाले तर्कों की साफ़ सूची से पहले जोड़ा जाता है.
--config
विकल्प को डिफ़ॉल्ट सेटिंग के तौर पर सेट करने के साथ-साथ, rc फ़ाइल का इस्तेमाल विकल्पों को ग्रुप
करने और सामान्य ग्रुप के लिए शॉर्टहैंड देने के लिए किया जा सकता है. ऐसा करने के लिए, कमांड में :name
सफ़िक्स जोड़ दिया जाता है. इन विकल्पों को डिफ़ॉल्ट रूप से अनदेखा किया जाता है. हालांकि, --config=name
विकल्प के मौजूद होने पर, इन्हें कमांड लाइन या .bazelrc
फ़ाइल में शामिल कर लिया जाएगा. ऐसा बार-बार किया जाएगा. कॉन्फ़िगरेशन की किसी दूसरी परिभाषा में भी ऐसा किया जा सकता है. command:name
के बताए गए विकल्पों को सिर्फ़ लागू होने वाले निर्देशों के लिए बड़ा किया जाएगा. ऐसा ऊपर बताए गए प्राथमिकता के क्रम में किया जाएगा.
--config=foo
, आरसी फ़ाइलों में बताए गए विकल्पों को "मौजूदा जगह पर" में दिखाता है, ताकि कॉन्फ़िगरेशन के लिए बताए गए विकल्पों को वही प्राथमिकता दी जाए जो --config=foo
विकल्प को मिलती थी.
इस सिंटैक्स में स्टार्टअप के विकल्प सेट करने के लिए, startup
का इस्तेमाल नहीं किया जा सकता. .bazelrc में मौजूद startup:config-name --some_startup_option
सेटिंग को अनदेखा कर दिया जाएगा.
--enable_platform_specific_config
.bazelrc
में प्लैटफ़ॉर्म के हिसाब से कॉन्फ़िगर किए गए कॉन्फ़िगरेशन, --enable_platform_specific_config
का इस्तेमाल करके अपने-आप चालू हो सकते हैं. उदाहरण के लिए, अगर होस्ट ओएस, Linux है और build
कमांड चलाया जाता है, तो build:linux
कॉन्फ़िगरेशन अपने-आप चालू हो जाएगा. linux
, macos
, windows
,
freebsd
, और openbsd
को ओएस आइडेंटिफ़ायर के तौर पर इस्तेमाल किया जा सकता है. इस फ़्लैग को चालू करने का मतलब है कि Linux पर --config=linux
, Windows पर --config=windows
वगैरह का इस्तेमाल किया जाता है.
--enable_platform_specific_config पर जाएं.
उदाहरण
यहां ~/.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
आपके पास फ़ाइल फ़ोल्डर में ऐसी डायरेक्ट्री तय करने का विकल्प होता है जिन्हें Bazel अनदेखा कर दे. जैसे, दूसरे बिल्ड सिस्टम इस्तेमाल करने वाले मिलते-जुलते प्रोजेक्ट. .bazelignore
नाम की फ़ाइल को फ़ाइल फ़ोल्डर के रूट में रखें. साथ ही, उन डायरेक्ट्री को जोड़ें जिन्हें आपको Bazel अनदेखा करना है. एक लाइन में एक फ़ाइल जोड़ें. एंट्री, फ़ाइल फ़ोल्डर के रूट से जुड़ी होती हैं.
ग्लोबल bazelrc फ़ाइल
Bazel इस क्रम में वैकल्पिक bazelrc फ़ाइलों को पढ़ता है:
- सिस्टम आरसी-फ़ाइल
etc/bazel.bazelrc
पर मौजूद है. - Workspace की rc-file,
$workspace/tools/bazel.rc
पर मौजूद है. - होम की आरसी-फ़ाइल,
$HOME/.bazelrc
पर मौजूद है
यहां सूची में दी गई हर bazelrc फ़ाइल से जुड़ा एक फ़्लैग मौजूद है. इसका इस्तेमाल करके उन्हें बंद किया जा सकता है (जैसे कि --nosystem_rc
, --noworkspace_rc
, --nohome_rc
). --ignore_all_rc_files
स्टार्टअप विकल्प पास करके, Bazel को सभी bazelrcs का अनदेखा करने का विकल्प भी दिया जा सकता है.