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