bazelrc कॉन्फ़िगरेशन फ़ाइलें लिखें

Bazel कई विकल्प स्वीकार करता है. कुछ विकल्प अक्सर अलग-अलग होते हैं (उदाहरण के लिए, --subcommands), जबकि अन्य कई बिल्ड (जैसे कि --package_path) में एक जैसे ही रहते हैं. हर बिल्ड (और दूसरे निर्देशों) के लिए, बदले गए इन विकल्पों को तय करने से बचने के लिए, कॉन्फ़िगरेशन फ़ाइल में विकल्प तय करें .bazelrc.

.bazelrc फ़ाइलें कहां हैं?

Bazel नीचे दिए गए क्रम में, नीचे दी गई जगहों में वैकल्पिक कॉन्फ़िगरेशन फ़ाइलें ढूंढता है. विकल्पों की जानकारी इसी क्रम में दी जाती है, इसलिए विवाद की स्थिति में, बाद की फ़ाइलों के विकल्प, किसी पुरानी फ़ाइल की वैल्यू को बदल सकते हैं. ऐसे सभी विकल्प जो यह कंट्रोल करते हैं कि इनमें से कौनसी फ़ाइलें लोड हों, शुरू करने के विकल्प हैं. इसका मतलब है कि ये विकल्प bazel के बाद और निर्देश (build, test वगैरह) से पहले आने चाहिए.

1. सिस्टम की आरसी फ़ाइल, अगर --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%.

2. फ़ाइल फ़ोल्डर की आरसी फ़ाइल, जब तक कि --noworkspace_rc मौजूद न हो.

   पाथ: आपकी फ़ाइल फ़ोल्डर की डायरेक्ट्री में .bazelrc (मुख्य WORKSPACE फ़ाइल के बगल में).

   अगर यह फ़ाइल मौजूद नहीं है, तो यह कोई गड़बड़ी नहीं है.

3. अगर --nohome_rc मौजूद नहीं है, तो होम की आरसी फ़ाइल.

   पथ:

   • Linux/macOS/Unixes पर: $HOME/.bazelrc
   • Windows पर: अगर मौजूद है, तो %USERPROFILE%\.bazelrc या %HOME%/.bazelrc

   अगर यह फ़ाइल मौजूद नहीं है, तो यह कोई गड़बड़ी नहीं है.

4. उपयोगकर्ता की बताई गई आरसी फ़ाइल, अगर --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 एक ग्लोबल आरसी फ़ाइल ढूंढता है. ज़्यादा जानकारी के लिए, ग्लोबल 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 कमांड पर लागू होते हैं.
• 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 से इनहेरिट किए जाते हैं (और इनसे ज़्यादा खास हैं) build: test, run, clean, mobile-install, info, print_action, config, cquery, और aquery
  • coverage को test से इनहेरिट किया जाता है

• एक ही कमांड के लिए, बराबर विकल्प के विकल्प तय करने वाली दो लाइनें, उस क्रम में पार्स की जाती हैं जिस क्रम में वे फ़ाइल में दिखती हैं.

• प्राथमिकता का यह नियम, फ़ाइल के क्रम से मेल नहीं खाता है. इसलिए, अगर आप आरसी फ़ाइलों में प्राथमिकता के क्रम को फ़ॉलो करते हैं, तो यह पढ़ने में मदद करता है: सबसे ऊपर common विकल्पों से शुरू करें और फ़ाइल के नीचे सबसे खास निर्देशों के साथ खत्म करें. इस तरह से, विकल्पों को उसी क्रम में पढ़ा जाएगा जिस क्रम में उन्हें लागू किया जाएगा. यह ज़्यादा आसान होता है.

rc फ़ाइल की लाइन में दिए गए तर्कों में, ऐसे तर्क शामिल हो सकते हैं जो विकल्प नहीं होते. जैसे, बिल्ड टारगेट के नाम वगैरह. इन ही फ़ाइलों में बताए गए विकल्पों की तरह, इनकी भी कमांड लाइन पर प्रतिरूपों की तुलना में कम प्राथमिकता होती है. साथ ही, इन्हें हमेशा बिना विकल्प वाले तर्कों की साफ़ सूची से पहले जोड़ा जाता है.

--config

विकल्प को डिफ़ॉल्ट तौर पर सेट करने के अलावा, आरसी फ़ाइल का इस्तेमाल विकल्पों को ग्रुप करने और सामान्य ग्रुप के लिए शॉर्टहैंड मुहैया कराने के लिए किया जा सकता है. ऐसा करने के लिए, कमांड में :name सफ़िक्स को जोड़ें. इन विकल्पों को डिफ़ॉल्ट रूप से अनदेखा किया जाता है. हालांकि, --config=name विकल्प मौजूद होने पर, इन्हें कमांड लाइन या .bazelrc फ़ाइल में बार-बार शामिल किया जाएगा. ऐसा किसी दूसरी कॉन्फ़िगरेशन परिभाषा में भी बार-बार किया जाएगा. command:name के बताए गए विकल्पों को सिर्फ़ लागू निर्देशों के लिए, ऊपर बताए गए प्राथमिकता के क्रम में बड़ा किया जाएगा.

--config=foo, आरसी फ़ाइलों "इन-प्लेस" में दिए गए विकल्पों के दायरे में आता है, ताकि कॉन्फ़िगरेशन के लिए बताए गए विकल्पों की प्राथमिकता वही हो जो --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

आप फ़ाइल फ़ोल्डर में ऐसी डायरेक्ट्री तय कर सकते हैं जिन्हें Bazel अनदेखा करना चाहता है. जैसे कि दूसरे बिल्ड सिस्टम का इस्तेमाल करने वाले मिलते-जुलते प्रोजेक्ट. .bazelignore नाम की फ़ाइल को फ़ाइल फ़ोल्डर की रूट में रखें. साथ ही, उन डायरेक्ट्री को जोड़ें जिन्हें आप Bazel से अनदेखा कराना चाहते हैं. एक लाइन में एक ही डायरेक्ट्री जोड़ें. एंट्री, फ़ाइल फ़ोल्डर के रूट से जुड़ी होती हैं.

ग्लोबल bazelrc फ़ाइल

Bazel, वैकल्पिक bazelrc फ़ाइलों को इस क्रम में पढ़ता है: - etc/bazel.bazelrc पर मौजूद सिस्टम rc-file. - Workspace की आरसी-फ़ाइल, $workspace/tools/bazel.rc पर मौजूद है. - होम की आरसी-फ़ाइल $HOME/.bazelrc में स्थानीय है

यहां दी गई हर bazelrc फ़ाइल में, उससे जुड़ा एक फ़्लैग मौजूद है. इसे बंद करने के लिए इस्तेमाल किया जा सकता है (जैसे, --nosystem_rc, --noworkspace_rc, --nohome_rc). --ignore_all_rc_files स्टार्टअप विकल्प पास करके, Bazel को सभी bazelrcs अनदेखा किए जा सकते हैं.