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