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

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

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

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

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

   पाथ:

   • Linux/macOS/Unix पर: /etc/bazel.bazelrc
   • Windows पर: %ProgramData%\bazel.bazelrc

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

   अगर सिस्टम के हिसाब से तय की गई किसी अन्य जगह की जानकारी की ज़रूरत है, तो आपको //src/main/cpp:option_processor में BAZEL_SYSTEM_BAZELRC_PATH वैल्यू को बदलकर, कस्टम Bazel बाइनरी बनानी होगी. सिस्टम के हिसाब से तय की गई जगह में एनवायरमेंट वैरिएबल के रेफ़रंस हो सकते हैं. जैसे, Unix पर ${VAR_NAME} या Windows पर %VAR_NAME%.

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

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

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

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

   पाथ:

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

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

4. एनवायरमेंट वैरिएबल RC फ़ाइल, अगर इसका पाथ BAZELRC एनवायरमेंट वैरिएबल के साथ सेट किया गया है.

   एनवायरमेंट वैरिएबल में, कॉमा लगाकर अलग किए गए कई पाथ शामिल किए जा सकते हैं.

5. उपयोगकर्ता की ओर से तय की गई RC फ़ाइल, अगर --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 को अनदेखा कर दिया गया है.

इस कॉन्फ़िगरेशन फ़ाइल के अलावा, Bazel एक ग्लोबल rc फ़ाइल भी खोजता है. ज़्यादा जानकारी के लिए, global bazelrc सेक्शन देखें.

.bazelrc सिंटैक्स और सिमैंटिक

सभी UNIX "rc" फ़ाइलों की तरह, .bazelrc फ़ाइल भी एक टेक्स्ट फ़ाइल होती है. इसमें लाइन के हिसाब से व्याकरण होता है. खाली लाइनों और # (टिप्पणियां) से शुरू होने वाली लाइनों को अनदेखा किया जाता है. हर लाइन में शब्दों का एक क्रम होता है, जिसे Bourne shell के नियमों के मुताबिक टोकन में बदला जाता है.

आयात

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

अलग-अलग इंपोर्ट स्टेटमेंट के बीच का अंतर यहां दिया गया है:

• import - अगर imported की गई फ़ाइल मौजूद नहीं है या उसे पढ़ा नहीं जा सकता, तो Bazel काम नहीं करेगा
• try-import - फ़ाइल को इंपोर्ट करने की कोशिश की जाएगी. हालांकि, import के उलट, अगर फ़ाइल मौजूद नहीं है या उसे पढ़ा नहीं जा सकता, तो Bazel काम करना बंद नहीं करेगा.
• try-import-if-bazel-version - यह try-import की तरह ही है. हालांकि, इंपोर्ट करने से पहले Bazel के मौजूदा वर्शन की एक और शर्त की जांच की जाती है. सिंटैक्स के लिए यहां देखें.

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

# Strictly greater than: used for post-release targeting
try-import-if-bazel-version >7.0.0 %workspace%/configs/post_v7.rc

# Greater than or equal to: commonly used for feature introduction
try-import-if-bazel-version >=6.0.0 %workspace%/configs/features.rc

# Strictly less than: used for deprecated flags removed in newer versions
try-import-if-bazel-version <7.0.0 %workspace%/configs/legacy.rc

# Less than or equal to: caps configuration to a specific version
try-import-if-bazel-version <=5.4.0 %workspace%/configs/v5_fixes.rc

# Exact match: hotfix for a specific broken release
try-import-if-bazel-version ==6.3.2 %workspace%/configs/hotfix_6.3.2.rc

# Not equal to: excludes broken version from standard config
try-import-if-bazel-version !=7.0.1 %workspace%/configs/standard.rc

टिल्ड ऑपरेटर, पैच, माइनर, और मेजर वर्शन में बदलावों के लिए रेंज उपलब्ध कराता है:

# Equivalent to >=1.2.3 <1.3.0
try-import-if-bazel-version ~1.2.3 %workspace%/configs/1.2.3_flags.rc

# Equivalent to >=1.2.0 <1.3.0 (Same as 1.2.x)
try-import-if-bazel-version ~1.2 %workspace%/configs/1.2_flags.rc

# Equivalent to >=1.0.0 <2.0.0 (Same as 1.x)
try-import-if-bazel-version ~1 %workspace%/configs/v1_flags.rc

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

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

विकल्पों की डिफ़ॉल्ट सेटिंग

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

