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

किसी समस्या की रिपोर्ट करें सोर्स देखें नाइटली · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

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

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

नियम

बाइंड

नियम का सोर्स देखें 
bind(name, actual, compatible_with, deprecation, distribs, features, licenses, restricted_to, tags, target_compatible_with, testonly, visibility)

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

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

//external पैकेज में किसी टारगेट को कोई दूसरा नाम देता है.

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

उदाहरण

किसी टारगेट को कोई दूसरा नाम देने के लिए, WORKSPACE फ़ाइल में जाकर, 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 पर निर्भर होंगी. इसके लिए, उनमें बदलाव करने की ज़रूरत नहीं होगी.

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

नाम; आवश्यक

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

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

वह टारगेट जिसका दूसरा नाम दिया जाना है.

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

अगर यह एट्रिब्यूट शामिल नहीं किया जाता है, तो //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

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

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

String; आवश्यक

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

यह उस डायरेक्ट्री का पाथ होना चाहिए जिसमें रिपॉज़िटरी की Workspace फ़ाइल का इस्तेमाल करता है. पाथ अपने-आप जनरेट होने वाले या मुख्य डेटा स्टोर करने की जगह के डेटा से मिलता-जुलता हो सकता है Workspace फ़ाइल का इस्तेमाल करता है.
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, workspace_file, workspace_file_content)

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

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

उदाहरण

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

उपयोगकर्ता, एसएसएल लाइब्रेरी के लिए बिल्ड फ़ाइल बनाकर, डिपेंडेंसी जोड़ सकता है (~/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.jar का इस्तेमाल करने के लिए @piano//:play-music पर निर्भर हो सकते हैं.

तर्क

विशेषताएं
name

नाम; आवश्यक

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

नाम; डिफ़ॉल्ट रूप से None है

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

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

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

String; "" डिफ़ॉल्ट है

इस रिपॉज़िटरी के लिए BUILD फ़ाइल का कॉन्टेंट.

campaign_file या create_file_content में से किसी एक को सेट करना ज़रूरी है.
path

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

लोकल फ़ाइल सिस्टम पर कोई पाथ.

यह डेटा स्टोर करने की मुख्य जगह की वर्कस्पेस फ़ाइल से मिलता-जुलता या उसके बारे में हो सकता है.
repo_mapping

डिक्शनरी: स्ट्रिंग -> स्ट्रिंग; डिफ़ॉल्ट तौर पर {}

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

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

workspace_file

नाम; डिफ़ॉल्ट तौर पर None

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

workspace_file या workspace_file_content में से किसी एक का इस्तेमाल किया जा सकता है, लेकिन दोनों का नहीं.

यह एट्रिब्यूट, मुख्य फ़ाइल फ़ोल्डर से जुड़ा लेबल है. फ़ाइल को का नाम WorkSPACE है, लेकिन इसे ऐसा किया जा सकता है. (कुछ ऐसा, जैसे कि WorkSPACE.new-repo-name इनके लिए अच्छा काम कर सकता है अलग से रिपोर्ट करना.)
workspace_file_content

String; "" डिफ़ॉल्ट है

इस डेटा स्टोर करने की जगह के लिए वर्कस्पेस फ़ाइल का कॉन्टेंट.

workspace_file या workspace_file_content में से किसी एक का इस्तेमाल किया जा सकता है, लेकिन दोनों का नहीं.