BazelCon 2022, 16 नवंबर से 17 नवंबर तक न्यूयॉर्क में और ऑनलाइन उपलब्ध है.
आज ही रजिस्टर करें!

Workspace के नियम

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

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

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

नियम

बाइंड

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",
)

इसके बाद, आपके फ़ाइल फ़ोल्डर में बिल्ड फ़ाइल में, बाउंड टारगेट का इस्तेमाल इस तरह किया जा सकता है:

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

Name; required

इस टारगेट के लिए कोई यूनीक नाम.

actual

Label; optional

टारगेट किया जाने वाला टारगेट.

यह टारगेट मौजूद होना चाहिए, लेकिन किसी भी तरह का नियम (बाइंडिंग के साथ) हो सकता है.

अगर इस एट्रिब्यूट को शामिल नहीं किया जाता है, तो //external में इस टारगेट के बारे में बताने वाले नियमों को यह डिपेंडेंसी किनारा नहीं दिखेगा. ध्यान रखें कि यह bind नियम को पूरी तरह से हटाने से अलग है: अगर //external डिपेंडेंसी में कोई bind नियम मौजूद नहीं है, तो यह गड़बड़ी होती है.

local_repository

local_repository(name, path, repo_mapping)

किसी स्थानीय डायरेक्ट्री के टारगेट को अनुमति देता है. इसका मतलब है कि मौजूदा डेटा संग्रह स्थान इस दूसरी डायरेक्ट्री में तय किए गए टारगेट का इस्तेमाल कर सकता है. ज़्यादा जानकारी के लिए, बाइंड सेक्शन देखें.

उदाहरण

मान लीजिए कि मौजूदा डेटा स्टोर करने की जगह, चैट क्लाइंट है, जो ~/chat-app डायरेक्ट्री पर है. यह किसी ऐसी एसएसएल लाइब्रेरी का इस्तेमाल करना चाहता है जिसे किसी अलग रिपॉज़िटरी (डेटा स्टोर की जगह) में बताया गया हो: ~/ssl. SSL लाइब्रेरी का टारगेट //src:openssl-lib है.

उपयोगकर्ता ~/chat-app/WORKSPACE में ये लाइनें जोड़कर इस टारगेट पर निर्भरता जोड़ सकता है:

local_repository(
    name = "my-ssl",
    path = "/home/user/ssl",
)

इस लाइब्रेरी पर निर्भर करने के लिए, टारगेट @my-ssl//src:openssl-lib एक निर्भरता के तौर पर तय करेंगे.

तर्क

विशेषताएं
name

Name; required

इस टारगेट के लिए कोई यूनीक नाम.

path

String; required

डेटा स्टोर करने की स्थानीय डायरेक्ट्री का पाथ.

यह उस डायरेक्ट्री का पाथ होना चाहिए जिसमें रिपॉज़िटरी की WORKSPACE फ़ाइल हो. पाथ या तो मुख्य रिपॉज़िटरी की WORKSPACE फ़ाइल से मिलता-जुलता हो सकता है या बिल्कुल सही हो सकता है.

repo_mapping

Dictionary: String -> String; optional

डेटा स्टोर करने की जगह के स्थानीय नाम से दुनिया भर की डेटा स्टोर करने की जगह के नाम का शब्दकोश. इससे इस रिपॉज़िटरी पर निर्भर करने के लिए, फ़ाइल फ़ोल्डर के डिपेंडेंसी रिज़ॉल्यूशन पर कंट्रोल की अनुमति मिलती है.

उदाहरण के लिए, "@foo": "@bar" एलान करता है कि डेटा स्टोर करने की यह जगह, किसी भी समय"@foo" (जैसे कि"@foo//some:target" ), इसे दुनिया भर में बताए गए तरीके से उस डिपेंडेंसी को असल में हल करना चाहिए"@bar" ("@bar//some:target" ).

new_local_repository

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

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

