BazelCon 2022 16-17 নভেম্বর নিউ ইয়র্ক এবং অনলাইনে আসছে।
নিবন্ধন আজ!

সাধারণ সংজ্ঞা

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

এই বিভাগটি বিভিন্ন পদ এবং ধারণাকে সংজ্ঞায়িত করে যা অনেক ফাংশন বা বিল্ড নিয়মগুলির জন্য সাধারণ।

বিষয়বস্তু

বোর্ন শেল টোকেনাইজেশন

বোর্ন শেলের টোকেনাইজেশন নিয়ম অনুসারে কিছু নিয়মের নির্দিষ্ট স্ট্রিং অ্যাট্রিবিউটগুলিকে একাধিক শব্দে বিভক্ত করা হয়েছে: উদ্ধৃত শূন্যস্থানগুলি পৃথক শব্দকে সীমাবদ্ধ করে, এবং টোকেনাইজেশন প্রতিরোধ করতে একক- এবং ডবল-কোট অক্ষর এবং ব্যাকস্ল্যাশ ব্যবহার করা হয়।

এই টোকেনাইজেশনের সাপেক্ষে যে বৈশিষ্ট্যগুলি এই নথিতে তাদের সংজ্ঞাগুলিতে স্পষ্টভাবে নির্দেশিত হয়েছে।

"মেক" পরিবর্তনশীল সম্প্রসারণ এবং বোর্ন শেল টোকেনাইজেশন সাপেক্ষে বৈশিষ্ট্যগুলি সাধারণত কম্পাইলার এবং অন্যান্য সরঞ্জামগুলিতে নির্বিচারে বিকল্পগুলি পাস করার জন্য ব্যবহৃত হয়। এই ধরনের গুণাবলীর উদাহরণ হল cc_library.copts এবং java_library.javacopts । একসাথে এই প্রতিস্থাপনগুলি একটি একক স্ট্রিং ভেরিয়েবলকে বিকল্প শব্দগুলির একটি কনফিগারেশন-নির্দিষ্ট তালিকায় প্রসারিত করার অনুমতি দেয়।

লেবেল সম্প্রসারণ

খুব কম নিয়মের কিছু স্ট্রিং অ্যাট্রিবিউট লেবেল সম্প্রসারণ সাপেক্ষে: যদি সেই স্ট্রিংগুলিতে একটি সাবস্ট্রিং হিসাবে একটি বৈধ লেবেল থাকে, যেমন //mypkg:target , এবং সেই লেবেলটি বর্তমান নিয়মের একটি ঘোষিত পূর্বশর্ত, তবে এটি প্রসারিত করা হয় টার্গেট //mypkg:target দ্বারা উপস্থাপিত ফাইলের পাথনাম।

উদাহরণের বৈশিষ্ট্যগুলির মধ্যে রয়েছে genrule.cmd এবং cc_binary.linkopts । প্রতিটি ক্ষেত্রে বিশদ বিবরণ উল্লেখযোগ্যভাবে পরিবর্তিত হতে পারে, যেমন বিষয়গুলির উপর: আপেক্ষিক লেবেলগুলি প্রসারিত করা হয়েছে কিনা; একাধিক ফাইলে প্রসারিত হওয়া লেবেলগুলিকে কীভাবে চিকিত্সা করা হয়, ইত্যাদি। সুনির্দিষ্টের জন্য নিয়ম বৈশিষ্ট্য ডকুমেন্টেশনের সাথে পরামর্শ করুন।

বেশিরভাগ বিল্ড নিয়ম দ্বারা সংজ্ঞায়িত সাধারণ বৈশিষ্ট্য

এই বিভাগটি এমন বৈশিষ্ট্যগুলি বর্ণনা করে যা অনেকগুলি বিল্ড নিয়ম দ্বারা সংজ্ঞায়িত করা হয়, কিন্তু সমস্ত নয়৷

বৈশিষ্ট্য বর্ণনা
data

List of labels ; optional

রানটাইমে এই নিয়ম দ্বারা প্রয়োজনীয় ফাইল। ফাইল বা নিয়ম লক্ষ্য তালিকা হতে পারে. সাধারণত কোন লক্ষ্য অনুমতি দেয়.

data অ্যাট্রিবিউটে লক্ষ্যগুলির ডিফল্ট আউটপুট এবং রানফাইলগুলি যে কোনও এক্সিকিউটেবলের *.runfiles এলাকায় উপস্থিত হওয়া উচিত যা এই টার্গেটে রানটাইম নির্ভরতা দ্বারা আউটপুট হয় বা রয়েছে। এই টার্গেটের srcs কার্যকর করার সময় ব্যবহৃত ডেটা ফাইল বা বাইনারিগুলি এতে অন্তর্ভুক্ত থাকতে পারে। কীভাবে ডেটা ফাইলের উপর নির্ভর করতে হয় এবং ব্যবহার করতে হয় সে সম্পর্কে আরও তথ্যের জন্য ডেটা নির্ভরতা বিভাগটি দেখুন।

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

deps

List of labels ; optional

এই লক্ষ্যের জন্য নির্ভরতা। সাধারণত শুধুমাত্র নিয়ম লক্ষ্য তালিকা করা উচিত। (যদিও কিছু নিয়ম ফাইলগুলিকে সরাসরি deps -এ তালিকাভুক্ত করার অনুমতি দেয়, এটি সম্ভব হলে এড়ানো উচিত।)

ভাষা-নির্দিষ্ট নিয়মগুলি সাধারণত তালিকাভুক্ত লক্ষ্যগুলিকে নির্দিষ্ট প্রদানকারীদের কাছে সীমাবদ্ধ করে।

একটি টার্গেটের জন্য deps ব্যবহার করে অন্যের উপর নির্ভর করার অর্থ কী তার সুনির্দিষ্ট শব্দার্থবিদ্যা নিয়মের ধরণের জন্য নির্দিষ্ট, এবং নিয়ম-নির্দিষ্ট ডকুমেন্টেশন আরও বিশদে যায়। সোর্স কোড প্রক্রিয়া করার নিয়মগুলির জন্য, deps সাধারণত srcs এ কোড দ্বারা ব্যবহৃত কোড নির্ভরতা নির্দিষ্ট করে।

