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

समस्या की शिकायत करें सोर्स देखें

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

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

नियम

• बाइंड करें
• 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 एट्रिब्यूट के इस्तेमाल पर विचार करें.

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

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

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

उदाहरण

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

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 पर निर्भर होंगी.

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

तर्क

विशेषताएं
name	नाम; ज़रूरी है इस टारगेट के लिए यूनीक नाम.
build_file	नाम; डिफ़ॉल्ट None है इस डायरेक्ट्री के लिए बिल्ड फ़ाइल के तौर पर इस्तेमाल की जाने वाली फ़ाइल. campaign_file या create_file_content में से किसी एक को सेट करना ज़रूरी है. यह एट्रिब्यूट, मुख्य फ़ाइल फ़ोल्डर से जुड़ा लेबल है. फ़ाइल का नाम BUILD होना ज़रूरी नहीं है, लेकिन ऐसा किया जा सकता है. (BUILD.new-repo-name जैसा कुछ इस तरह काम करता है कि इसे डेटा स्टोर करने की जगह की असली BUILD फ़ाइलों से अलग किया जा सकता है.)
build_file_content	स्ट्रिंग; डिफ़ॉल्ट तौर पर "" है इस डेटा स्टोर करने की जगह के लिए 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.new-repo-name इसे और रिपॉज़िटरी की असली वर्कस्पेस फ़ाइलों में अलग करे.)
workspace_file_content	स्ट्रिंग; डिफ़ॉल्ट तौर पर "" है इस डेटा स्टोर करने की जगह के लिए वर्कस्पेस फ़ाइल का कॉन्टेंट. Workspace_file या workspace_file_content में से किसी एक को तय किया जा सकता है, लेकिन दोनों को नहीं.