फ़ाइल फ़ोल्डर के नियम

Workspace के नियमों का इस्तेमाल, बाहरी डिपेंडेंसी को पुल करने के लिए किया जाता है. आम तौर पर, यह सोर्स कोड मुख्य रिपॉज़िटरी के बाहर मौजूद होता है.

ध्यान दें: Bazel, नेटिव वर्कस्पेस के नियमों के अलावा, कई Starlark वर्कस्पेस के नियम भी एम्बेड करता है. खास तौर पर, वेब पर होस्ट की गई git रिपॉज़िटरी या संग्रहों से निपटने के लिए.

नियम

• bind
• local_repository
• new_local_repository

बाइंड

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 पर निर्भर होंगी. इसके लिए, उन्हें बदलने की ज़रूरत नहीं होगी.

बाइंड का इस्तेमाल, बाहरी रिपॉज़िटरी में मौजूद टारगेट को आपके वर्कस्पेस के लिए उपलब्ध कराने के लिए भी किया जा सकता है. उदाहरण के लिए, अगर 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"

तर्क

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 को डिपेंडेंसी के तौर पर तय करेंगे.

तर्क

new_local_repository

new_local_repository(name, build_file, build_file_content, path, repo_mapping, workspace_file, workspace_file_content)

इस विकल्प की मदद से, किसी लोकल डायरेक्ट्री को Bazel रिपॉज़िटरी में बदला जा सकता है. इसका मतलब है कि मौजूदा रिपॉज़िटरी, फ़ाइल सिस्टम में किसी भी जगह से टारगेट तय कर सकती है और उनका इस्तेमाल कर सकती है.

यह नियम, WORKSPACE फ़ाइल और दी गई BUILD फ़ाइल और पाथ के सिंबल लिंक वाली सबडायरेक्ट्री बनाकर, Bazel रिपॉज़िटरी बनाता है. बिल्ड फ़ाइल को path के हिसाब से टारगेट बनाने चाहिए. जिन डायरेक्ट्री में पहले से ही WORKSPACE फ़ाइल और BUILD फ़ाइल मौजूद है उनके लिए, local_repository नियम का इस्तेमाल किया जा सकता है.

उदाहरण

मान लें कि मौजूदा रिपॉज़िटरी एक चैट क्लाइंट है, जो ~/chat-app डायरेक्ट्री में मौजूद है. इसे किसी दूसरी डायरेक्ट्री ~/ssl में मौजूद एसएसएल लाइब्रेरी का इस्तेमाल करना है.

उपयोगकर्ता, 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.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"],
)

तर्क