बाहरी डिपेंडेंसी के साथ काम करना

Baज़ल, दूसरे प्रोजेक्ट के टारगेट पर निर्भर हो सकता है. इन अन्य से डिपेंडेंसी प्रोजेक्ट को बाहरी डिपेंडेंसी कहा जाता है.

इसमें WORKSPACE फ़ाइल (या WORKSPACE.bazel फ़ाइल) वर्कस्पेस डायरेक्ट्री बेज़ल को बताता है कि दूसरे प्रोजेक्ट कैसे हासिल किए जाएं' स्रोत. ये दूसरे प्रोजेक्ट, उसके अपने टारगेट वाली एक या ज़्यादा BUILD फ़ाइलें होनी चाहिए. इसके अंदर BUILD फ़ाइलें मुख्य प्रोजेक्ट, इन बाहरी टारगेट पर निर्भर करता है. इसके लिए, WORKSPACE फ़ाइल.

उदाहरण के लिए, मान लें कि किसी सिस्टम पर दो प्रोजेक्ट हैं:

/
  home/
    user/
      project1/
        WORKSPACE
        BUILD
        srcs/
          ...
      project2/
        WORKSPACE
        BUILD
        my-libs/

अगर project1 किसी टारगेट पर निर्भर होना चाहता था, तो :foo, इसमें परिभाषित किया गया है /home/user/project2/BUILD, यह तय कर सकता है कि रिपॉज़िटरी का नाम project2, /home/user/project2 पर मिल सकता है. फिर /home/user/project1/BUILD, @project2//:foo पर निर्भर हो सकता है.

WORKSPACE फ़ाइल की मदद से, उपयोगकर्ता फ़ाइल सिस्टम या इंटरनेट से डाउनलोड किया गया हो. यह उसी सिंटैक्स का इस्तेमाल करता है जो BUILD फ़ाइल है, लेकिन नियमों के एक अलग सेट की अनुमति देता है, जिसे डेटा स्टोर करने के नियम कहा जाता है (कभी-कभी इसे फ़ाइल फ़ोल्डर के नियम भी कहा जाता है). Basel का स्टोर करने की सुविधा, कुछ पहले से मौजूद रिपॉज़िटरी (डेटा स्टोर करने की जगह) के साथ मिलती है नियम और एम्बेड किए गए Starlark डेटा स्टोर करने की जगह का सेट नियम पढ़ें. उपयोगकर्ता, कस्टम डेटा स्टोर करने की जगह भी लिख सकते हैं नियमों का पालन करें.

बाहरी डिपेंडेंसी के साथ काम करने वाले टाइप

बाहरी डिपेंडेंसी के कुछ बुनियादी टाइप इस्तेमाल किए जा सकते हैं:

• अन्य Basel प्रोजेक्ट पर डिपेंडेंसी
• नॉन-बेज़ल प्रोजेक्ट पर डिपेंडेंसी
• बाहरी पैकेज पर निर्भरता

अन्य Basel प्रोजेक्ट के आधार पर

अगर आपको दूसरे Bagel प्रोजेक्ट के टारगेट का इस्तेमाल करना है, तो इस्तेमाल local_repository git_repository या http_archive इसे लोकल फ़ाइल सिस्टम से सिमलिंक करने के लिए, git रिपॉज़िटरी का रेफ़रंस दें या डाउनलोड करें इसे (क्रमिक रूप से).

उदाहरण के लिए, मान लें कि आप किसी प्रोजेक्ट my-project/ पर काम कर रहे हैं और आपको आपके सहकर्मी के प्रोजेक्ट, coworkers-project/ के टारगेट पर निर्भर रहने के लिए किया जा सकता है. दोनों का इस्तेमाल किया जा सकता है. इसलिए, अपने सहकर्मी के प्रोजेक्ट को निर्भर करता है और फिर आपके सहकर्मी द्वारा अपने आप तय किए गए किसी लक्ष्य का उपयोग करता है फ़ाइलें बनाएं. आपको my_project/WORKSPACE में यह जोड़ना होगा:

local_repository(
    name = "coworkers_project",
    path = "/path/to/coworkers-project",
)

अगर आपके सहकर्मी के पास टारगेट //foo:bar है, तो आपका प्रोजेक्ट इसका रेफ़रंस इस तौर पर दे सकता है: @coworkers_project//foo:bar. एक्सटर्नल प्रोजेक्ट नाम फ़ाइल फ़ोल्डर के मान्य नाम होने चाहिए.

नॉन-बेज़ल प्रोजेक्ट के आधार पर

नियम से पहले new_ जुड़ा हुआ है, जैसे new_local_repository, आपको ऐसे प्रोजेक्ट से टारगेट करने की सुविधा मिलती है जो Basel का इस्तेमाल नहीं करते हैं.

उदाहरण के लिए, मान लें कि आप किसी प्रोजेक्ट my-project/ पर काम कर रहे हैं और आपको अपने सहकर्मी के प्रोजेक्ट, coworkers-project/ पर निर्भर रहेगा. आपके सहकर्मी का प्रोजेक्ट बनाने के लिए make का इस्तेमाल करता है, लेकिन आपको .so फ़ाइलों में से किसी एक पर निर्भर रहना होगा तो जनरेट होता है. ऐसा करने के लिए, my_project/WORKSPACE में यह जोड़ें:

new_local_repository(
    name = "coworkers_project",
    path = "/path/to/coworkers-project",
    build_file = "coworker.BUILD",
)

build_file एक BUILD फ़ाइल तय करता है, जिसे मौजूदा प्रोजेक्ट पर ओवरले किया जा सकता है उदाहरण:

cc_library(
    name = "some-lib",
    srcs = glob(["**"]),
    visibility = ["//visibility:public"],
)

इसके बाद, आप अपने प्रोजेक्ट के @coworkers_project//:some-lib पर निर्भर रह सकते हैं BUILD फ़ाइलें.

बाहरी पैकेज के हिसाब से

Maven आर्टफ़ैक्ट और डेटा स्टोर करने की जगहें

नियमसेट का इस्तेमाल करें rules_jvm_external Maven रिपॉज़िटरी से आर्टफ़ैक्ट डाउनलोड करने और उन्हें Java के तौर पर उपलब्ध कराने के लिए निर्भरता.

डिपेंडेंसी फ़ेच की जा रही है

डिफ़ॉल्ट रूप से, bazel build के दौरान ज़रूरत के मुताबिक बाहरी डिपेंडेंसी फ़ेच की जाती हैं. अगर आपने आपको टारगेट के किसी खास सेट के लिए ज़रूरी डिपेंडेंसी को प्रीफ़ेच करना है, तो इसका इस्तेमाल करें bazel fetch. सभी बाहरी डिपेंडेंसी को बिना किसी शर्त के फ़ेच करने के लिए, इसका इस्तेमाल करें bazel sync. फ़ेच किए गए डेटा स्टोर करने की जगहों को आउटपुट बेस में सेव किया जाता है, इसलिए फ़ेच किया जा रहा है हर वर्कस्पेस में होता है.

शैडोइंग डिपेंडेंसी

हमारा सुझाव है कि जब भी मुमकिन हो, अपने रिपोर्ट में एक वर्शन नीति का इस्तेमाल करें प्रोजेक्ट. यह उन डिपेंडेंसी के लिए ज़रूरी है जिन्हें आप कंपाइल करके रखते हैं और खत्म करते हैं तय करें. हालाँकि, उन मामलों में जहां यह सही नहीं है, वहां ऐसा किया जा सकता है शैडो डिपेंडेंसी. यह उदाहरण देखें:

मेरा प्रोजेक्ट/वर्कस्पेस

workspace(name = "myproject")

local_repository(
    name = "A",
    path = "../A",
)
local_repository(
    name = "B",
    path = "../B",
)

A/वर्कस्पेस

workspace(name = "A")

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
    name = "testrunner",
    urls = ["https://github.com/testrunner/v1.zip"],
    sha256 = "...",
)

बी/वर्कस्पेस