প্রায়শই, একটি মডিউলকে একই প্রোগ্রামিং ভাষায় লিখিত এবং আলাদাভাবে সংকলিত অন্য মডিউলে সংজ্ঞায়িত চিহ্নগুলি ব্যবহার করার অনুমতি দেওয়ার জন্য একটি deps নির্ভরতা ব্যবহার করা হয়। অনেক ক্ষেত্রে ক্রস-ল্যাঙ্গুয়েজ নির্ভরতাও অনুমোদিত: উদাহরণস্বরূপ, একটি java_library টার্গেট cc_library টার্গেটে C++ কোডের উপর নির্ভর করতে পারে, পরবর্তীটিকে deps অ্যাট্রিবিউটে তালিকাভুক্ত করে। আরও তথ্যের জন্য নির্ভরতার সংজ্ঞা দেখুন।

licenses

List of strings; optional; nonconfigurable

এই নির্দিষ্ট লক্ষ্যের জন্য ব্যবহার করা লাইসেন্স-টাইপ স্ট্রিংগুলির একটি তালিকা। এটি একটি অপ্রচলিত লাইসেন্সিং API এর অংশ যা Bazel আর ব্যবহার করে না৷ এই ব্যবহার করবেন না.

srcs

List of labels ; optional

এই নিয়ম দ্বারা প্রক্রিয়া করা বা অন্তর্ভুক্ত ফাইল. সাধারণত ফাইলগুলিকে সরাসরি তালিকাভুক্ত করে, তবে তাদের ডিফল্ট আউটপুটগুলি অন্তর্ভুক্ত করতে নিয়ম লক্ষ্যগুলি (যেমন filegroup বা genrule ) তালিকাভুক্ত করতে পারে।

ভাষা-নির্দিষ্ট নিয়মগুলির জন্য প্রায়ই তালিকাভুক্ত ফাইলগুলির নির্দিষ্ট ফাইল এক্সটেনশনের প্রয়োজন হয়।

সমস্ত বিল্ড নিয়ম সাধারণ বৈশিষ্ট্য

এই বিভাগটি এমন বৈশিষ্ট্যগুলি বর্ণনা করে যা সমস্ত বিল্ড নিয়মগুলিতে অন্তর্নিহিতভাবে যুক্ত করা হয়।

বৈশিষ্ট্য বর্ণনা
compatible_with

List of labels ; optional; nonconfigurable

ডিফল্ট-সমর্থিত পরিবেশ ছাড়াও এই টার্গেটের জন্য তৈরি করা যেতে পারে এমন পরিবেশের তালিকা।

এটি Bazel এর সীমাবদ্ধতা সিস্টেমের অংশ, যা ব্যবহারকারীদের ঘোষণা করতে দেয় কোন লক্ষ্যগুলি একে অপরের উপর নির্ভর করতে পারে এবং করতে পারে না। উদাহরণস্বরূপ, বাহ্যিকভাবে স্থাপনযোগ্য বাইনারিগুলি কোম্পানি-গোপন কোড সহ লাইব্রেরির উপর নির্ভর করা উচিত নয়। বিস্তারিত জানার জন্য Constraint Semantics দেখুন।

deprecation

String; optional; nonconfigurable

এই লক্ষ্যের সাথে যুক্ত একটি ব্যাখ্যামূলক সতর্কতা বার্তা। সাধারণত এটি ব্যবহারকারীদের জানানোর জন্য ব্যবহার করা হয় যে একটি লক্ষ্য অপ্রচলিত হয়ে গেছে, বা অন্য নিয়ম দ্বারা বাতিল হয়ে গেছে, একটি প্যাকেজের জন্য ব্যক্তিগত, বা সম্ভবত কোনো কারণে ক্ষতিকারক বলে বিবেচিত হয়। কিছু রেফারেন্স অন্তর্ভুক্ত করা একটি ভাল ধারণা (যেমন একটি ওয়েবপৃষ্ঠা, একটি বাগ নম্বর বা উদাহরণ মাইগ্রেশন CL) যাতে কেউ সহজেই খুঁজে পেতে পারে যে বার্তাটি এড়াতে কী কী পরিবর্তন প্রয়োজন৷ যদি একটি নতুন লক্ষ্য থাকে যা প্রতিস্থাপনের ড্রপ হিসাবে ব্যবহার করা যেতে পারে, তবে পুরানো টার্গেটের সমস্ত ব্যবহারকারীকে স্থানান্তর করা একটি ভাল ধারণা।

জিনিসগুলি যেভাবে তৈরি করা হয় তার উপর এই বৈশিষ্ট্যটির কোন প্রভাব নেই, তবে এটি একটি বিল্ড টুলের ডায়াগনস্টিক আউটপুটকে প্রভাবিত করতে পারে। বিল্ড টুল একটি সতর্কতা জারি করে যখন একটি deprecation বৈশিষ্ট্য সহ একটি নিয়ম অন্য প্যাকেজে একটি লক্ষ্যের উপর নির্ভর করে।

আন্তঃ-প্যাকেজ নির্ভরতাগুলি এই সতর্কতা থেকে অব্যাহতিপ্রাপ্ত, যাতে, উদাহরণস্বরূপ, একটি অবমূল্যায়িত নিয়মের পরীক্ষা তৈরি করা একটি সতর্কতার সম্মুখীন না হয়৷

যদি একটি অবচ্যুত লক্ষ্য অন্য অবচয়িত লক্ষ্যের উপর নির্ভর করে, কোন সতর্কতা বার্তা জারি করা হয় না।

একবার লোকেরা এটি ব্যবহার করা বন্ধ করে দিলে, লক্ষ্যটি সরানো যেতে পারে।

distribs

List of strings; optional; nonconfigurable

এই নির্দিষ্ট টার্গেটের জন্য ব্যবহার করা ডিস্ট্রিবিউশন-পদ্ধতি স্ট্রিংগুলির একটি তালিকা। এটি একটি অপ্রচলিত লাইসেন্সিং API এর অংশ যা Bazel আর ব্যবহার করে না৷ এই ব্যবহার করবেন না.

