বাহ্যিক নির্ভরতা নিয়ে কাজ করা

Bazel অন্যান্য প্রকল্প থেকে লক্ষ্য উপর নির্ভর করতে পারে. এই অন্যান্য প্রকল্প থেকে নির্ভরশীলতা বহিরাগত নির্ভরতা বলা হয়.

ওয়ার্কস্পেস ডিরেক্টরিতে ওয়ার্কস্পেস ফাইল (বা 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 ফাইলের মতো একই সিনট্যাক্স ব্যবহার করে, তবে সংগ্রহস্থলের নিয়ম (কখনও কখনও ওয়ার্কস্পেস নিয়ম হিসাবেও পরিচিত) নামক নিয়মগুলির একটি ভিন্ন সেটের অনুমতি দেয়। Bazel কিছু বিল্ট-ইন রিপোজিটরি নিয়ম এবং এমবেডেড Starlark রিপোজিটরি নিয়মের একটি সেট নিয়ে আসে। ব্যবহারকারীরা আরও জটিল আচরণ পেতে কাস্টম সংগ্রহস্থলের নিয়ম লিখতে পারেন।

সমর্থিত ধরনের বাহ্যিক নির্ভরতা

কয়েকটি মৌলিক ধরনের বাহ্যিক নির্ভরতা ব্যবহার করা যেতে পারে:

• অন্যান্য Bazel প্রকল্পের উপর নির্ভরতা
• নন-ব্যাজেল প্রকল্পের উপর নির্ভরতা
• বাহ্যিক প্যাকেজের উপর নির্ভরতা

অন্যান্য Bazel প্রকল্পের উপর নির্ভর করে

আপনি যদি দ্বিতীয় বেজেল প্রকল্প থেকে লক্ষ্যগুলি ব্যবহার করতে চান, আপনি স্থানীয় ফাইল সিস্টেম থেকে এটিকে সিমলিংক করতে, একটি গিট সংগ্রহস্থল উল্লেখ করতে বা এটি ডাউনলোড করতে local_repository , git_repository বা http_archive ব্যবহার করতে পারেন (যথাক্রমে)।

উদাহরণস্বরূপ, ধরুন আপনি একটি প্রকল্পে কাজ করছেন, my-project/ , এবং আপনি আপনার সহকর্মীর প্রকল্প, coworkers-project/ থেকে লক্ষ্যের উপর নির্ভর করতে চান। উভয় প্রকল্পই Bazel ব্যবহার করে, তাই আপনি আপনার সহকর্মীর প্রকল্পকে একটি বাহ্যিক নির্ভরতা হিসাবে যুক্ত করতে পারেন এবং তারপরে আপনার নিজের BUILD ফাইল থেকে আপনার সহকর্মী সংজ্ঞায়িত যে কোনো লক্ষ্য ব্যবহার করতে পারেন৷ আপনি my_project/WORKSPACE এ নিম্নলিখিত যোগ করবেন:

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

যদি আপনার সহকর্মীর একটি টার্গেট //foo:bar থাকে, তাহলে আপনার প্রজেক্ট এটিকে @coworkers_project//foo:bar হিসেবে উল্লেখ করতে পারে। বাহ্যিক প্রকল্পের নাম অবশ্যই বৈধ ওয়ার্কস্পেস নাম হতে হবে।

নন-ব্যাজেল প্রকল্পের উপর নির্ভর করে

new_ সাথে উপসর্গযুক্ত নিয়ম, যেমন new_local_repository , আপনাকে এমন প্রকল্পগুলি থেকে লক্ষ্য তৈরি করতে দেয় যা Bazel ব্যবহার করে না।

উদাহরণস্বরূপ, ধরুন আপনি একটি প্রকল্পে কাজ করছেন, my-project/ , এবং আপনি আপনার সহকর্মীর প্রকল্প, coworkers-project/ এর উপর নির্ভর করতে চান। আপনার সহকর্মীর প্রকল্পটি তৈরি করতে make ব্যবহার করে, কিন্তু আপনি এটি তৈরি করা ফাইলগুলির একটির উপর নির্ভর করতে চান৷ এটি করতে, 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"],
)

তারপরে আপনি আপনার প্রকল্পের BUILD ফাইল থেকে @coworkers_project//:some-lib এর উপর নির্ভর করতে পারেন।

বাহ্যিক প্যাকেজের উপর নির্ভর করে

Maven নিদর্শন এবং সংগ্রহস্থল

মাভেন রিপোজিটরি থেকে আর্টিফ্যাক্ট ডাউনলোড করতে এবং জাভা নির্ভরতা হিসাবে উপলব্ধ করতে rules_jvm_external ব্যবহার করুন।

