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

किसी समस्या की शिकायत करें सोर्स देखें Nightly · 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

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

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

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

  1. सिस्टम की आरसी फ़ाइल, बशर्ते --nosystem_rc मौजूद न हो.

    पाथ:

    • Linux/macOS/Unix पर: /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 को अनदेखा कर दिया जाएगा. यह जानकारी, रिलीज़ बिल्ड जैसी किसी उपयोगकर्ता rc फ़ाइल की खोज को बंद करने के लिए काम की है.

    उदाहरण के लिए:

    --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 फ़ाइल भी एक टेक्स्ट फ़ाइल है, जिसमें लाइन पर आधारित व्याकरण का इस्तेमाल किया जाता है. # (टिप्पणियों) से शुरू होने वाली खाली लाइनों और लाइनों को अनदेखा कर दिया जाता है. हर लाइन में शब्दों का क्रम होता है. इन्हें Bourne shell के नियमों के मुताबिक टोकन में बदला जाता है.

आयात

import या try-import से शुरू होने वाली लाइनें खास होती हैं: इनका इस्तेमाल, अन्य "rc" फ़ाइलों को लोड करने के लिए करें. वर्कस्पेस के रूट से जुड़ा पाथ तय करने के लिए, import %workspace%/path/to/bazelrc लिखें.

import और try-import के बीच अंतर यह है कि import की फ़ाइल मौजूद न होने (या उसे पढ़ा नहीं जा सकता) होने पर Basel काम नहीं करता है. हालांकि, try-import'ed फ़ाइल के लिए ऐसा नहीं होता है.

इंपोर्ट की प्राथमिकता:

  • इंपोर्ट स्टेटमेंट से पहले दिए गए विकल्पों की तुलना में, इंपोर्ट की गई फ़ाइल के विकल्पों को प्राथमिकता दी जाती है.
  • इंपोर्ट स्टेटमेंट के बाद बताए गए विकल्प, इंपोर्ट की गई फ़ाइल के विकल्पों से ज़्यादा अहम होते हैं.
  • बाद में इंपोर्ट की गई फ़ाइलों के विकल्प, पहले इंपोर्ट की गई फ़ाइलों के विकल्पों से ज़्यादा प्राथमिकता पाते हैं.

डिफ़ॉल्ट विकल्प

bazelrc की ज़्यादातर लाइनें, विकल्प की डिफ़ॉल्ट वैल्यू तय करती हैं. हर लाइन के पहले शब्द से पता चलता है कि ये डिफ़ॉल्ट वैल्यू कब लागू होती हैं:

  • startup: स्टार्टअप के विकल्प, जो कमांड से पहले आते हैं और जिनके बारे में bazel help startup_options में बताया गया है.
  • common: ऐसे विकल्प जो Basel के सभी कमांड पर लागू होते हैं.
  • 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 हैं.

विकल्प के लागू होने की प्राथमिकता:

  • कमांड लाइन के विकल्पों को, 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 सफ़िक्स जोड़कर दिखाया जाता है. इन विकल्पों को डिफ़ॉल्ट रूप से अनदेखा किया जाता है. हालांकि, --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

बेज़ल के व्यवहार को कंट्रोल करने वाली अन्य फ़ाइलें

.bazelignore

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

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

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

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