इस पेज का अनुवाद Cloud Translation API से किया गया है.

फ़ाइल फ़ोल्डर के नियम

Workspace के नियमों का इस्तेमाल, बाहरी डिपेंडेंसी पाने के लिए किया जाता है. आम तौर पर, यह सोर्स कोड मुख्य रिपॉज़िटरी के बाहर मौजूद होता है.

ध्यान दें: नेटिव वर्कस्पेस के नियमों के अलावा, Bazel कई Starlark के फ़ाइल फ़ोल्डर के नियमों को भी जोड़ता है. खास तौर पर, इससे वे गिट के डेटा स्टोर करने की जगहों या वेब पर होस्ट किए गए संग्रह के नियमों का पता लगाते हैं.

bind

नियम का सोर्स देखें

bind(name, actual, compatible_with, deprecation, distribs, features, licenses, restricted_to, tags, target_compatible_with, testonly, visibility)

चेतावनी: bind() इस्तेमाल करने का सुझाव नहीं दिया जाता. इसकी समस्याओं और इसके विकल्पों के बारे में लंबी चर्चा के लिए, "बाइंड हटाने की कोशिश करें" देखें. खास तौर पर, repo_mapping डेटा स्टोर करने की जगह के एट्रिब्यूट के इस्तेमाल पर ध्यान दें.

चेतावनी: select() का इस्तेमाल bind() में नहीं किया जा सकता. ज़्यादा जानकारी के लिए, कॉन्फ़िगर किए जा सकने वाले एट्रिब्यूट के बारे में अक्सर पूछे जाने वाले सवाल देखें.

//external पैकेज में टारगेट को एक उपनाम देता है.

//external पैकेज, "सामान्य" पैकेज नहीं है: कोई बाहरी/ डायरेक्ट्री नहीं होती. इसलिए, इसे एक ऐसा "वर्चुअल पैकेज" माना जा सकता है जिसमें तय किए गए सभी टारगेट शामिल हों.

उदाहरण

किसी टारगेट को उपनाम देने के लिए, उसे Workspace फ़ाइल में bind करें. उदाहरण के लिए, मान लें कि //third_party/javacc-v2 नाम का एक java_library टारगेट है. Workspace फ़ाइल में इन्हें जोड़कर, इसे उपनाम जोड़ा जा सकता है:

bind(
    name = "javacc-latest",
    actual = "//third_party/javacc-v2",
)

अब टारगेट //third_party/javacc-v2 के बजाय, //external:javacc-latest पर निर्भर हो सकते हैं. अगर javacc-v3 रिलीज़ किया जाता है, तो bind नियम को अपडेट किया जा सकता है. साथ ही, //external:javacc-latest के आधार पर सभी BUILD फ़ाइलें अब बिना बदलाव के javacc-v3 पर निर्भर होंगी.

बाइंड का इस्तेमाल, बाहरी डेटा स्टोर करने की जगहों में मौजूद टारगेट को आपके फ़ाइल फ़ोल्डर में उपलब्ध कराने के लिए भी किया जा सकता है. उदाहरण के लिए, अगर Workspace फ़ाइल में @my-ssl नाम का कोई रिमोट रिपॉज़िटरी (डेटा स्टोर करने की जगह) इंपोर्ट किया गया है और उसमें cc_library टारगेट //src:openssl-lib है, तो bind का इस्तेमाल करके, इस टारगेट के लिए उपनाम बनाया जा सकता है:

bind(
    name = "openssl",
    actual = "@my-ssl//src:openssl-lib",
)

इसके बाद, आपके फ़ाइल फ़ोल्डर में BUILD फ़ाइल में, बाउंड टारगेट का इस तरह इस्तेमाल किया जा सकता है:

cc_library(
    name = "sign-in",
    srcs = ["sign_in.cc"],
    hdrs = ["sign_in.h"],
    deps = ["//external:openssl"],
)

sign_in.cc और sign_in.h में, //external:openssl जिन हेडर फ़ाइलों को दिखाता है उन्हें उनके डेटा स्टोर करने की जगह के रूट के पाथ का इस्तेमाल करके रेफ़र किया जा सकता है. उदाहरण के लिए, अगर @my-ssl//src:openssl-lib के लिए नियम की परिभाषा इस तरह दिखती है:

cc_library(
    name = "openssl-lib",
    srcs = ["openssl.cc"],
    hdrs = ["openssl.h"],
)

ऐसा करने पर, sign_in.cc के शामिल करने पर कुछ ऐसा दिख सकता है:

#include "sign_in.h"
#include "src/openssl.h"

तर्क

विशेषताएं