নির্ভরতা আনা হচ্ছে

ডিফল্টরূপে, bazel build সময় প্রয়োজন অনুযায়ী বাহ্যিক নির্ভরতা আনা হয়। আপনি যদি লক্ষ্যগুলির একটি নির্দিষ্ট সেটের জন্য প্রয়োজনীয় নির্ভরতাগুলি bazel fetch ব্যবহার করুন। নিঃশর্তভাবে সমস্ত বাহ্যিক নির্ভরতা আনতে, bazel sync ব্যবহার করুন৷ যেহেতু আনা সংগ্রহস্থলগুলি আউটপুট বেসে সংরক্ষণ করা হয় , তাই প্রতি কর্মক্ষেত্রে আনা হয়।

ছায়া নির্ভরতা

যখনই সম্ভব, আপনার প্রকল্পে একটি একক সংস্করণ নীতি থাকা বাঞ্ছনীয়। এটি নির্ভরতাগুলির জন্য প্রয়োজন যা আপনি কম্পাইল করেন এবং আপনার চূড়ান্ত বাইনারিতে শেষ করেন। কিন্তু এমন ক্ষেত্রে যেখানে এটি সত্য নয়, নির্ভরতাকে ছায়া দেওয়া সম্ভব। নিম্নলিখিত দৃশ্যকল্প বিবেচনা করুন:

myproject/WORKSPACE

workspace(name = "myproject")

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

এ/ওয়ার্কস্পেস

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 মধ্যে শান্তিপূর্ণভাবে সহাবস্থান না করার কোন কারণ নেই, তবে তাদের একই নাম থাকায় তারা একে অপরের সাথে সংঘর্ষে লিপ্ত হবে। উভয় নির্ভরতা ঘোষণা করতে, myproject/WORKSPACE আপডেট করুন:

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 যদি একই নির্ভরতা থাকে তবে একে ভিন্ন নামে ডাকে, সেই নির্ভরতাগুলি myproject/WORKSPACE-এ যোগ দেওয়া যেতে পারে।

কমান্ড লাইন থেকে সংগ্রহস্থল ওভাররাইডিং

কমান্ড লাইন থেকে একটি স্থানীয় সংগ্রহস্থলের সাথে একটি ঘোষিত সংগ্রহস্থল ওভাররাইড করতে, --override_repository পতাকা ব্যবহার করুন। এই পতাকা ব্যবহার করে আপনার সোর্স কোড পরিবর্তন না করেই বাহ্যিক সংগ্রহস্থলের বিষয়বস্তু পরিবর্তন করে।

উদাহরণস্বরূপ, স্থানীয় ডিরেক্টরি /path/to/local/foo এ @foo ওভাররাইড করতে, --override_repository --override_repository=foo=/path/to/local/foo ফ্ল্যাগটি পাস করুন।

কিছু ব্যবহারের ক্ষেত্রে অন্তর্ভুক্ত:

• ডিবাগিং সমস্যা। উদাহরণস্বরূপ, আপনি একটি স্থানীয় ডিরেক্টরিতে একটি http_archive সংগ্রহস্থল ওভাররাইড করতে পারেন যেখানে আপনি আরও সহজে পরিবর্তন করতে পারেন।
• ভেন্ডরিং। আপনি যদি এমন একটি পরিবেশে থাকেন যেখানে আপনি নেটওয়ার্ক কল করতে পারবেন না, তার পরিবর্তে স্থানীয় ডিরেক্টরিতে নির্দেশ করতে নেটওয়ার্ক-ভিত্তিক সংগ্রহস্থলের নিয়মগুলি ওভাররাইড করুন।

প্রক্সি ব্যবহার করে

Bazel HTTPS_PROXY এবং HTTP_PROXY এনভায়রনমেন্ট ভেরিয়েবল থেকে প্রক্সি অ্যাড্রেস তুলবে এবং HTTP/HTTPS ফাইল ডাউনলোড করতে ব্যবহার করবে (যদি নির্দিষ্ট করা থাকে)।

IPv6 এর জন্য সমর্থন

