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

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.
किसी समस्या की शिकायत करें सोर्स देखें

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

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

नियम

बाइंड

नियम का सोर्स देखें
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 करें. उदाहरण के लिए, मान लें कि java_library टारगेट, //third_party/javacc-v2 है. इन्हें 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 पर निर्भर होंगी.

आपके फ़ाइल फ़ोल्डर के लिए उपलब्ध डेटा स्टोर करने की जगह में, टारगेट को उपलब्ध कराने के लिए भी Bind का इस्तेमाल किया जा सकता है. उदाहरण के लिए, अगर @my-ssl नाम का एक रिमोट रिपॉज़िटरी (डेटा स्टोर करने की जगह) @my-ssl है, जो WORKSPACE में मौजूद फ़ाइल में इंपोर्ट किया गया है और उसके पास 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(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" (जैसे कि "@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 डेटा स्टोर करने की जगह में बदला जा सकता है. इसका मतलब है कि डेटा स्टोर करने की मौजूदा जगह फ़ाइल सिस्टम में कहीं से भी टारगेट तय कर सकती है और उनका इस्तेमाल कर सकती है.

यह नियम एक WORKSPACE फ़ाइल और सबडायरेक्ट्री बनाकर, दिए गए 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.jam पर एक जार फ़ाइल थी. आप अपनी 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 फ़ाइल का कॉन्टेंट.

build_file या build_file_content की जानकारी देना ज़रूरी है.

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 की जानकारी दी जा सकती है, लेकिन दोनों को नहीं.