name

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

इस टारगेट के लिए यूनीक नाम.

actual

लेबल; None डिफ़ॉल्ट है

वह टारगेट जिसे ईमेल करना है.

यह टारगेट मौजूद होना चाहिए, लेकिन यह किसी भी तरह का नियम हो सकता है. इसमें बाइंड भी शामिल है.

अगर इस एट्रिब्यूट को शामिल नहीं किया जाता है, तो //external में इस टारगेट को रेफ़र करने वाले नियमों को यह डिपेंडेंसी एज नहीं दिखेगा. ध्यान दें कि यह bind नियम को पूरी तरह से छोड़ने से अलग है: अगर //external डिपेंडेंसी से कोई bind नियम नहीं जुड़ा है, तो यह गड़बड़ी होती है.

local_repository

नियम का सोर्स देखें

local_repository(name, path, repo_mapping)

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

उदाहरण

मान लीजिए कि मौजूदा डेटा स्टोर करने की जगह एक चैट क्लाइंट है, जो ~/chat-app डायरेक्ट्री पर रूट किया गया है. वह एसएसएल लाइब्रेरी का इस्तेमाल करना चाहता है, जो किसी अलग रिपॉज़िटरी (डेटा स्टोर करने की जगह) में दी गई है: ~/एसएसएल. एसएसएल लाइब्रेरी में टारगेट //src:openssl-lib है.

उपयोगकर्ता ~/chat-app/WorkSPACE में ये लाइनें जोड़कर, इस टारगेट पर डिपेंडेंसी जोड़ सकता है:

local_repository(
    name = "my-ssl",
    path = "/home/user/ssl",
)

टारगेट, इस लाइब्रेरी पर निर्भर होने के लिए @my-ssl//src:openssl-lib को डिपेंडेंसी के तौर पर तय करेंगे.

तर्क

विशेषताएं

name

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

इस टारगेट के लिए यूनीक नाम.

path

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

लोकल रिपॉज़िटरी की डायरेक्ट्री का पाथ.

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

repo_mapping

शब्दकोश: स्ट्रिंग -> स्ट्रिंग; {} डिफ़ॉल्ट है

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

उदाहरण के लिए, "@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, workspace_file, workspace_file_content)

इससे किसी लोकल डायरेक्ट्री को Bazel डेटा स्टोर करने की जगह में बदलने की अनुमति मिलती है. इसका मतलब है कि मौजूदा रिपॉज़िटरी, फ़ाइल सिस्टम में कहीं से भी टारगेट को तय और इस्तेमाल कर सकता है.

यह नियम एक ऐसी PHONESPACE फ़ाइल और सबडायरेक्ट्री बनाकर Bazel डेटा स्टोर करता है जिसमें BUILD फ़ाइल और दिए गए पाथ के सिमलिंक होते हैं. बिल्ड फ़ाइल को path से मिलते-जुलते टारगेट बनाने चाहिए. जिन डायरेक्ट्री में पहले से ही वर्कSPACE फ़ाइल और BUILD फ़ाइल है, उनके लिए local_repository नियम का इस्तेमाल किया जा सकता है.

उदाहरण

मान लीजिए कि मौजूदा डेटा स्टोर करने की जगह एक चैट क्लाइंट है, जो ~/chat-app डायरेक्ट्री पर रूट किया गया है. वह एसएसएल लाइब्रेरी का इस्तेमाल करना चाहता है, जिसकी जानकारी किसी दूसरी डायरेक्ट्री में दी गई है: ~/एसएसएल.

उपयोगकर्ता उस एसएसएल लाइब्रेरी (~/chat-app/BUILD.my-एसएसएल) के लिए BUILD फ़ाइल बनाकर, डिपेंडेंसी जोड़ सकता है, जिसमें ये चीज़ें शामिल हों:

java_library(
    name = "openssl",
    srcs = glob(['*.java'])
    visibility = ["//visibility:public"],
)

इसके बाद, वह ~/chat-app/WorkspaceSPACE में ये लाइनें जोड़ सकता है:

new_local_repository(
    name = "my-ssl",
    path = "/home/user/ssl",
    build_file = "BUILD.my-ssl",
)

इससे एक @my-ssl रिपॉज़िटरी बन जाएगा, जो /home/user/ssl से सिमलिंक करेगा. किसी टारगेट की डिपेंडेंसी में @my-ssl//:openssl को जोड़कर, टारगेट इस लाइब्रेरी पर निर्भर हो सकते हैं.