শুধুমাত্র IPv6 মেশিনে, Bazel কোনো পরিবর্তন ছাড়াই নির্ভরতা ডাউনলোড করতে সক্ষম হবে। ডুয়াল-স্ট্যাক IPv4/IPv6 মেশিনে, তবে, Bazel জাভা হিসাবে একই নিয়ম অনুসরণ করে: যদি IPv4 সক্রিয় থাকে, IPv4 পছন্দ করা হয়। কিছু পরিস্থিতিতে, উদাহরণস্বরূপ, যখন IPv4 নেটওয়ার্ক বাহ্যিক ঠিকানাগুলি সমাধান করতে/পৌঁছতে অক্ষম হয়, এটি Network unreachable পৌঁছানো যায় না এমন ব্যতিক্রম এবং বিল্ড ব্যর্থতার কারণ হতে পারে। এই ক্ষেত্রে, আপনি java.net.preferIPv6Addresses=true সিস্টেম প্রপার্টি ব্যবহার করে IPv6 পছন্দ করার জন্য Bazel-এর আচরণ ওভাররাইড করতে পারেন। বিশেষভাবে:

• --host_jvm_args=-Djava.net.preferIPv6Addresses=true startup অপশন ব্যবহার করুন, উদাহরণস্বরূপ আপনার .bazelrc ফাইলে নিম্নলিখিত লাইন যোগ করে:

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

• আপনি যদি জাভা বিল্ড টার্গেট চালাচ্ছেন যা ইন্টারনেটের সাথেও সংযোগ করতে হবে (ইন্টিগ্রেশন টেস্টে মাঝে মাঝে এটির প্রয়োজন হয়), এছাড়াও --jvmopt=-Djava.net.preferIPv6Addresses=true টুল ফ্ল্যাগ ব্যবহার করুন, উদাহরণস্বরূপ আপনার নিচের লাইনটি রেখে .bazelrc ফাইল :

  build --jvmopt=-Djava.net.preferIPv6Addresses

• আপনি যদি rules_jvm_external ব্যবহার করেন, উদাহরণস্বরূপ, নির্ভরতা সংস্করণ রেজোলিউশনের জন্য, Coursier-এর জন্য JVM বিকল্পগুলি প্রদান করতে COURSIER_OPTS এনভায়রনমেন্ট ভেরিয়েবলে -Djava.net.preferIPv6Addresses=true যোগ করুন

ট্রানজিটিভ নির্ভরতা

Bazel শুধুমাত্র আপনার WORKSPACE ফাইলে তালিকাভুক্ত নির্ভরতা পড়ে। যদি আপনার প্রকল্প ( A ) অন্য একটি প্রকল্প ( B ) এর উপর নির্ভর করে যা তার WORKSPACE ফাইলে একটি তৃতীয় প্রকল্প ( C ) এর উপর নির্ভরতা তালিকাভুক্ত করে, তাহলে আপনাকে আপনার প্রকল্পের WORKSPACE ফাইলে B এবং C উভয়ই যোগ করতে হবে। এই প্রয়োজনীয়তাটি WORKSPACE ফাইলের আকারকে বেলুন করতে পারে, তবে একটি লাইব্রেরি 1.0 সংস্করণে C অন্তর্ভুক্ত করার সম্ভাবনা সীমিত করে এবং অন্যটি 2.0-এ C অন্তর্ভুক্ত করে।

বাহ্যিক নির্ভরতা ক্যাশিং

ডিফল্টরূপে, Bazel শুধুমাত্র বাহ্যিক নির্ভরতা পুনরায় ডাউনলোড করবে যদি তাদের সংজ্ঞা পরিবর্তন হয়। সংজ্ঞায় উল্লেখ করা ফাইলগুলির পরিবর্তনগুলি (যেমন প্যাচ বা BUILD ফাইলগুলি) বেজেল দ্বারা বিবেচনা করা হয়।

জোর করে পুনরায় ডাউনলোড করতে, bazel sync ব্যবহার করুন।

লেআউট

বাহ্যিক নির্ভরতাগুলি আউটপুট বেসে external সাবডিরেক্টরির অধীনে একটি ডিরেক্টরিতে ডাউনলোড করা হয়। একটি স্থানীয় সংগ্রহস্থলের ক্ষেত্রে, একটি নতুন ডিরেক্টরি তৈরি করার পরিবর্তে সেখানে একটি সিমলিঙ্ক তৈরি করা হয়। আপনি চালানোর মাধ্যমে external ডিরেক্টরি দেখতে পারেন:

ls $(bazel info output_base)/external

মনে রাখবেন যে bazel clean চালানো আসলে বহিরাগত ডিরেক্টরি মুছে ফেলবে না। সমস্ত বাহ্যিক শিল্পকর্ম অপসারণ করতে, bazel clean --expunge ব্যবহার করুন।

অফলাইন তৈরি করে