यह नियम एक WorkSPACE फ़ाइल और सबडायरेक्ट्री बनाने के लिए एक Bazel डेटा स्टोर करने की जगह बनाता है. इस फ़ाइल में दिए गए बिल्ड फ़ाइल और पाथ के सिमलिंक होते हैं. बिल्ड फ़ाइल को path से मिलते-जुलते टारगेट बनाने चाहिए. जिन डायरेक्ट्री में पहले से ही WORKSPACE फ़ाइल और Build फ़ाइल है उनके लिए, local_repository नियम का इस्तेमाल किया जा सकता है.

उदाहरण

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

उपयोगकर्ता, एसएसएल लाइब्रेरी के लिए एक बिल्ड फ़ाइल बनाकर एक डिपेंडेंसी जोड़ सकता है. इसमें (~/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/Download/piao.jar पर एक जार फ़ाइल थी. आप अपनी WORKSPACE फ़ाइल में ये चीज़ें जोड़कर सिर्फ़ उस फ़ाइल को अपने बिल्ड में जोड़ सकते हैं:

new_local_repository(
    name = "piano",
    path = "/home/username/Downloads/piano.jar",
    build_file = "BUILD.piano",
)

और नीचे दी गई Build.pian फ़ाइल बनाना:

java_import(
    name = "play-music",
    jars = ["piano.jar"],
    visibility = ["//visibility:public"],
)
फिर पियानो पर जार का इस्तेमाल करने के लिए, टारगेट @piano//:play-music पर निर्भर हो सकते हैं.

तर्क

विशेषताएं
name

Name; required

इस टारगेट के लिए कोई यूनीक नाम.

build_file

String; optional

इस निर्देशिका के लिए बिल्ड फ़ाइल के रूप में उपयोग करने के लिए फ़ाइल.

बिल्ड_फ़ाइल या build_file_content में जानकारी देना ज़रूरी है.

यह विशेषता मुख्य फ़ाइल फ़ोल्डर से जुड़ा लेबल है. फ़ाइल को अनुमति का नाम बताने की ज़रूरत नहीं है, लेकिन ऐसा हो सकता है. (कुछ तरह के CREATED

build_file_content

String; optional

इस डेटा स्टोर करने की जगह के लिए Build फ़ाइल का कॉन्टेंट.

बिल्ड_फ़ाइल या build_file_content में जानकारी देना ज़रूरी है.

path

String; required

लोकल फ़ाइल सिस्टम का पाथ.

यह या तो निरपेक्ष हो सकता है या मुख्य डेटा संग्रह स्थान की WORKSPACE फ़ाइल से संबंधित हो सकता है.

repo_mapping

Dictionary: String -> String; optional

डेटा स्टोर करने की जगह के स्थानीय नाम से दुनिया भर की डेटा स्टोर करने की जगह के नाम का शब्दकोश. इससे इस रिपॉज़िटरी पर निर्भर करने के लिए, फ़ाइल फ़ोल्डर के डिपेंडेंसी रिज़ॉल्यूशन पर कंट्रोल की अनुमति मिलती है.

उदाहरण के लिए, "@foo": "@bar" एलान करता है कि डेटा स्टोर करने की यह जगह, किसी भी समय"@foo" (जैसे कि"@foo//some:target" ), इसे दुनिया भर में बताए गए तरीके से उस डिपेंडेंसी को असल में हल करना चाहिए"@bar" ("@bar//some:target" ).

workspace_file

String; optional

इस डेटा स्टोर करने की जगह के लिए WORKSPACE फ़ाइल के रूप में इस्तेमाल करने के लिए फ़ाइल.

Workspace_file या Workspace_file_content के बारे में बताया जा सकता है, लेकिन दोनों नहीं.

यह विशेषता मुख्य फ़ाइल फ़ोल्डर से जुड़ा लेबल है. फ़ाइल को WORKSPACE के नाम की ज़रूरत नहीं है, लेकिन ऐसा हो सकता है. (WORKSPACE.new-repo-name जैसी कुछ चीज़ें इसके लिए अच्छी तरह से काम कर सकती हैं कि ये डेटा स्टोर करने वाली जगह की असली WORKSPACE फ़ाइलों से अलग हों.)

workspace_file_content

String; optional

इस डेटा स्टोर करने की जगह के लिए WORKSPACE फ़ाइल का कॉन्टेंट.

Workspace_file या Workspace_file_content के बारे में बताया जा सकता है, लेकिन दोनों नहीं.