exec_compatible_with

List of labels ; optional; nonconfigurable

এই লক্ষ্যের জন্য কার্যকরী প্ল্যাটফর্মে উপস্থিত থাকা আবশ্যক constraint_values একটি তালিকা। এটি নিয়মের ধরন দ্বারা ইতিমধ্যে সেট করা যেকোনো সীমাবদ্ধতা ছাড়াও। উপলব্ধ এক্সিকিউশন প্ল্যাটফর্মের তালিকা সীমাবদ্ধ করতে সীমাবদ্ধতা ব্যবহার করা হয়। আরো বিস্তারিত জানার জন্য, টুলচেইন রেজোলিউশনের বিবরণ দেখুন।

exec_properties

Dictionary of strings; optional

স্ট্রিংগুলির একটি অভিধান যা এই লক্ষ্যের জন্য নির্বাচিত একটি প্ল্যাটফর্মের exec_properties এ যোগ করা হবে। প্ল্যাটফর্ম নিয়মের exec_properties দেখুন।

যদি প্ল্যাটফর্ম এবং লক্ষ্য-স্তরের বৈশিষ্ট্য উভয়েই একটি কী উপস্থিত থাকে, তাহলে মান লক্ষ্য থেকে নেওয়া হবে।

features

List of feature strings; optional

একটি বৈশিষ্ট্য হল স্ট্রিং ট্যাগ যা একটি লক্ষ্যে সক্ষম বা নিষ্ক্রিয় করা যেতে পারে। একটি বৈশিষ্ট্যের অর্থ নিয়মের উপর নির্ভর করে।

এই features বৈশিষ্ট্য প্যাকেজ স্তর features বৈশিষ্ট্য সঙ্গে মিলিত হয়. উদাহরণস্বরূপ, যদি প্যাকেজ স্তরে বৈশিষ্ট্যগুলি ["a", "b"] সক্ষম করা হয়, এবং একটি লক্ষ্যের features বৈশিষ্ট্যগুলিতে ["-a", "c"] থাকে, তবে নিয়মের জন্য সক্রিয় বৈশিষ্ট্যগুলি হবে "b" এবং "গ"। উদাহরণ দেখুন

restricted_to

List of labels ; optional; nonconfigurable

ডিফল্ট-সমর্থিত পরিবেশের পরিবর্তে এই লক্ষ্যমাত্রার পরিবেশের তালিকা তৈরি করা যেতে পারে।

এটি Bazel এর সীমাবদ্ধতা সিস্টেমের অংশ। বিস্তারিত জানার জন্য compatible_with দেখুন।

tags

List of strings; optional; nonconfigurable

ট্যাগ যেকোনো নিয়মে ব্যবহার করা যেতে পারে। পরীক্ষার ট্যাগ এবং test_suite নিয়মগুলি পরীক্ষার শ্রেণীকরণের জন্য উপযোগী। নন-টেস্ট টার্গেটের ট্যাগগুলি genrule s এবং স্টারলার্ক অ্যাকশনগুলির স্যান্ডবক্সড এক্সিকিউশন নিয়ন্ত্রণ করতে এবং মানুষ এবং/অথবা বাহ্যিক সরঞ্জামগুলির দ্বারা পার্সিংয়ের জন্য ব্যবহৃত হয়।

Bazel তার স্যান্ডবক্সিং কোডের আচরণ পরিবর্তন করে যদি এটি কোনো পরীক্ষা বা genrule টার্গেটের tags অ্যাট্রিবিউটে নিম্নলিখিত কীওয়ার্ডগুলি খুঁজে পায়, অথবা কোনো Starlark অ্যাকশনের জন্য execution_requirements এর কীগুলি খুঁজে পায়।

  • no-sandbox কীওয়ার্ডের ফলাফলে অ্যাকশন বা পরীক্ষা কখনও স্যান্ডবক্স করা হয় না; এটি এখনও ক্যাশে করা যেতে পারে বা দূরবর্তীভাবে চালানো যেতে পারে - যেটি বা উভয়টিকে প্রতিরোধ করতে no-cache বা no-remote ব্যবহার করুন।
  • no-cache কীওয়ার্ডের ফলস্বরূপ অ্যাকশন বা পরীক্ষা কখনই ক্যাশে করা হয় না (দূরবর্তী বা স্থানীয়ভাবে)
  • no-remote-cache কীওয়ার্ডের ফলে অ্যাকশন বা পরীক্ষা কখনও দূরবর্তীভাবে ক্যাশ করা হয় না (তবে এটি স্থানীয়ভাবে ক্যাশে করা যেতে পারে; এটি দূরবর্তীভাবেও চালানো যেতে পারে)। দ্রষ্টব্য: এই ট্যাগের উদ্দেশ্যে, ডিস্ক-ক্যাশে একটি স্থানীয় ক্যাশে হিসাবে বিবেচিত হয়, যেখানে http এবং gRPC ক্যাশেগুলি দূরবর্তী হিসাবে বিবেচিত হয়৷ যদি একটি সম্মিলিত ক্যাশে নির্দিষ্ট করা হয় (যেমন স্থানীয় এবং দূরবর্তী উপাদানগুলির সাথে একটি ক্যাশে), এটি একটি দূরবর্তী ক্যাশে হিসাবে বিবেচিত হয় এবং সম্পূর্ণরূপে নিষ্ক্রিয় করা হয় যদি না --incompatible_remote_results_ignore_disk সেট করা হয় যে ক্ষেত্রে স্থানীয় উপাদানগুলি ব্যবহার করা হবে৷
  • no-remote-exec কীওয়ার্ডের ফলে অ্যাকশন বা পরীক্ষা কখনও দূরবর্তীভাবে চালানো হয় না (তবে এটি দূরবর্তীভাবে ক্যাশে করা যেতে পারে)।
  • no-remote কীওয়ার্ড অ্যাকশন বা পরীক্ষাকে দূরবর্তীভাবে চালানো বা দূরবর্তীভাবে ক্যাশে করা থেকে বাধা দেয়। এটি no-remote-cache এবং no-remote-exec উভয়ই ব্যবহার করার সমতুল্য।
  • no-remote-cache-upload কীওয়ার্ড একটি স্পনের রিমোট ক্যাশিংয়ের অংশ আপলোড নিষ্ক্রিয় করে। এটি দূরবর্তী সম্পাদন নিষ্ক্রিয় করে না।
  • local কীওয়ার্ড অ্যাকশন বা পরীক্ষাকে দূরবর্তীভাবে ক্যাশে করা, দূরবর্তীভাবে কার্যকর করা বা স্যান্ডবক্সের ভিতরে চালানো থেকে বিরত রাখে। জেন্যুল এবং পরীক্ষার জন্য, local = True অ্যাট্রিবিউট দিয়ে নিয়ম চিহ্নিত করার একই প্রভাব রয়েছে।
  • requires-network কীওয়ার্ড স্যান্ডবক্সের ভিতর থেকে বাহ্যিক নেটওয়ার্কে অ্যাক্সেসের অনুমতি দেয়। স্যান্ডবক্সিং সক্ষম হলেই এই ট্যাগটির প্রভাব থাকে৷
  • block-network কীওয়ার্ড স্যান্ডবক্সের ভিতর থেকে বাহ্যিক নেটওয়ার্কে অ্যাক্সেস ব্লক করে। এই ক্ষেত্রে, শুধুমাত্র লোকালহোস্টের সাথে যোগাযোগ অনুমোদিত। স্যান্ডবক্সিং সক্ষম হলেই এই ট্যাগটির প্রভাব থাকে৷
  • requires-fakeroot পরীক্ষা বা কর্ম চালায় uid এবং gid 0 (অর্থাৎ, রুট ব্যবহারকারী)। এটি শুধুমাত্র লিনাক্সে সমর্থিত। এই ট্যাগটি --sandbox_fake_username কমান্ড-লাইন বিকল্পের উপর অগ্রাধিকার দেয়।