অফলাইন ফ্যাশনে বিল্ড চালানো কখনও কখনও বাঞ্ছনীয় বা প্রয়োজনীয়। সাধারণ ব্যবহারের ক্ষেত্রে, যেমন একটি বিমানে ভ্রমণ, bazel fetch বা bazel sync সহ প্রয়োজনীয় সংগ্রহস্থলগুলি প্রিফেচ করা যথেষ্ট হতে পারে; অধিকন্তু, --nofetch বিকল্পটি ব্যবহার করে, বিল্ড করার সময় আরও সংগ্রহস্থলের আনয়ন নিষ্ক্রিয় করা যেতে পারে।

সত্যিকারের অফলাইন বিল্ডের জন্য, যেখানে প্রয়োজনীয় ফাইল সরবরাহ করা হয় bazel থেকে ভিন্ন একটি সত্তা দ্বারা করা হয়, bazel --distdir বিকল্পটিকে সমর্থন করে। যখনই একটি সংগ্রহস্থলের নিয়ম বেজেলকে ctx.download বা ctx.download_and_extract এর মাধ্যমে একটি ফাইল আনতে বলে এবং প্রয়োজনীয় ফাইলের একটি হ্যাশ যোগ প্রদান করে, তখন bazel প্রথমে প্রদত্ত প্রথম URL-এর বেসনামের সাথে মেলে একটি ফাইলের জন্য সেই বিকল্প দ্বারা নির্দিষ্ট করা ডিরেক্টরিগুলি দেখবে। , এবং হ্যাশ মিলে গেলে সেই স্থানীয় কপিটি ব্যবহার করুন।

Bazel নিজেই এই কৌশলটি ব্যবহার করে অফলাইনে ডিস্ট্রিবিউশন আর্টিফ্যাক্ট থেকে বুটস্ট্র্যাপ করতে। এটি একটি অভ্যন্তরীণ distdir_tar এ সমস্ত প্রয়োজনীয় বাহ্যিক নির্ভরতা সংগ্রহ করে তা করে।

যাইহোক, বেজেল নেটওয়ার্কে কল করে কিনা তা না জেনে রিপোজিটরি নিয়মে নির্বিচারে আদেশগুলি কার্যকর করার অনুমতি দেয়। অতএব, সম্পূর্ণ অফলাইনে বিল্ডগুলিকে প্রয়োগ করার জন্য বেজেলের কোন বিকল্প নেই। সুতরাং একটি বিল্ড অফলাইনে সঠিকভাবে কাজ করে কিনা তা পরীক্ষা করার জন্য নেটওয়ার্কের বাহ্যিক ব্লকিং প্রয়োজন, যেমন বেজেল তার বুটস্ট্র্যাপ পরীক্ষায় করে।

সেরা অনুশীলন

সংগ্রহস্থলের নিয়ম

একটি সংগ্রহস্থল নিয়ম সাধারণত এর জন্য দায়ী হওয়া উচিত:

• সিস্টেম সেটিংস সনাক্ত করা এবং ফাইলগুলিতে লেখা।
• সিস্টেমের অন্য কোথাও সম্পদ খোঁজা.
• ইউআরএল থেকে সম্পদ ডাউনলোড করা হচ্ছে।
• বাহ্যিক সংগ্রহস্থল ডিরেক্টরিতে বিল্ড ফাইল তৈরি করা বা সিমলিংক করা।

সম্ভব হলে repository_ctx.execute ব্যবহার এড়িয়ে চলুন। উদাহরণস্বরূপ, যখন মেক ব্যবহার করে একটি বিল্ড আছে এমন একটি নন-বাজেল সি++ লাইব্রেরি ব্যবহার করার সময়, ctx.execute(["make"]) চালানোর পরিবর্তে repository_ctx.download() ব্যবহার করা এবং তারপর একটি BUILD ফাইল লিখুন যা এটি তৈরি করে। ctx.execute(["make"])

git_repository এবং http_archive এ new_git_repository পছন্দ করুন। কারণগুলি হল:

• গিট রিপোজিটরি নিয়মগুলি সিস্টেম git(1) এর উপর নির্ভর করে যেখানে HTTP ডাউনলোডার বেজেলে তৈরি করা হয়েছে এবং এর কোনও সিস্টেম নির্ভরতা নেই।
• http_archive মিরর হিসাবে urls এর একটি তালিকা সমর্থন করে, এবং git_repository শুধুমাত্র একটি একক remote সমর্থন করে।
• http_archive রিপোজিটরি ক্যাশের সাথে কাজ করে, কিন্তু git_repository নয়। আরও তথ্যের জন্য #5116 দেখুন।

bind() ব্যবহার করবেন না। এর সমস্যা এবং বিকল্পগুলির একটি দীর্ঘ আলোচনার জন্য " বাঁধাই অপসারণ বিবেচনা করুন " দেখুন৷