BazelCon 2022 16-17 নভেম্বর নিউ ইয়র্ক এবং অনলাইনে আসছে। নিবন্ধন আজ!
নতুন: 15 নভেম্বর সম্প্রদায় দিবসের জন্য আমাদের সাথে যোগ দিন! বিস্তারিত এবং নিবন্ধন.

কর্মক্ষেত্রের নিয়ম

সেভ করা পৃষ্ঠা গুছিয়ে রাখতে 'সংগ্রহ' ব্যবহার করুন আপনার পছন্দ অনুযায়ী কন্টেন্ট সেভ করুন ও সঠিক বিভাগে রাখুন।

ওয়ার্কস্পেস নিয়মগুলি বাহ্যিক নির্ভরতাগুলি টানতে ব্যবহৃত হয়, সাধারণত মূল সংগ্রহস্থলের বাইরে অবস্থিত উত্স কোড।

দ্রষ্টব্য: নেটিভ ওয়ার্কস্পেস নিয়মের পাশাপাশি, Bazel বিভিন্ন Starlark ওয়ার্কস্পেস নিয়মগুলিও এম্বেড করে, বিশেষ করে যেগুলি ওয়েবে হোস্ট করা গিট রিপোজিটরি বা আর্কাইভগুলির সাথে মোকাবিলা করার জন্য।

নিয়ম

বাঁধাই করা

bind(name, actual, compatible_with, deprecation, distribs, features, licenses, restricted_to, tags, target_compatible_with, testonly, visibility)

সতর্কতা: bind() ব্যবহার বাঞ্ছনীয় নয়। এর সমস্যা এবং বিকল্পগুলির একটি দীর্ঘ আলোচনার জন্য " বাঁধাই অপসারণ বিবেচনা করুন " দেখুন৷ বিশেষ করে, repo_mapping সংগ্রহস্থল বৈশিষ্ট্যের ব্যবহার বিবেচনা করুন।

সতর্কতা: select() bind() এ ব্যবহার করা যাবে না। বিস্তারিত জানার জন্য কনফিগারযোগ্য গুণাবলী FAQ দেখুন।

//external প্যাকেজে একটি লক্ষ্যকে একটি উপনাম দেয়।

//external প্যাকেজটি একটি "স্বাভাবিক" প্যাকেজ নয়: কোনও বহিরাগত/ ডিরেক্টরি নেই, তাই এটিকে একটি "ভার্চুয়াল প্যাকেজ" হিসাবে ভাবা যেতে পারে যাতে সমস্ত আবদ্ধ লক্ষ্য থাকে।

উদাহরণ

একটি লক্ষ্যকে একটি উপনাম দিতে, এটি ওয়ার্কস্পেস ফাইলে 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 এর উপর নির্ভর করবে।

আপনার কর্মক্ষেত্রে উপলব্ধ বহিরাগত সংগ্রহস্থলগুলিতে লক্ষ্যগুলি তৈরি করতে Bind ব্যবহার করা যেতে পারে। উদাহরণস্বরূপ, যদি 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 । 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)

একটি স্থানীয় ডিরেক্টরিকে একটি Bazel সংগ্রহস্থলে পরিণত করার অনুমতি দেয়৷ এর অর্থ হল বর্তমান সংগ্রহস্থল ফাইল সিস্টেমের যেকোনো স্থান থেকে লক্ষ্য নির্ধারণ এবং ব্যবহার করতে পারে।

এই নিয়মটি একটি ওয়ার্কস্পেস ফাইল এবং সাবডিরেক্টরি তৈরি করে একটি বেজেল রিপোজিটরি তৈরি করে যার মধ্যে বিল্ড ফাইল এবং প্রদত্ত পাথের সিমলিঙ্ক রয়েছে৷ বিল্ড ফাইলটি path সাথে সম্পর্কিত লক্ষ্যগুলি তৈরি করা উচিত। যে ডিরেক্টরিগুলির জন্য ইতিমধ্যে একটি local_repository ফাইল এবং একটি BUILD ফাইল রয়েছে, স্থানীয়_রিপোজিটরি নিয়মটি ব্যবহার করা যেতে পারে।

উদাহরণ

ধরুন বর্তমান সংগ্রহস্থলটি একটি চ্যাট ক্লায়েন্ট, যা ~/chat-app ডিরেক্টরিতে রুট করা হয়েছে। এটি একটি SSL লাইব্রেরি ব্যবহার করতে চায় যা একটি ভিন্ন ডিরেক্টরিতে সংজ্ঞায়িত করা হয়েছে: ~/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"],
)
তাহলে piano.jar ব্যবহার করার জন্য লক্ষ্যগুলি @piano//:play-music উপর নির্ভর করতে পারে।

যুক্তি

গুণাবলী
name

Name ; required

এই লক্ষ্যের জন্য একটি অনন্য নাম।

build_file

String; optional

এই ডিরেক্টরির জন্য একটি BUILD ফাইল হিসাবে ব্যবহার করার জন্য একটি ফাইল৷

বিল্ড_ফাইল বা বিল্ড_ফাইল_কন্টেন্ট অবশ্যই নির্দিষ্ট করতে হবে।

এই বৈশিষ্ট্যটি প্রধান কর্মক্ষেত্রের সাথে সম্পর্কিত একটি লেবেল। ফাইলটির নাম BUILD করার দরকার নেই, তবে হতে পারে। (BUILD.new-repo-name এর মত কিছু রিপোজিটরির আসল BUILD ফাইল থেকে আলাদা করার জন্য ভাল কাজ করতে পারে।)

build_file_content

String; optional

এই সংগ্রহস্থলের জন্য BUILD ফাইলের বিষয়বস্তু।

বিল্ড_ফাইল বা বিল্ড_ফাইল_কন্টেন্ট অবশ্যই নির্দিষ্ট করতে হবে।

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 নামকরণের প্রয়োজন নেই, তবে হতে পারে। (WORKSPACE.new-repo-name এর মত কিছু এটাকে রিপোজিটরির প্রকৃত WORKSPACE ফাইল থেকে আলাদা করার জন্য ভালো কাজ করতে পারে।)

workspace_file_content

String; optional

এই সংগ্রহস্থলের জন্য WORKSPACE ফাইলের বিষয়বস্তু।

হয় ওয়ার্কস্পেস_ফাইল বা ওয়ার্কস্পেস_ফাইল_কন্টেন্ট নির্দিষ্ট করা যেতে পারে, তবে উভয়ই নয়।