পরীক্ষার ট্যাগগুলি সাধারণত আপনার ডিবাগ এবং রিলিজ প্রক্রিয়ায় একটি পরীক্ষার ভূমিকা টীকা করতে ব্যবহৃত হয়। সাধারণত, ট্যাগগুলি C++ এবং পাইথন পরীক্ষার জন্য সবচেয়ে উপযোগী, যার কোনো রানটাইম টীকা করার ক্ষমতা নেই। ট্যাগ এবং আকারের উপাদানগুলির ব্যবহার কোডবেস চেক-ইন নীতির চারপাশে ভিত্তিক পরীক্ষার স্যুটগুলি একত্রিত করার ক্ষেত্রে নমনীয়তা দেয়।

Bazel পরীক্ষার চলমান আচরণ পরিবর্তন করে যদি এটি পরীক্ষার নিয়মের tags বৈশিষ্ট্যে নিম্নলিখিত কীওয়ার্ডগুলি খুঁজে পায়:

  • exclusive পরীক্ষাটিকে "এক্সক্লুসিভ" মোডে চালানোর জন্য বাধ্য করবে, এটি নিশ্চিত করে যে একই সময়ে অন্য কোনো পরীক্ষা চলছে না। সমস্ত বিল্ড অ্যাক্টিভিটি এবং অ-এক্সক্লুসিভ পরীক্ষা শেষ হওয়ার পরে এই ধরনের পরীক্ষাগুলি সিরিয়াল ফ্যাশনে সম্পাদিত হবে। এই ধরনের পরীক্ষার জন্য রিমোট এক্সিকিউশন অক্ষম করা হয়েছে কারণ রিমোট মেশিনে যা চলছে তার উপর Bazel-এর নিয়ন্ত্রণ নেই।
  • exclusive-if-local পরীক্ষাটিকে "এক্সক্লুসিভ" মোডে চালানোর জন্য বাধ্য করবে যদি এটি স্থানীয়ভাবে কার্যকর করা হয়, তবে দূরবর্তীভাবে চালানো হলে পরীক্ষাটি সমান্তরালভাবে চালাবে।
  • manual কীওয়ার্ড টার্গেট প্যাটার্ন ওয়াইল্ডকার্ড ( ... , :* , :all , ইত্যাদি) এবং test_suite নিয়মগুলির সম্প্রসারণ থেকে লক্ষ্যকে বাদ দেবে যা তৈরি/চালানোর জন্য শীর্ষ-স্তরের লক্ষ্যগুলির সেট গণনা করার সময় স্পষ্টভাবে পরীক্ষার তালিকা দেয় না build , test এবং coverage কমান্ড। এটি query কমান্ড সহ অন্যান্য প্রসঙ্গে টার্গেট ওয়াইল্ডকার্ড বা টেস্ট স্যুট সম্প্রসারণকে প্রভাবিত করে না। মনে রাখবেন যে manual বোঝায় না যে একটি টার্গেট ক্রমাগত বিল্ড/পরীক্ষা সিস্টেম দ্বারা স্বয়ংক্রিয়ভাবে তৈরি/চালানো উচিত নয়। উদাহরণস্বরূপ, bazel test ... কারণ এটির জন্য নির্দিষ্ট ব্যাজেল পতাকা প্রয়োজন, কিন্তু তারপরও এটি সঠিকভাবে কনফিগার করা প্রিসবমিট বা ক্রমাগত পরীক্ষা চালানোর মধ্যে অন্তর্ভুক্ত রয়েছে।
  • external কীওয়ার্ড পরীক্ষা নিঃশর্তভাবে কার্যকর করতে বাধ্য করবে ( --cache_test_results মান নির্বিশেষে)।
টেস্ট টার্গেটের সাথে সংযুক্ত ট্যাগ সংক্রান্ত আরও নিয়মাবলীর জন্য টেস্ট এনসাইক্লোপিডিয়ায় ট্যাগ কনভেনশন দেখুন।
target_compatible_with

List of labels ; optional