new_local_repository का इस्तेमाल करके, सिर्फ़ डायरेक्ट्री को ही नहीं, बल्कि एक ही फ़ाइल को शामिल किया जा सकता है. उदाहरण के लिए, मान लें कि आपके पास /home/username/Downloads/piano.jar पर एक जार फ़ाइल थी. अपनी Workspace फ़ाइल में नीचे दी गई चीज़ें जोड़कर, आप सिर्फ़ उसी फ़ाइल को अपने बिल्ड में जोड़ सकते हैं:

new_local_repository(
    name = "piano",
    path = "/home/username/Downloads/piano.jar",
    build_file = "BUILD.piano",
)

साथ ही, नीचे दी गई BUILD.piano फ़ाइल बनाकर:

java_import(
    name = "play-music",
    jars = ["piano.jar"],
    visibility = ["//visibility:public"],
)

इसके बाद, Piano.jar का इस्तेमाल करने के लिए, टारगेट @piano//:play-music पर निर्भर हो सकते हैं.

तर्क

विशेषताएं
`name`	नाम; ज़रूरी है इस टारगेट के लिए यूनीक नाम.
`build_file`	नाम; `None` डिफ़ॉल्ट है इस डायरेक्ट्री के लिए, BUILD फ़ाइल के तौर पर इस्तेमाल करने के लिए फ़ाइल. बिल्ड_फ़ाइल या बिल्ड_फ़ाइल_कॉन्टेंट से जुड़ी जानकारी देना ज़रूरी है. यह एट्रिब्यूट मुख्य फ़ाइल फ़ोल्डर से जुड़ा लेबल है. फ़ाइल को BUILD नाम देने की ज़रूरत नहीं है, लेकिन ऐसा किया जा सकता है. (BUILD.new-repo-name जैसी कुछ चीज़ें, इसे रिपॉज़िटरी की असली BUILD फ़ाइलों से अलग करने में अच्छी तरह से काम कर सकती हैं.)
`build_file_content`	स्ट्रिंग; `""` डिफ़ॉल्ट तौर पर सेट है इस रिपॉज़िटरी के लिए BUILD फ़ाइल का कॉन्टेंट. बिल्ड_फ़ाइल या बिल्ड_फ़ाइल_कॉन्टेंट से जुड़ी जानकारी देना ज़रूरी है.
`path`	स्ट्रिंग; ज़रूरी है लोकल फ़ाइल सिस्टम का पाथ. यह काफ़ी हद तक डेटा स्टोर करने की जगह की मुख्य जगह की SPACESPACE फ़ाइल से मिलता-जुलता या पूरा डेटा हो सकता है.
`repo_mapping`	शब्दकोश: स्ट्रिंग -> स्ट्रिंग; `{}` डिफ़ॉल्ट है स्थानीय डेटा स्टोर करने की जगह के नाम से ग्लोबल रिपॉज़िटरी के नाम तक का शब्दकोश. इससे, इस रिपॉज़िटरी की डिपेंडेंसी के लिए Workspace डिपेंडेंसी रिज़ॉल्यूशन को कंट्रोल करने की अनुमति मिलती है. उदाहरण के लिए, `"@foo": "@bar"` में यह एलान किया गया है कि जब भी डेटा स्टोर करने की जगह `"@foo"` (जैसे कि `"@foo//some:target"` पर निर्भरता) पर निर्भर करती है, तब इसे दुनिया भर में बताए गए `"@bar"` (`"@bar//some:target"`) में उस डिपेंडेंसी का समाधान करना चाहिए.
`workspace_file`	नाम; `None` डिफ़ॉल्ट है इस फ़ाइल को डेटा स्टोर करने की इस जगह के लिए, Workspace फ़ाइल के तौर पर इस्तेमाल किया जाना है. Workspace_file या Workspace_file_content में से किसी एक को तय किया जा सकता है, लेकिन दोनों को नहीं. यह एट्रिब्यूट मुख्य फ़ाइल फ़ोल्डर से जुड़ा लेबल है. फ़ाइल को 'काम करने की जगह' नाम देने की ज़रूरत नहीं है, लेकिन यह नाम दिया जा सकता है. (इसे डेटा स्टोर करने की जगह की असल वर्कस्पेस फ़ाइलों से अलग करने के लिए, वर्कSPACE.new-repo-name जैसा कुछ इस्तेमाल किया जा सकता है.)
`workspace_file_content`	स्ट्रिंग; `""` डिफ़ॉल्ट तौर पर सेट है इस डेटा स्टोर करने की जगह के लिए Workspace फ़ाइल का कॉन्टेंट. Workspace_file या Workspace_file_content में से किसी एक को तय किया जा सकता है, लेकिन दोनों को नहीं.