Workspace के नियमों का इस्तेमाल, बाहरी डिपेंडेंसी पाने के लिए किया जाता है. आम तौर पर, यह सोर्स कोड मुख्य रिपॉज़िटरी के बाहर मौजूद होता है.
ध्यान दें: नेटिव वर्कस्पेस के नियमों के अलावा, Bazel कई Starlark के फ़ाइल फ़ोल्डर के नियमों को भी जोड़ता है. खास तौर पर, इससे वे गिट के डेटा स्टोर करने की जगहों या वेब पर होस्ट किए गए संग्रह के नियमों का पता लगाते हैं.
नियम
bind
bind(name, actual, compatible_with, deprecation, distribs, features, licenses, restricted_to, tags, target_compatible_with, testonly, visibility)
चेतावनी: bind()
इस्तेमाल करने का सुझाव नहीं दिया जाता. इसकी समस्याओं और इसके विकल्पों के बारे में
लंबी चर्चा के लिए, "बाइंड हटाने की कोशिश करें" देखें. खास तौर पर, repo_mapping
डेटा स्टोर करने की जगह के एट्रिब्यूट के इस्तेमाल पर ध्यान दें.
चेतावनी: select()
का इस्तेमाल bind()
में नहीं किया जा सकता. ज़्यादा जानकारी के लिए, कॉन्फ़िगर किए जा सकने वाले एट्रिब्यूट के बारे में अक्सर पूछे जाने वाले सवाल देखें.
//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 डायरेक्ट्री पर रूट किया गया है. वह
एसएसएल लाइब्रेरी का इस्तेमाल करना चाहता है, जो किसी अलग रिपॉज़िटरी (डेटा स्टोर करने की जगह) में दी गई है: ~/एसएसएल. एसएसएल
लाइब्रेरी में टारगेट //src:openssl-lib
है.
उपयोगकर्ता ~/chat-app/WorkSPACE में ये लाइनें जोड़कर, इस टारगेट पर डिपेंडेंसी जोड़ सकता है:
local_repository( name = "my-ssl", path = "/home/user/ssl", )
टारगेट, इस लाइब्रेरी पर निर्भर होने के लिए @my-ssl//src:openssl-lib
को डिपेंडेंसी के तौर पर तय करेंगे.
तर्क
एट्रिब्यूट | |
---|---|
name |
इस टारगेट के लिए यूनीक नाम. |
path
|
यह उस डायरेक्ट्री का पाथ होना चाहिए जिसमें डेटा स्टोर करने की जगह की Workspace फ़ाइल मौजूद है. पाथ, डेटा स्टोर करने की मुख्य जगह की SPACESPACE फ़ाइल का ऐब्सलूट या रिलेटिव हो सकता है. |
repo_mapping
|
उदाहरण के लिए, |
new_local_repository
new_local_repository(name, build_file, build_file_content, path, repo_mapping, workspace_file, workspace_file_content)
इससे किसी लोकल डायरेक्ट्री को Bazel डेटा स्टोर करने की जगह में बदलने की अनुमति मिलती है. इसका मतलब है कि मौजूदा रिपॉज़िटरी, फ़ाइल सिस्टम में कहीं से भी टारगेट को तय और इस्तेमाल कर सकता है.
यह नियम एक ऐसी PHONESPACE फ़ाइल और सबडायरेक्ट्री बनाकर Bazel डेटा स्टोर करता है जिसमें BUILD फ़ाइल और दिए गए पाथ के सिमलिंक होते हैं. बिल्ड फ़ाइल को path
से मिलते-जुलते टारगेट बनाने चाहिए. जिन डायरेक्ट्री में पहले से ही वर्कSPACE फ़ाइल और BUILD फ़ाइल है, उनके लिए local_repository
नियम का इस्तेमाल किया जा सकता है.
उदाहरण
मान लीजिए कि मौजूदा डेटा स्टोर करने की जगह एक चैट क्लाइंट है, जो ~/chat-app डायरेक्ट्री पर रूट किया गया है. वह एसएसएल लाइब्रेरी का इस्तेमाल करना चाहता है, जिसकी जानकारी किसी दूसरी डायरेक्ट्री में दी गई है: ~/एसएसएल.
उपयोगकर्ता उस एसएसएल लाइब्रेरी (~/chat-app/BUILD.my-एसएसएल) के लिए BUILD फ़ाइल बनाकर, डिपेंडेंसी जोड़ सकता है, जिसमें ये चीज़ें शामिल हों:
java_library( name = "openssl", srcs = glob(['*.java']) visibility = ["//visibility:public"], )
इसके बाद, वह ~/chat-app/WorkspaceSPACE में ये लाइनें जोड़ सकता है:
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
|
बिल्ड_फ़ाइल या बिल्ड_फ़ाइल_कॉन्टेंट से जुड़ी जानकारी देना ज़रूरी है. यह एट्रिब्यूट मुख्य फ़ाइल फ़ोल्डर से जुड़ा लेबल है. फ़ाइल को BUILD नाम देने की ज़रूरत नहीं है, लेकिन ऐसा किया जा सकता है. (BUILD.new-repo-name जैसी कुछ चीज़ें, इसे रिपॉज़िटरी की असली BUILD फ़ाइलों से अलग करने में अच्छी तरह से काम कर सकती हैं.) |
build_file_content
|
बिल्ड_फ़ाइल या बिल्ड_फ़ाइल_कॉन्टेंट से जुड़ी जानकारी देना ज़रूरी है. |
path
|
यह काफ़ी हद तक डेटा स्टोर करने की जगह की मुख्य जगह की SPACESPACE फ़ाइल से मिलता-जुलता या पूरा डेटा हो सकता है. |
repo_mapping
|
उदाहरण के लिए, |
workspace_file
|
Workspace_file या Workspace_file_content में से किसी एक को तय किया जा सकता है, लेकिन दोनों को नहीं. यह एट्रिब्यूट मुख्य फ़ाइल फ़ोल्डर से जुड़ा लेबल है. फ़ाइल को 'काम करने की जगह' नाम देने की ज़रूरत नहीं है, लेकिन यह नाम दिया जा सकता है. (इसे डेटा स्टोर करने की जगह की असल वर्कस्पेस फ़ाइलों से अलग करने के लिए, वर्कSPACE.new-repo-name जैसा कुछ इस्तेमाल किया जा सकता है.) |
workspace_file_content
|
Workspace_file या Workspace_file_content में से किसी एक को तय किया जा सकता है, लेकिन दोनों को नहीं. |