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

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

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

नियम

• बाइंड
• 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 रिपॉज़िटरी एट्रिब्यूट.

चेतावनी: bind() में select() का इस्तेमाल नहीं किया जा सकता. इनके लिए, कॉन्फ़िगर किए जा सकने वाले एट्रिब्यूट के बारे में अक्सर पूछे जाने वाले सवाल देखें जानकारी देखें.

टारगेट को //external पैकेज में एक उपनाम देता है.

//external पैकेज "सामान्य" नहीं है पैकेज: कोई बाहरी/ डायरेक्ट्री नहीं है, इसलिए इसे एक "वर्चुअल पैकेज" माना जा सकता है जिसमें सभी बाउंड टारगेट शामिल हैं.

उदाहरण

किसी टारगेट को उपनाम देने के लिए, उसे वर्कस्पेस फ़ाइल में bind करें. उदाहरण के लिए, मान लीजिए कि किसी java_library टारगेट को कॉल किया गया है //third_party/javacc-v2. इसे Workspace फ़ाइल:

bind(
    name = "javacc-latest",
    actual = "//third_party/javacc-v2",
)

अब टारगेट, इसके बजाय //external:javacc-latest पर निर्भर हो सकते हैं //third_party/javacc-v2. अगर javacc-v3 को रिलीज़ किया गया, तो bind नियम अपडेट की जाएगी और //external:javacc-latest के आधार पर बनाई गई सभी BUILD फ़ाइलें अब अपडेट हो जाएंगी उसके लिए javacc-v3 का इस्तेमाल करना पड़ता है और इसके लिए बदलाव करने की ज़रूरत नहीं होती.

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

तर्क

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)

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

यह नियम, Workspace फ़ाइल और सबडायरेक्ट्री (इसमें शामिल है) बनाकर बेज़ल रिपॉज़िटरी बनाता है दिए गए BUILD फ़ाइल और पाथ के सिमलिंक. बिल्ड फ़ाइल को 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/Downloads/piano.jar पर एक जार फ़ाइल थी. आपने लोगों तक पहुंचाया मुफ़्त में आपकी वर्कस्पेस फ़ाइल में नीचे दी गई चीज़ें जोड़कर, बस उस फ़ाइल को आपके बिल्ड में जोड़ा जा सकता है:

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

तर्क