workspace(name = "B")

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
    name = "testrunner",
    urls = ["https://github.com/testrunner/v2.zip"],
    sha256 = "..."
)

A और B, दोनों डिपेंडेंसी, testrunner पर निर्भर करती हैं. हालांकि, ये इन पर निर्भर करती हैं testrunner के विभिन्न वर्शन हैं. जांच करने वाले इन लोगों के लिए, ऐसा करने की कोई ज़रूरत नहीं है myproject में शांति से नहीं रहते. हालांकि, वे दोनों के साथ झगड़ेंगे क्योंकि उनके नाम एक जैसे हैं. दोनों डिपेंडेंसी के बारे में बताने के लिए, मेरा प्रोजेक्ट/वर्कस्पेस अपडेट करें:

workspace(name = "myproject")

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
    name = "testrunner-v1",
    urls = ["https://github.com/testrunner/v1.zip"],
    sha256 = "..."
)
http_archive(
    name = "testrunner-v2",
    urls = ["https://github.com/testrunner/v2.zip"],
    sha256 = "..."
)
local_repository(
    name = "A",
    path = "../A",
    repo_mapping = {"@testrunner" : "@testrunner-v1"}
)
local_repository(
    name = "B",
    path = "../B",
    repo_mapping = {"@testrunner" : "@testrunner-v2"}
)

हीरे जोड़ने के लिए भी इस तरीके का इस्तेमाल किया जा सकता है. उदाहरण के लिए, अगर A और B एक ही डिपेंडेंसी थी, लेकिन उसे अलग-अलग नामों से कॉल किया. ये डिपेंडेंसी मेरे प्रोजेक्ट/वर्कस्पेस में शामिल हो सकते हैं.

कमांड लाइन से डेटा स्टोर करने की जगहों को बदलना

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

उदाहरण के लिए, @foo को लोकल डायरेक्ट्री /path/to/local/foo में बदलने के लिए, --override_repository=foo=/path/to/local/foo फ़्लैग को पास करें.

इसके कुछ इस्तेमाल के उदाहरण यहां दिए गए हैं:

• डीबग करने से जुड़ी समस्याएं. उदाहरण के लिए, http_archive डेटा स्टोर करने की जगह को बदला जा सकता है में बदलाव कर सकते हैं.
• वेंडरिंग. अगर आप किसी ऐसे माहौल में हैं जहां आप नेटवर्क कॉल नहीं कर सकते, लोकल डायरेक्ट्री पर ले जाने के लिए, नेटवर्क पर आधारित डेटा स्टोर करने की जगह के नियमों को ओवरराइड करें आज़माएं.

प्रॉक्सी का इस्तेमाल करना

Baज़र, HTTPS_PROXY और HTTP_PROXY से प्रॉक्सी पते इस्तेमाल करेगा एनवायरमेंट वैरिएबल का इस्तेमाल करें और इनका इस्तेमाल एचटीटीपी/एचटीटीपीएस फ़ाइलों (अगर बताया गया है) को डाउनलोड करने के लिए करें.

आईपीवी6 के साथ काम करने की सुविधा

सिर्फ़ आईपीवी6 मशीनों पर, Basel, कोई बदलाव नहीं. हालांकि, ड्यूअल-स्टैक IPv4/IPv6 मशीनों पर, Basel का तरीका नीचे दिया गया है Java के तौर पर कंवेंशन: अगर IPv4 चालू है, तो IPv4 को प्राथमिकता दी जाती है. कुछ स्थितियों में, उदाहरण के लिए, जब आईपीवी4 नेटवर्क बाहरी पतों को ठीक नहीं कर पाता या उन तक नहीं पहुंच पाता, इससे Network unreachable अपवाद हो सकते हैं और बिल्ड फ़ेल हो सकता है. ऐसे मामलों में, आईपीवी6 को प्राथमिकता देने के लिए, बेज़ल का व्यवहार बदला जा सकता है java.net.preferIPv6Addresses=true सिस्टम प्रॉपर्टी का इस्तेमाल करके. खास तौर पर:

• --host_jvm_args=-Djava.net.preferIPv6Addresses=true का इस्तेमाल करें स्टार्टअप विकल्प, उदाहरण के लिए, अपने .bazelrc फ़ाइल:

  startup --host_jvm_args=-Djava.net.preferIPv6Addresses=true

• अगर आपके पास Java बिल्ड टारगेट इस्तेमाल करने की सुविधा है, जिन्हें इंटरनेट से कनेक्ट करना ज़रूरी है (इंटिग्रेशन टेस्ट को कभी-कभी इसकी ज़रूरत होती है), तो इसका भी इस्तेमाल करें --jvmopt=-Djava.net.preferIPv6Addresses=true अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है टूल फ़्लैग का इस्तेमाल किया जा सकता है, उदाहरण के लिए: आपकी .bazelrc फ़ाइल में निम्न पंक्ति:

  build --jvmopt=-Djava.net.preferIPv6Addresses

• अगर आप इसका इस्तेमाल कर रहे हैं, तो rules_jvm_external, उदाहरण के लिए, डिपेंडेंसी वर्शन रिज़ॉल्यूशन के लिए, -Djava.net.preferIPv6Addresses=true से COURSIER_OPTS के बीच एनवायरमेंट वैरिएबल की मदद से कॉर्सियर के लिए जेवीएम के विकल्प उपलब्ध कराना

ट्रांज़िटिव डिपेंडेंसी

Baज़र, आपकी WORKSPACE फ़ाइल में मौजूद डिपेंडेंसी को सिर्फ़ पढ़ता है. अगर आपका प्रोजेक्ट (A), किसी दूसरे प्रोजेक्ट (B) पर निर्भर है, जिसमें तीसरे पक्ष की डिपेंडेंसी दी गई है प्रोजेक्ट (C) को इसकी WORKSPACE फ़ाइल में एक्सपोर्ट करना होता है, तो आपको दोनों B को जोड़ना होगा और C को आपके प्रोजेक्ट की WORKSPACE फ़ाइल में जोड़ा जा सकता है. यह ज़रूरत, दुनिया भर में फ़ाइल का साइज़ WORKSPACE है, लेकिन इसमें एक लाइब्रेरी होने की संभावना सीमित है वर्शन 1.0 पर C और दूसरे में C को 2.0 शामिल करते हैं.

एक्सटर्नल डिपेंडेंसी को कैश मेमोरी में सेव करना

डिफ़ॉल्ट रूप से, Baze बाहरी डिपेंडेंसी को सिर्फ़ तब फिर से डाउनलोड करेगा, जब परिभाषा में बदलाव हुए हैं. परिभाषा में बताई गई फ़ाइलों में बदलाव. जैसे, पैच या BUILD फ़ाइलें) भी शामिल हैं.

ज़बरदस्ती फिर से डाउनलोड करने के लिए, bazel sync का इस्तेमाल करें.

लेआउट

सभी बाहरी डिपेंडेंसी को सबडायरेक्ट्री के तहत एक डायरेक्ट्री में डाउनलोड किया जाता है आउटपुट बेस में external. अगर लोकल रिपॉज़िटरी, एक सिमलिंक बनाया जाता है नहीं कर सकते. external डायरेक्ट्री को चलाकर देखा जा सकता है:

ls $(bazel info output_base)/external

ध्यान दें कि bazel clean चलाने से बाहरी डेटा को नहीं मिटाया जाएगा डायरेक्ट्री. सभी बाहरी आर्टफ़ैक्ट हटाने के लिए, bazel clean --expunge का इस्तेमाल करें.

ऑफ़लाइन बिल्ड

बिल्ड को ऑफ़लाइन तरीके से चलाना कभी-कभी ज़रूरी या ज़रूरी हो जाता है. इसके लिए सामान्य इस्तेमाल के उदाहरण, जैसे कि हवाई जहाज़ पर यात्रा करना, ज़रूरत के मुताबिक prefetching अगर डेटा स्टोर करने की जगहों में bazel fetch या bazel sync है, तो यह काफ़ी हो सकता है; इतना ही नहीं, विकल्प --nofetch का इस्तेमाल करके, डेटा स्टोर करने की अन्य जगहों की जानकारी फ़ेच करने की सुविधा को बंद किया जा सकता है बिल्ड के दौरान किया गया था.