• startup: स्टार्टअप के विकल्प, जो कमांड से पहले आते हैं. इनके बारे में bazel help startup_options में बताया गया है.
• common: ऐसे विकल्प जिन्हें Bazel के उन सभी निर्देशों पर लागू किया जाना चाहिए जो उन्हें सपोर्ट करते हैं. अगर कोई निर्देश, इस तरह से तय किए गए विकल्प के साथ काम नहीं करता है, तो उस विकल्प को तब तक अनदेखा किया जाता है, जब तक वह किसी अन्य Bazel निर्देश के लिए मान्य हो. ध्यान दें कि यह सिर्फ़ विकल्प के नामों पर लागू होता है: अगर मौजूदा कमांड, तय किए गए नाम वाले विकल्प को स्वीकार करती है, लेकिन तय की गई वैल्यू के साथ काम नहीं करती है, तो यह काम नहीं करेगी.
• always: ऐसे विकल्प जो Bazel के सभी निर्देशों पर लागू होते हैं. अगर कोई निर्देश, इस तरीके से तय किए गए विकल्प के साथ काम नहीं करता है, तो वह काम नहीं करेगा.
• command: Bazel कमांड, जैसे कि build या query, जिन पर विकल्प लागू होते हैं. ये विकल्प, उन सभी कमांड पर भी लागू होते हैं जो बताई गई कमांड से इनहेरिट की जाती हैं. (उदाहरण के लिए, test, build से इनहेरिट करता है.)

इनमें से हर लाइन का इस्तेमाल एक से ज़्यादा बार किया जा सकता है. साथ ही, पहले शब्द के बाद दिए गए आर्ग्युमेंट को इस तरह से जोड़ा जाता है जैसे वे एक ही लाइन में दिख रहे हों. (CVS का इस्तेमाल करने वाले लोगों को, .cvsrc का सिंटैक्स एक जैसा लगेगा. CVS, "स्विस आर्मी नाइफ़" कमांड-लाइन इंटरफ़ेस वाला एक और टूल है.) उदाहरण के लिए, ये लाइनें:

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 फ़ाइलों में दिए गए विकल्पों से ज़्यादा प्राथमिकता पाते हैं. उदाहरण के लिए, अगर किसी 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, fetch, और vendor, test से इनहेरिट करते हैं

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

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

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

--config

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

--config=foo, rc फ़ाइलों में तय किए गए विकल्पों के हिसाब से "इन-प्लेस" में फैलता है, ताकि कॉन्फ़िगरेशन के लिए तय किए गए विकल्पों को वही प्राथमिकता मिले जो --config=foo विकल्प को मिली थी.

यह सिंटैक्स, स्टार्टअप के विकल्प सेट करने के लिए startup के इस्तेमाल पर लागू नहीं होता. .bazelrc फ़ाइल में startup:config-name --some_startup_option सेटिंग को अनदेखा कर दिया जाएगा.

--enable_platform_specific_config

--enable_platform_specific_config का इस्तेमाल करके, .bazelrc में प्लैटफ़ॉर्म के हिसाब से कॉन्फ़िगरेशन अपने-आप चालू किए जा सकते हैं. उदाहरण के लिए, अगर होस्ट ओएस Linux है और build कमांड चलाई जाती है, तो build:linux कॉन्फ़िगरेशन अपने-आप चालू हो जाएगा. linux, macos, windows, freebsd, और openbsd जैसे ओएस आइडेंटिफ़ायर इस्तेमाल किए जा सकते हैं. इस फ़्लैग को चालू करने का मतलब है कि Linux पर --config=linux, Windows पर --config=windows, macOS पर --config=macos, FreeBSD पर --config=freebsd, और OpenBSD पर --config=openbsd का इस्तेमाल किया जा रहा है.

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

.bazelignore फ़ाइल में ग्लोब सिमैंटिक की अनुमति नहीं है. Bazel 8 में REPO.bazel फ़ाइल पेश की गई है. इससे दूसरे डायरेक्टिव, ignore_directories() का इस्तेमाल किया जा सकता है. यह .bazelignore की तरह ही, अनदेखी की जाने वाली डायरेक्ट्री की सूची लेता है. हालांकि, इसमें ग्लोब सिमैंटिक का इस्तेमाल किया जाता है. #24203 देखें.

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

Bazel, इस क्रम में वैकल्पिक bazelrc फ़ाइलें पढ़ता है:

1. सिस्टम rc-फ़ाइल, /etc/bazel.bazelrc पर मौजूद है.
2. फ़ाइल फ़ोल्डर की rc-फ़ाइल, $workspace/tools/bazel.rc पर मौजूद है.
3. होम rc-फ़ाइल $HOME/.bazelrc पर मौजूद है

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