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

समस्या की शिकायत करें सोर्स देखें

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

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

Basel, नीचे दिए गए क्रम में, वैकल्पिक कॉन्फ़िगरेशन फ़ाइलों को नीचे दिए गए क्रम में ढूंढती है. विकल्पों की व्याख्या इसी क्रम में की जाती है, ताकि कोई समस्या होने पर, बाद की फ़ाइलों के विकल्प, पिछली फ़ाइल की वैल्यू को बदल दें. इनमें से किन फ़ाइलों को लोड किया जाए, यह कंट्रोल करने वाले सभी विकल्प, स्टार्टअप विकल्प हैं. इसका मतलब है कि ये 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. Workspace की आरसी फ़ाइल, जब तक कि --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 पढ़ी गई हैं.
   • 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 में दिए गए विकल्पों को सिर्फ़ लागू होने वाले निर्देशों के लिए बड़ा किया जाएगा. ऐसा ऊपर बताए गए प्राथमिकता के क्रम में किया जाएगा.

ध्यान दें: कॉन्फ़िगरेशन को किसी भी .bazelrc फ़ाइल में तय किया जा सकता है. साथ ही, अलग-अलग rc फ़ाइलों में, 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ज़र, वैकल्पिक bazerc फ़ाइलों को इस क्रम में पढ़ता है: - सिस्टम rc-file, etc/bazel.bazelrc पर मौजूद है. - Workspace rc-फ़ाइल, $workspace/tools/bazel.rc पर मौजूद है. - होम आरसी-फ़ाइल की जगह $HOME/.bazelrc पर दी गई

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