फ़ाइल फ़ोल्डर के नियमों का इस्तेमाल बाहरी डिपेंडेंसी पाने के लिए किया जाता है. आम तौर पर, यह मुख्य रिपॉज़िटरी के बाहर मौजूद सोर्स कोड होता है.
ध्यान दें: फ़ाइल फ़ोल्डर के नेटिव नियमों के अलावा, Bazel कई Starlark के फ़ाइल फ़ोल्डर के नियमों को भी एम्बेड करता है. खास तौर पर, वे नियम, जो वेब पर होस्ट किए गए git डेटा स्टोर करने की जगहों या आर्काइव से जुड़े होते हैं.
नियम
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 फ़ाइल मौजूद है. पाथ, मुख्य रिपॉज़िटरी (डेटा स्टोर करने की जगह) की Workspace फ़ाइल से जुड़ा हो सकता है या उससे जुड़ा हो सकता है. |
repo_mapping
|
उदाहरण के लिए, |
new_local_repository
new_local_repository(name, build_file, build_file_content, path, repo_mapping, workspace_file, workspace_file_content)
इससे किसी लोकल डायरेक्ट्री को Bazel का डेटा स्टोर करने की अनुमति मिलती है. इसका मतलब है कि डेटा स्टोर करने की मौजूदा जगह, फ़ाइल सिस्टम में कहीं से भी टारगेट को तय कर सकती है और उनका इस्तेमाल कर सकती है.
यह नियम एक वर्कSPACE फ़ाइल और सबडायरेक्ट्री बनाकर, Bazel रिपॉज़िटरी बनाता है,
जिसमें BUILD फ़ाइल और दिए गए पाथ के सिमलिंक होते हैं. बिल्ड फ़ाइल को path
से जुड़े टारगेट बनाने चाहिए. जिन डायरेक्ट्री में पहले से ही WORKSPACE फ़ाइल और BUILD फ़ाइल मौजूद है, उनके लिए
local_repository
नियम का इस्तेमाल किया जा सकता है.
उदाहरण
मान लीजिए कि मौजूदा डेटा स्टोर करने की जगह एक चैट क्लाइंट है, जिसे ~/chat-app डायरेक्ट्री पर रूट किया गया है. वह एक ऐसी एसएसएल लाइब्रेरी का इस्तेमाल करना चाहता है जिसकी जानकारी किसी दूसरी डायरेक्ट्री में दी गई है: ~/एसएसएल.
उपयोगकर्ता उस एसएसएल लाइब्रेरी (~/chat-app/BUILD.my-एसएसएल) के लिए, BUILD फ़ाइल बनाकर डिपेंडेंसी जोड़ सकता है, जिसमें यह शामिल हो:
java_library( name = "openssl", srcs = glob(['*.java']) visibility = ["//visibility:public"], )
इसके बाद, वह ~/chat-app/वर्कस्पेस में ये लाइनें जोड़ सकता है:
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
|
बिल्ड_फ़ाइल या बिल्ड_फ़ाइल_कॉन्टेंट से जुड़ी जानकारी देना ज़रूरी है. यह एट्रिब्यूट मुख्य फ़ाइल फ़ोल्डर से जुड़ा लेबल है. फ़ाइल को BUILD नाम देने की ज़रूरत नहीं है, लेकिन इसे नाम दिया जा सकता है. (BUILD.new-repo-name जैसी कोई चीज़, इसे रिपॉज़िटरी की असल BUILD फ़ाइलों से अलग करने में अच्छी तरह काम कर सकती है.) |
build_file_content
|
बिल्ड_फ़ाइल या बिल्ड_फ़ाइल_कॉन्टेंट से जुड़ी जानकारी देना ज़रूरी है. |
path
|
यह डेटा रिपॉज़िटरी की मुख्य फ़ाइल की WORKSPACE फ़ाइल से जुड़ा हो सकता है या यह बिलकुल सही हो सकता है. |
repo_mapping
|
उदाहरण के लिए, |
workspace_file
|
Workspace_file या Workspace_file_content में से किसी एक को तय किया जा सकता है, लेकिन दोनों को नहीं. यह एट्रिब्यूट मुख्य फ़ाइल फ़ोल्डर से जुड़ा लेबल है. फ़ाइल को WORKSPACE नाम देने की ज़रूरत नहीं है, लेकिन इसे नाम दिया जा सकता है. (Workspace.new-repo-name जैसी कोई चीज़, इसे रिपॉज़िटरी की असल WORKSPACE फ़ाइलों से अलग करने में अच्छी तरह काम कर सकती है.) |
workspace_file_content
|
Workspace_file या Workspace_file_content में से किसी एक को तय किया जा सकता है, लेकिन दोनों को नहीं. |