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

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

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

नियम

• bind
• local_repository
• new_local_repository

बाइंड

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

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

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

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

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

उदाहरण

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

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

अब टारगेट, इसके बजाय //external:javacc-latest पर निर्भर हो सकते हैं //third_party/javacc-v2. अगर 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 में रूट किया गया है. इसे ऐसी एसएसएल लाइब्रेरी का इस्तेमाल करना है जिसे किसी दूसरी रिपॉज़िटरी: ~/ssl में तय किया गया है. एसएसएल लाइब्रेरी में टारगेट //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" पर निर्भर करता है, तो उसे ग्लोबल तौर पर बताए गए "@bar" ("@bar//some:target") में उस डिपेंडेंसी को हल करना चाहिए. जैसे, "@foo//some:target" पर डिपेंडेंसी.

new_local_repository

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

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

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

उदाहरण

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

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

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

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

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_file या build_file_content में से किसी एक की जानकारी देना ज़रूरी है. यह एट्रिब्यूट, मुख्य फ़ाइल फ़ोल्डर से जुड़ा लेबल है. फ़ाइल को BUILD नाम का इस्तेमाल किया जाता है, लेकिन इसे बनाया भी जा सकता है. (BUILD.new-repo-name जैसा कुछ, इसे रिपॉज़िटरी की असल BUILD फ़ाइलों से अलग करने के लिए काम कर सकता है.)
build_file_content	String; optional इस डेटा स्टोर करने की जगह के लिए BUILD फ़ाइल का कॉन्टेंट. campaign_file या create_file_content में से किसी एक को सेट करना ज़रूरी है.
path	String; required लोकल फ़ाइल सिस्टम पर मौजूद पाथ. यह डेटा स्टोर करने की मुख्य जगह की वर्कस्पेस फ़ाइल से मिलता-जुलता या उसके बारे में हो सकता है.
repo_mapping	Dictionary: String -> String; optional लोकल डेटा स्टोर करने की जगह के नाम से ग्लोबल डेटा स्टोर करने की जगह के नाम की डिक्शनरी. इससे आपको इन चीज़ों को कंट्रोल करने में मदद मिलेगी इस रिपॉज़िटरी की डिपेंडेंसी के लिए वर्कस्पेस डिपेंडेंसी का रिज़ॉल्यूशन. उदाहरण के लिए, "@foo": "@bar" एंट्री से पता चलता है कि जब भी यह रिपॉज़िटरी "@foo" पर निर्भर करता है, तो उसे ग्लोबल तौर पर बताए गए "@bar" ("@bar//some:target") में उस डिपेंडेंसी को हल करना चाहिए. जैसे, "@foo//some:target" पर डिपेंडेंसी.
workspace_file	String; optional इस डेटा स्टोर करने की जगह के लिए Workspace फ़ाइल के रूप में इस्तेमाल की जाने वाली फ़ाइल. workspace_file या workspace_file_content में से किसी एक की वैल्यू दी जा सकती है, लेकिन दोनों की नहीं. यह एट्रिब्यूट, मुख्य फ़ाइल फ़ोल्डर से जुड़ा लेबल होता है. फ़ाइल को का नाम WorkSPACE है, लेकिन इसे ऐसा किया जा सकता है. (कुछ ऐसा, जैसे कि WorkSPACE.new-repo-name इनके लिए अच्छा काम कर सकता है अलग से रिपोर्ट करना.)
workspace_file_content	String; optional इस डेटा स्टोर करने की जगह के लिए वर्कस्पेस फ़ाइल का कॉन्टेंट. Workspace_file या workspace_file_content में से किसी एक को तय किया जा सकता है, लेकिन दोनों को नहीं.