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

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

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

नियम

• बाइंड
• 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 का इस्तेमाल करना पड़ता है और इसके लिए बदलाव करने की ज़रूरत नहीं होती.

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

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)

किसी लोकल डायरेक्ट्री को 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 पर एक जार फ़ाइल थी. आपने लोगों तक पहुंचाया मुफ़्त में आपकी वर्कस्पेस फ़ाइल में नीचे दी गई चीज़ें जोड़कर, बस उस फ़ाइल को आपके बिल्ड में जोड़ा जा सकता है:

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