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

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

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

नियम

• बाइंड
• local_repository
• new_local_repository

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	Name; required इस टारगेट के लिए एक खास नाम.
actual	Label; optional टारगेट को उपनाम दिया जाना है. यह टारगेट मौजूद होना चाहिए, लेकिन यह किसी भी तरह का नियम हो सकता है (इसमें बाइंड भी शामिल है). अगर यह एट्रिब्यूट हटाया जाता है, तो //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	Name; required इस टारगेट के लिए एक खास नाम.
path	String; required लोकल रिपॉज़िटरी की डायरेक्ट्री का पाथ. यह उस डायरेक्ट्री का पाथ होना चाहिए जिसमें डेटा स्टोर करने की जगह की WORKSPACE फ़ाइल मौजूद है. पाथ, मुख्य रिपॉज़िटरी (डेटा स्टोर करने की जगह) की Workspace फ़ाइल से जुड़ा हो सकता है या उससे जुड़ा हो सकता है.
repo_mapping	Dictionary: String -> String; optional स्थानीय डेटा स्टोर करने की जगह के नाम से ग्लोबल रिपॉज़िटरी के नाम तक का शब्दकोश. इससे, इस रिपॉज़िटरी की डिपेंडेंसी के लिए, फ़ाइल फ़ोल्डर डिपेंडेंसी रिज़ॉल्यूशन को कंट्रोल किया जा सकता है. उदाहरण के लिए, "@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 का डेटा स्टोर करने की अनुमति मिलती है. इसका मतलब है कि डेटा स्टोर करने की मौजूदा जगह, फ़ाइल सिस्टम में कहीं से भी टारगेट को तय कर सकती है और उनका इस्तेमाल कर सकती है.

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

उदाहरण

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

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

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

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

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//:play-music पर निर्भर हो सकते हैं.

तर्क

एट्रिब्यूट
name	Name; required इस टारगेट के लिए एक खास नाम.
build_file	String; optional इस डायरेक्ट्री के लिए, BUILD फ़ाइल के तौर पर इस्तेमाल करने के लिए फ़ाइल. बिल्ड_फ़ाइल या बिल्ड_फ़ाइल_कॉन्टेंट से जुड़ी जानकारी देना ज़रूरी है. यह एट्रिब्यूट मुख्य फ़ाइल फ़ोल्डर से जुड़ा लेबल है. फ़ाइल को BUILD नाम देने की ज़रूरत नहीं है, लेकिन इसे नाम दिया जा सकता है. (BUILD.new-repo-name जैसी कोई चीज़, इसे रिपॉज़िटरी की असल BUILD फ़ाइलों से अलग करने में अच्छी तरह काम कर सकती है.)
build_file_content	String; optional इस रिपॉज़िटरी के लिए BUILD फ़ाइल का कॉन्टेंट. बिल्ड_फ़ाइल या बिल्ड_फ़ाइल_कॉन्टेंट से जुड़ी जानकारी देना ज़रूरी है.
path	String; required लोकल फ़ाइल सिस्टम का पाथ. यह डेटा रिपॉज़िटरी की मुख्य फ़ाइल की WORKSPACE फ़ाइल से जुड़ा हो सकता है या यह बिलकुल सही हो सकता है.
repo_mapping	Dictionary: String -> String; optional स्थानीय डेटा स्टोर करने की जगह के नाम से ग्लोबल रिपॉज़िटरी के नाम तक का शब्दकोश. इससे, इस रिपॉज़िटरी की डिपेंडेंसी के लिए, फ़ाइल फ़ोल्डर डिपेंडेंसी रिज़ॉल्यूशन को कंट्रोल किया जा सकता है. उदाहरण के लिए, "@foo": "@bar" की एक एंट्री में यह बताया गया है कि जब भी यह रिपॉज़िटरी, "@foo" पर निर्भर करती है (जैसे, "@foo//some:target" पर निर्भरता), तो उसे दुनिया भर में बताए गए "@bar" ("@bar//some:target") में उस डिपेंडेंसी को ठीक करना चाहिए.
workspace_file	String; optional इस डेटा स्टोर करने की जगह के लिए, WORKSPACE फ़ाइल के तौर पर इस्तेमाल की जाने वाली फ़ाइल. Workspace_file या Workspace_file_content में से किसी एक को तय किया जा सकता है, लेकिन दोनों को नहीं. यह एट्रिब्यूट मुख्य फ़ाइल फ़ोल्डर से जुड़ा लेबल है. फ़ाइल को WORKSPACE नाम देने की ज़रूरत नहीं है, लेकिन इसे नाम दिया जा सकता है. (Workspace.new-repo-name जैसी कोई चीज़, इसे रिपॉज़िटरी की असल WORKSPACE फ़ाइलों से अलग करने में अच्छी तरह काम कर सकती है.)
workspace_file_content	String; optional इस डेटा स्टोर करने की जगह के लिए WORKSPACE फ़ाइल का कॉन्टेंट. Workspace_file या Workspace_file_content में से किसी एक को तय किया जा सकता है, लेकिन दोनों को नहीं.