असल ऑफ़लाइन बिल्ड के लिए, जहां ज़रूरी फ़ाइलें उपलब्ध कराई जानी हों अगर आपकी इकाई बेज़ल से अलग है, तो बेज़ल इस विकल्प का इस्तेमाल करता है --distdir. जब भी कोई डेटा संग्रह नियम बेज़ल से फ़ाइल फ़ेच करने के लिए कहता है ctx.download या ctx.download_and_extract और फ़ाइल का हैश योग देता है की ज़रूरत है, तो बेज़ल सबसे पहले उन डायरेक्ट्रीज़ में खोजेगा जो एक फ़ाइल, जो दिए गए पहले यूआरएल के बेसनेम से मेल खाती हो और उस लोकल कॉपी का इस्तेमाल करें अगर हैश मैच होता है.

बेज़ल इस तकनीक का इस्तेमाल करके, डिस्ट्रिब्यूशन से ऑफ़लाइन बूटस्ट्रैप करते हैं आर्टफ़ैक्ट है. ऐसा करने के लिए, यह सभी ज़रूरी बाहरी तरीकों को इकट्ठा करता है डिपेंडेंसी एक इंटरनल distdir_tar.

हालांकि, baaz, रिपॉज़िटरी के नियमों में आर्बिट्रेरी कमांड चलाने की अनुमति देता है, ताकि उन्हें यह पता न चले कि वे नेटवर्क से संपर्क करते हैं या नहीं. इसलिए, बेज़ल का कोई विकल्प नहीं है बिल्ड को पूरी तरह से ऑफ़लाइन लागू करने के लिए. इसलिए, यह जांचना कि कोई बिल्ड ठीक से काम कर रहा है या नहीं ऑफ़लाइन होने पर नेटवर्क को बाहरी ब्लॉक करना ज़रूरी होता है, जैसा कि बेज़ल अपने ऐप्लिकेशन में बूटस्ट्रैप टेस्ट.

सबसे सही तरीके

डेटा स्टोर करने की जगह के नियम

आम तौर पर, रिपॉज़िटरी का नियम इनके लिए ज़िम्मेदार होना चाहिए:

• सिस्टम सेटिंग को पहचानकर, उन्हें फ़ाइलों पर लिखा जा सकता है.
• सिस्टम पर कहीं और संसाधन खोजना.
• यूआरएल से संसाधन डाउनलोड किए जा रहे हैं.
• बाहरी रिपॉज़िटरी डायरेक्ट्री में BUILD फ़ाइलों को जनरेट या सिमलिंक करना.

जब भी हो सके, repository_ctx.execute का इस्तेमाल करने से बचें. उदाहरण के लिए, नॉन-बेज़ल C++ का इस्तेमाल करते समय ऐसी लाइब्रेरी है जिसमें Make का इस्तेमाल किया गया है, तो repository_ctx.download() का इस्तेमाल करना बेहतर होता है. ऐसी BUILD फ़ाइल लिखें जो ctx.execute(["make"]) को चलाने के बजाय, उसे बनाए.

http_archive को git_repository और new_git_repository. इसकी वजहें ये हैं:

• Git रिपॉज़िटरी के नियम सिस्टम git(1) पर निर्भर करते हैं, जबकि एचटीटीपी डाउनलोडर बनाया गया है और इसकी कोई सिस्टम डिपेंडेंसी नहीं है.
• http_archive urls की सूची को मिरर के रूप में इस्तेमाल करता है, और git_repository सिर्फ़ काम करता है एक remote.
• http_archive, डेटा स्टोर करने की कैश मेमोरी के साथ काम करता है, लेकिन यह काम नहीं करता git_repository. यहां जाएं: #5116 पर जाएं.

bind() का इस्तेमाल न करें. देखें "इन्हें हटाने के बारे में सोचें बाइंड" लंबे समय के लिए इसके मुद्दों और विकल्पों पर चर्चा करना.