এই টার্গেটটিকে সামঞ্জস্যপূর্ণ বলে বিবেচনা করার জন্য লক্ষ্য প্ল্যাটফর্মে উপস্থিত থাকা আবশ্যক constraint_value এর একটি তালিকা। এটি নিয়মের ধরন দ্বারা ইতিমধ্যে সেট করা যেকোনো সীমাবদ্ধতা ছাড়াও। যদি লক্ষ্য প্ল্যাটফর্ম সমস্ত তালিকাভুক্ত সীমাবদ্ধতাগুলি পূরণ না করে তবে লক্ষ্যটি বেমানান বলে বিবেচিত হয়৷ যখন লক্ষ্য প্যাটার্নটি প্রসারিত হয় তখন বেমানান লক্ষ্যগুলি নির্মাণ এবং পরীক্ষার জন্য এড়িয়ে যায় (যেমন //... , :all )। কমান্ড লাইনে স্পষ্টভাবে নির্দিষ্ট করা হলে, বেমানান টার্গেটের কারণে Bazel একটি ত্রুটি প্রিন্ট করে এবং একটি বিল্ড বা পরীক্ষা ব্যর্থতার কারণ হয়।

যে টার্গেটগুলি ট্রানজিটিভভাবে বেমানান লক্ষ্যগুলির উপর নির্ভর করে সেগুলিকে বেমানান বলে মনে করা হয়। তারা বিল্ডিং এবং পরীক্ষার জন্য এড়িয়ে গেছে।

একটি খালি তালিকা (যা ডিফল্ট) নির্দেশ করে যে লক্ষ্যটি সমস্ত প্ল্যাটফর্মের সাথে সামঞ্জস্যপূর্ণ।

ওয়ার্কস্পেস নিয়ম ছাড়া অন্য সব নিয়ম এই বৈশিষ্ট্য সমর্থন করে। কিছু নিয়মের জন্য এই বৈশিষ্ট্যের কোন প্রভাব নেই। উদাহরণস্বরূপ, একটি cc_toolchain এর জন্য target_compatible_with নির্দিষ্ট করা কার্যকর নয়।

বেমানান টার্গেট এড়িয়ে যাওয়া সম্পর্কে আরও তথ্যের জন্য প্ল্যাটফর্ম পৃষ্ঠা দেখুন।

testonly

Boolean; optional; default False except for test and test suite targets; nonconfigurable

যদি সত্য হয়, শুধুমাত্র পরীক্ষামূলক লক্ষ্য (যেমন পরীক্ষা) এই লক্ষ্যের উপর নির্ভর করতে পারে।

testonly , একটি নিয়ম যা testonly নয় তা শুধুমাত্র পরীক্ষামূলক কোন নিয়মের উপর নির্ভর করার অনুমতি দেওয়া হয় না।

টেস্ট ( *_test নিয়ম) এবং টেস্ট স্যুট ( test_suite নিয়ম) শুধুমাত্র ডিফল্টরূপে testonly করা হয়।

এই অ্যাট্রিবিউটের উদ্দেশ্য হল যে টার্গেটটি বাইনারিগুলিতে থাকা উচিত নয় যা উত্পাদনের জন্য ছেড়ে দেওয়া হয়।

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

toolchains

List of labels ; optional; nonconfigurable

লক্ষ্যের সেট যার মেক ভেরিয়েবল এই টার্গেট অ্যাক্সেস করার অনুমতি দেওয়া হয়েছে। এই লক্ষ্যগুলি হয় নিয়মের উদাহরণ যা TemplateVariableInfo প্রদান করে বা Bazel-এ তৈরি টুলচেন প্রকারের জন্য বিশেষ লক্ষ্য। এর মধ্যে রয়েছে:

  • @bazel_tools//tools/cpp:current_cc_toolchain
  • @bazel_tools//tools/jdk:current_java_runtime

নোট করুন যে এটি টুলচেন রেজোলিউশনের ধারণা থেকে আলাদা যা প্ল্যাটফর্ম-নির্ভর কনফিগারেশনের জন্য নিয়ম বাস্তবায়ন দ্বারা ব্যবহৃত হয়। কোন নির্দিষ্ট cc_toolchain বা java_toolchain টার্গেট ব্যবহার করবে তা নির্ধারণ করতে আপনি এই বৈশিষ্ট্যটি ব্যবহার করতে পারবেন না।

visibility

List of labels ; optional; default default_visibility from package if specified, or //visibility:private otherwise; nonconfigurable

টার্গেটের visibility বৈশিষ্ট্য অন্য প্যাকেজে টার্গেট ব্যবহার করা যাবে কিনা তা নিয়ন্ত্রণ করে। দৃশ্যমানতার জন্য ডকুমেন্টেশন দেখুন।

সমস্ত পরীক্ষার নিয়মে সাধারণ বৈশিষ্ট্য (*_test)

এই বিভাগটি এমন বৈশিষ্ট্যগুলি বর্ণনা করে যা সমস্ত পরীক্ষার নিয়মগুলির জন্য সাধারণ৷

বৈশিষ্ট্য বর্ণনা
args

List of strings; optional; subject to $(location) and "Make variable" substitution, and Bourne shell tokenization

কমান্ড লাইন আর্গুমেন্ট করে যে Bazel টার্গেটে পাস করে যখন এটি bazel test মাধ্যমে কার্যকর করা হয়।

এই আর্গুমেন্টগুলি bazel test কমান্ড লাইনে নির্দিষ্ট করা যেকোনো --test_arg মানগুলির আগে পাস করা হয়।

env

Dictionary of strings; optional; values are subject to $(location) and "Make variable" substitution

bazel test দ্বারা পরীক্ষাটি চালানো হলে সেট করার জন্য অতিরিক্ত পরিবেশের ভেরিয়েবল নির্দিষ্ট করে।

এই বৈশিষ্ট্যটি শুধুমাত্র নেটিভ নিয়মে প্রযোজ্য, যেমন cc_test , py_test , এবং sh_test । এটা Starlark-সংজ্ঞায়িত পরীক্ষার নিয়ম প্রযোজ্য নয়. আপনার নিজের Starlark নিয়মের জন্য, আপনি একটি "env" অ্যাট্রিবিউট যোগ করতে পারেন এবং এটি একটি TestEnvironment প্রোভাইডার তৈরি করতে ব্যবহার করতে পারেন।

env_inherit

List of strings; optional

বহিরাগত পরিবেশ থেকে উত্তরাধিকার সূত্রে প্রাপ্ত অতিরিক্ত পরিবেশের ভেরিয়েবল নির্দিষ্ট করে যখন পরীক্ষাটি bazel test দ্বারা সম্পাদিত হয়।

এই বৈশিষ্ট্যটি শুধুমাত্র নেটিভ নিয়মে প্রযোজ্য, যেমন cc_test , py_test , এবং sh_test । এটা Starlark-সংজ্ঞায়িত পরীক্ষার নিয়ম প্রযোজ্য নয়.

size

String "enormous", "large" "medium" or "small", default is "medium"; optional; nonconfigurable

একটি পরীক্ষার লক্ষ্যের "ভারীতা" নির্দিষ্ট করে: এটি চালানোর জন্য কত সময়/সম্পদ প্রয়োজন।

ইউনিট পরীক্ষাগুলিকে "ছোট", ইন্টিগ্রেশন পরীক্ষাগুলি "মাঝারি" এবং শেষ থেকে শেষ পরীক্ষাগুলিকে "বড়" বা "বিশাল" হিসাবে বিবেচনা করা হয়। Bazel একটি ডিফল্ট টাইমআউট নির্ধারণ করতে আকার ব্যবহার করে, যা timeout বৈশিষ্ট্য ব্যবহার করে ওভাররাইড করা যেতে পারে। টাইমআউট BUILD টার্গেটের সমস্ত পরীক্ষার জন্য, প্রতিটি পৃথক পরীক্ষার জন্য নয়। যখন পরীক্ষাটি স্থানীয়ভাবে চালানো হয়, তখন size অতিরিক্ত সময় নির্ধারণের উদ্দেশ্যে ব্যবহার করা হয়: Bazel চেষ্টা করে --local_{ram,cpu}_resources কে সম্মান করার এবং একই সময়ে প্রচুর ভারী পরীক্ষা চালিয়ে স্থানীয় মেশিনকে অভিভূত না করে।

পরীক্ষার মাপ নিম্নোক্ত ডিফল্ট টাইমআউট এবং অনুমান করা সর্বোচ্চ স্থানীয় সম্পদ ব্যবহারের সাথে মিলে যায়:

আকার RAM (MB-এ) CPU (CPU কোরে) ডিফল্ট সময়সীমা
ছোট 20 1 সংক্ষিপ্ত (1 মিনিট)
মধ্যম 100 1 মাঝারি (5 মিনিট)
বড় 300 1 দীর্ঘ (15 মিনিট)
বিশাল 800 1 চিরন্তন (60 মিনিট)

এনভায়রনমেন্ট ভেরিয়েবল TEST_SIZE এই অ্যাট্রিবিউটের মানের সাথে সেট করা হবে যখন পরীক্ষাটি তৈরি করা হবে।

timeout

String "short", "moderate", "long", "eternal" (with the default derived from the test's size attribute); nonconfigurable

ফেরার আগে পরীক্ষা কতক্ষণ চলবে বলে আশা করা হচ্ছে।

যদিও একটি পরীক্ষার আকার বৈশিষ্ট্য সম্পদ অনুমান নিয়ন্ত্রণ করে, একটি পরীক্ষার সময়সীমা স্বাধীনভাবে সেট করা হতে পারে। যদি স্পষ্টভাবে নির্দিষ্ট না করা হয়, তাহলে সময়সীমা পরীক্ষার আকারের উপর ভিত্তি করে। পরীক্ষার সময়সীমা --test_timeout ফ্ল্যাগ দিয়ে ওভাররাইড করা যেতে পারে, যেমন কিছু নির্দিষ্ট অবস্থার অধীনে চালানোর জন্য যা ধীর বলে পরিচিত। পরীক্ষার টাইমআউট মানগুলি নিম্নলিখিত সময়ের সাথে সঙ্গতিপূর্ণ:

টাইমআউট মান সময় কাল
সংক্ষিপ্ত 1 মিনিট
মধ্যপন্থী 5 মিনিট
দীর্ঘ 15 মিনিট
চিরন্তন 60 মিনিট

উপরের ব্যতীত অন্য সময়ের জন্য, পরীক্ষার সময়সীমা --test_timeout বেজেল ফ্ল্যাগ দিয়ে ওভাররাইড করা যেতে পারে, যেমন ধীর বলে পরিচিত এমন পরিস্থিতিতে ম্যানুয়ালি চালানোর জন্য। --test_timeout মান সেকেন্ডে হয়। উদাহরণস্বরূপ --test_timeout=120 পরীক্ষার সময়সীমা দুই মিনিটে সেট করবে।

এনভায়রনমেন্ট ভেরিয়েবল TEST_TIMEOUT পরীক্ষার টাইমআউটে (সেকেন্ডে) সেট করা হবে যখন পরীক্ষাটি শুরু হবে।

flaky

Boolean; optional; default False; nonconfigurable

পরীক্ষাকে ফ্ল্যাকি হিসেবে চিহ্নিত করে।

সেট করা হলে, পরীক্ষাটি তিনবার পর্যন্ত চালায়, প্রতিবার ব্যর্থ হলেই এটিকে ব্যর্থ হিসেবে চিহ্নিত করে। ডিফল্টরূপে, এই বৈশিষ্ট্যটি False-এ সেট করা থাকে এবং পরীক্ষাটি শুধুমাত্র একবারই সম্পাদিত হয়। দ্রষ্টব্য, এই বৈশিষ্ট্যের ব্যবহারকে সাধারণত নিরুৎসাহিত করা হয় - যখন তাদের দাবিগুলি বহাল থাকে তখন পরীক্ষাগুলি নির্ভরযোগ্যভাবে পাস করা উচিত।

shard_count

Non-negative integer less than or equal to 50; optional

পরীক্ষা চালানোর জন্য ব্যবহার করার জন্য সমান্তরাল শার্ডের সংখ্যা নির্দিষ্ট করে।

এই মানটি পরীক্ষা চালানোর জন্য সমান্তরাল শার্ডের সংখ্যা নির্ধারণ করতে ব্যবহৃত যেকোন হিউরিস্টিকসকে ওভাররাইড করবে। মনে রাখবেন কিছু পরীক্ষার নিয়মের জন্য, প্রথমে শার্ডিং সক্ষম করতে এই প্যারামিটারের প্রয়োজন হতে পারে। এছাড়াও --test_sharding_strategy দেখুন।

যদি টেস্ট শার্ডিং সক্ষম করা থাকে, পরীক্ষাটি তৈরি করার সময় পরিবেশ পরিবর্তনশীল TEST_TOTAL_SHARDS এই মানটিতে সেট করা হবে৷

শার্ডিংয়ের জন্য টেস্ট রানারকে টেস্ট শার্ডিং প্রোটোকল সমর্থন করতে হবে। যদি এটি না হয়, তবে এটি সম্ভবত প্রতিটি শার্ডে প্রতিটি পরীক্ষা চালাবে, যা আপনি যা চান তা নয়।

শর্ডিংয়ের বিস্তারিত জানার জন্য টেস্ট এনসাইক্লোপিডিয়ায় টেস্ট শার্ডিং দেখুন।

local

Boolean; default False; nonconfigurable

স্যান্ডবক্সিং ছাড়াই স্থানীয়ভাবে পরীক্ষা চালাতে বাধ্য করে।

এটিকে সত্যে সেট করা "স্থানীয়" একটি ট্যাগ হিসাবে প্রদান করার সমতুল্য ( tags=["local"] )।

সমস্ত বাইনারি নিয়মে সাধারণ বৈশিষ্ট্য (*_binary)

এই বিভাগটি এমন বৈশিষ্ট্যগুলি বর্ণনা করে যা সমস্ত বাইনারি নিয়মে সাধারণ।

বৈশিষ্ট্য বর্ণনা
args

List of strings; optional; subject to $(location) and "Make variable" substitution, and Bourne shell tokenization ; nonconfigurable

কমান্ড লাইন আর্গুমেন্ট যে Bazel টার্গেট পাস হবে যখন এটি run কমান্ড দ্বারা বা একটি পরীক্ষা হিসাবে নির্বাহ করা হয়। এই আর্গুমেন্টগুলি bazel run বা bazel test কমান্ড লাইনে নির্দিষ্ট করাগুলির আগে পাস করা হয়।

দ্রষ্টব্য: আপনি যখন Bazel-এর বাইরে লক্ষ্যটি চালান তখন আর্গুমেন্টগুলি পাস হয় না (উদাহরণস্বরূপ, bazel-bin/ এ বাইনারিটি ম্যানুয়ালি চালানোর মাধ্যমে)।

env

Dictionary of strings; optional; values are subject to $(location) and "Make variable" substitution

bazel run দ্বারা লক্ষ্য নির্বাহ করা হলে সেট করার জন্য অতিরিক্ত পরিবেশ ভেরিয়েবল নির্দিষ্ট করে।

এই বৈশিষ্ট্যটি শুধুমাত্র নেটিভ নিয়মে প্রযোজ্য, যেমন cc_binary , py_binary , এবং sh_binary । এটা Starlark-সংজ্ঞায়িত এক্সিকিউটেবল নিয়মের ক্ষেত্রে প্রযোজ্য নয়।

দ্রষ্টব্য: আপনি যখন Bazel-এর বাইরে টার্গেট চালান তখন এনভায়রনমেন্ট ভেরিয়েবল সেট করা হয় না (উদাহরণস্বরূপ, bazel-bin/ এ বাইনারি ম্যানুয়ালি চালানোর মাধ্যমে)।

output_licenses

List of strings; optional

আউটপুট ফাইলের লাইসেন্স যা এই বাইনারি তৈরি করে। এটি একটি অপ্রচলিত লাইসেন্সিং API এর অংশ যা Bazel আর ব্যবহার করে না৷ এই ব্যবহার করবেন না.

কনফিগারযোগ্য বৈশিষ্ট্য

বেশিরভাগ গুণাবলী "কনফিগারযোগ্য" হয়, যার মানে লক্ষ্য ভিন্ন উপায়ে নির্মিত হলে তাদের মান পরিবর্তন হতে পারে। বিশেষত, Bazel কমান্ড লাইনে পাস করা পতাকার উপর ভিত্তি করে কনফিগারযোগ্য বৈশিষ্ট্যগুলি পরিবর্তিত হতে পারে, বা কোন ডাউনস্ট্রিম নির্ভরতা লক্ষ্যের জন্য অনুরোধ করছে। এটি ব্যবহার করা যেতে পারে, উদাহরণস্বরূপ, একাধিক প্ল্যাটফর্ম বা সংকলন মোডের লক্ষ্য কাস্টমাইজ করতে।

নিম্নলিখিত উদাহরণটি বিভিন্ন লক্ষ্য আর্কিটেকচারের জন্য বিভিন্ন উত্স ঘোষণা করে। bazel build :multiplatform_lib --cpu x86 x86_impl.cc ব্যবহার করে টার্গেট তৈরি করা হবে, যেখানে --cpu arm প্রতিস্থাপন করা হলে এটি arm_impl.cc ব্যবহার করবে।

cc_library(
    name = "multiplatform_lib",
    srcs = select({
        ":x86_mode": ["x86_impl.cc"],
        ":arm_mode": ["arm_impl.cc"]
    })
)
config_setting(
    name = "x86_mode",
    values = { "cpu": "x86" }
)
config_setting(
    name = "arm_mode",
    values = { "cpu": "arm" }
)

select() ফাংশন একটি কনফিগারযোগ্য অ্যাট্রিবিউটের জন্য বিভিন্ন বিকল্প মানের মধ্যে বেছে নেয় যার উপর ভিত্তি করে config_setting বা constraint_value মানদণ্ড লক্ষ্যের কনফিগারেশন সন্তুষ্ট হয়।

ব্যাজেল ম্যাক্রো প্রক্রিয়াকরণের পরে এবং প্রক্রিয়াকরণের নিয়মের আগে (প্রযুক্তিগতভাবে, লোডিং এবং বিশ্লেষণের পর্যায়গুলির মধ্যে) কনফিগারযোগ্য বৈশিষ্ট্যগুলি মূল্যায়ন করে। select() মূল্যায়নের আগে যে কোনো প্রক্রিয়াকরণ জানা যায় না যে Select select() কোন শাখা বেছে নেয়। ম্যাক্রো, উদাহরণস্বরূপ, নির্বাচিত শাখার উপর ভিত্তি করে তাদের আচরণ পরিবর্তন করতে পারে না, এবং bazel query শুধুমাত্র একটি লক্ষ্যের কনফিগারযোগ্য নির্ভরতা সম্পর্কে রক্ষণশীল অনুমান করতে পারে। নিয়ম এবং ম্যাক্রো সহ select() ব্যবহার করার বিষয়ে আরও জানতে এই FAQ দেখুন।

তাদের ডকুমেন্টেশনে অ- nonconfigurable বৈশিষ্ট্যগুলি এই বৈশিষ্ট্যটি ব্যবহার করতে পারে না। সাধারণত একটি অ্যাট্রিবিউট অ-কনফিগার করা যায় না কারণ একটি select() কিভাবে সমাধান করতে হয় তা নির্ধারণ করার আগে Bazel-এর অভ্যন্তরীণভাবে এর মান জানতে হবে।

বিস্তারিত ওভারভিউয়ের জন্য কনফিগারযোগ্য বিল্ড অ্যাট্রিবিউট দেখুন।

অন্তর্নিহিত আউটপুট লক্ষ্য

C++ এর অন্তর্নিহিত আউটপুটগুলিকে অবমূল্যায়ন করা হয়েছে। যেখানে সম্ভব অন্য ভাষায় এটি ব্যবহার করা থেকে বিরত থাকুন। আমাদের কাছে এখনও অবচয়নের পথ নেই তবে শেষ পর্যন্ত সেগুলিও অবমূল্যায়িত হবে৷

যখন আপনি একটি বিল্ড ফাইলে একটি বিল্ড নিয়ম সংজ্ঞায়িত করেন, আপনি স্পষ্টভাবে একটি প্যাকেজে একটি নতুন, নামকৃত নিয়ম লক্ষ্য ঘোষণা করছেন। অনেক বিল্ড রুল ফাংশনও এক বা একাধিক আউটপুট ফাইল টার্গেটকে অন্তর্নিহিত করে, যার বিষয়বস্তু এবং অর্থ নিয়ম-নির্দিষ্ট। উদাহরণস্বরূপ, আপনি যখন স্পষ্টভাবে একটি java_binary(name='foo', ...) নিয়ম ঘোষণা করেন, তখন আপনি একই প্যাকেজের সদস্য হিসাবে একটি আউটপুট ফাইল লক্ষ্য foo_deploy.jar- কে foo_deploy.jar ঘোষণা করছেন। (এই বিশেষ লক্ষ্যটি স্থাপনার জন্য উপযুক্ত একটি স্বয়ংসম্পূর্ণ জাভা সংরক্ষণাগার।)

অন্তর্নিহিত আউটপুট লক্ষ্যগুলি বিশ্বব্যাপী লক্ষ্য গ্রাফের প্রথম শ্রেণীর সদস্য। অন্যান্য লক্ষ্যমাত্রার মতো, এগুলি চাহিদার ভিত্তিতে তৈরি করা হয়, হয় যখন শীর্ষ-স্তরের বিল্ট কমান্ডে নির্দিষ্ট করা হয়, অথবা যখন তারা অন্যান্য বিল্ড লক্ষ্যগুলির জন্য প্রয়োজনীয় পূর্বশর্ত। এগুলিকে বিল্ড ফাইলগুলিতে নির্ভরতা হিসাবে উল্লেখ করা যেতে পারে এবং বিশ্লেষণ সরঞ্জামগুলির আউটপুটে যেমন bazel query লক্ষ্য করা যেতে পারে।

প্রতিটি ধরনের বিল্ড নিয়মের জন্য, নিয়মের ডকুমেন্টেশনে একটি বিশেষ বিভাগ রয়েছে যা সেই ধরনের নিয়মের ঘোষণা দ্বারা প্রযোজিত কোনো অন্তর্নিহিত আউটপুটের নাম এবং বিষয়বস্তু বিশদ বিবরণ দেয়।

বিল্ড সিস্টেম দ্বারা ব্যবহৃত দুটি নেমস্পেসের মধ্যে একটি গুরুত্বপূর্ণ কিন্তু কিছুটা সূক্ষ্ম পার্থক্য: লেবেল লক্ষ্যগুলি সনাক্ত করে, যা নিয়ম বা ফাইল হতে পারে এবং ফাইল লক্ষ্যগুলিকে উৎস (বা ইনপুট) ফাইল লক্ষ্য এবং প্রাপ্ত (বা আউটপুট) ফাইল লক্ষ্যে ভাগ করা যেতে পারে . এই জিনিসগুলি আপনি BUILD ফাইলে উল্লেখ করতে পারেন, কমান্ড-লাইন থেকে তৈরি করতে পারেন, বা bazel query ব্যবহার করে পরীক্ষা করতে পারেন; এই টার্গেট নেমস্পেস । প্রতিটি ফাইল টার্গেট ডিস্কের একটি প্রকৃত ফাইলের সাথে মিলে যায় ("ফাইল সিস্টেম নামস্থান"); প্রতিটি নিয়ম লক্ষ্য ডিস্কের শূন্য, এক বা একাধিক প্রকৃত ফাইলের সাথে মিলিত হতে পারে। ডিস্কে এমন ফাইল থাকতে পারে যেগুলোর কোনো সংশ্লিষ্ট লক্ষ্য নেই; উদাহরণস্বরূপ, C++ সংকলনের সময় উত্পাদিত .o অবজেক্ট ফাইলগুলি BUILD ফাইলের মধ্যে বা কমান্ড লাইন থেকে উল্লেখ করা যাবে না। এইভাবে, বিল্ড টুলটি কীভাবে এটির কাজ করে তার কিছু বাস্তবায়ন বিবরণ লুকিয়ে রাখতে পারে। এটি বিল্ড কনসেপ্ট রেফারেন্সে আরও সম্পূর্ণভাবে ব্যাখ্যা করা হয়েছে।