डेटा स्टोर करने की स्थानीय जगह के नियम

@bazel_tools//tools/build_defs/repo:local.bzl से, ये फ़ंक्शन लोड किए जा सकते हैं.

लोकल फ़ाइल सिस्टम में मौजूद डायरेक्ट्री को, डेटाबेस के तौर पर उपलब्ध कराने के नियम.

सेटअप

मॉड्यूल एक्सटेंशन में इन नियमों का इस्तेमाल करने के लिए, इन्हें अपनी .bzl फ़ाइल में लोड करें. इसके बाद, अपने एक्सटेंशन के लागू करने वाले फ़ंक्शन से इन्हें कॉल करें. उदाहरण के लिए, local_repository का इस्तेमाल करने के लिए:

load("@bazel_tools//tools/build_defs/repo:local.bzl", "local_repository")

def _my_extension_impl(mctx):
  local_repository(name = "foo", path = "foo")

my_extension = module_extension(implementation = _my_extension_impl)

इसके अलावा, use_repo_rule की मदद से, MODULE.bazel फ़ाइल में इन डेटाबेस के नियमों को सीधे कॉल किया जा सकता है:

local_repository = use_repo_rule("@bazel_tools//tools/build_defs/repo:local.bzl", "local_repository")
local_repository(name = "foo", path = "foo")

local_repository

local_repository(name, path, repo_mapping)

इससे, लोकल डायरेक्ट्री को डेटाबेस के तौर पर उपलब्ध कराया जा सकता है. इस डायरेक्ट्री में Bazel की फ़ाइलें पहले से मौजूद होनी चाहिए. इस डायरेक्ट्री में, Bazel की BUILD फ़ाइलें और डेटाबेस की बाउंड्री फ़ाइल पहले से मौजूद होनी चाहिए. अगर इनमें ये फ़ाइलें मौजूद नहीं हैं, तो <a href="#new_local_repository"><code>new_local_repository</code></a> का इस्तेमाल करें.

विशेषताएं

name नाम; ज़रूरी है

इस डेटाबेस के लिए यूनीक नाम.

path स्ट्रिंग; ज़रूरी है

उस डायरेक्ट्री का पाथ जिसे डेटाबेस के तौर पर उपलब्ध कराना है.

पाथ, ऐब्सलूट या वर्कस्पेस रूट के हिसाब से हो सकता है.

repo_mapping डिक्शनरी: स्ट्रिंग -> स्ट्रिंग; ज़रूरी है

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

उदाहरण के लिए, `"@foo": "@bar"` एंट्री से यह पता चलता है कि जब भी यह डेटाबेस `@foo` पर निर्भर करती है (जैसे कि `@foo//some:target` पर निर्भरता), तो इसे असल में, वैश्विक तौर पर घोषित `@bar` (`@bar//some:target`) के अंदर उस निर्भरता को हल करना चाहिए.

new_local_repository

new_local_repository(name, build_file, build_file_content, path, repo_mapping)

इससे, लोकल डायरेक्ट्री को डेटाबेस के तौर पर उपलब्ध कराया जा सकता है. इस डायरेक्ट्री में Bazel की फ़ाइलें मौजूद नहीं होनी चाहिए. यह ज़रूरी नहीं है कि इस डायरेक्ट्री में, Bazel की BUILD फ़ाइलें या डेटाबेस की बाउंड्री फ़ाइल मौजूद हों. ये फ़ाइलें, डेटाबेस के इस नियम से बनाई जाएंगी. अगर डायरेक्ट्री में Bazel की फ़ाइलें पहले से मौजूद हैं, तो <a href="#local_repository"><code>local_repository</code></a> का इस्तेमाल करें.

विशेषताएं

name नाम; ज़रूरी है

इस डेटाबेस के लिए यूनीक नाम.

build_file लेबल; ज़रूरी नहीं

इस डेटाबेस के लिए, BUILD फ़ाइल के तौर पर इस्तेमाल की जाने वाली फ़ाइल.

build_file और build_file_content में से किसी एक को तय करना ज़रूरी है.

यह ज़रूरी नहीं है कि इस लेबल से जुड़ी फ़ाइल का नाम BUILD हो. हालांकि, ऐसा किया जा सकता है. इसे असल BUILD फ़ाइलों से अलग करने के लिए, BUILD.new-repo-name जैसे नाम का इस्तेमाल किया जा सकता है.

build_file_content स्ट्रिंग; ज़रूरी नहीं

इस डेटाबेस के लिए बनाई जाने वाली BUILD फ़ाइल का कॉन्टेंट.

build_file और build_file_content में से किसी एक को तय करना ज़रूरी है.

path स्ट्रिंग; ज़रूरी है

उस डायरेक्ट्री का पाथ जिसे डेटाबेस के तौर पर उपलब्ध कराना है.

पाथ, ऐब्सलूट या वर्कस्पेस रूट के हिसाब से हो सकता है.

repo_mapping डिक्शनरी: स्ट्रिंग -> स्ट्रिंग; ज़रूरी है

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

उदाहरण के लिए, `"@foo": "@bar"` एंट्री से यह पता चलता है कि जब भी यह डेटाबेस `@foo` पर निर्भर करती है (जैसे कि `@foo//some:target` पर निर्भरता), तो इसे असल में, वैश्विक तौर पर घोषित `@bar` (`@bar//some:target`) के अंदर उस निर्भरता को हल करना चाहिए.