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