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

সপ্তাহের দিন

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

নিয়ম

উপনাম

alias(name, actual, compatible_with, deprecation, features, restricted_to, tags, target_compatible_with, testonly, visibility)

alias নিয়ম অন্য একটি নাম তৈরি করে যা একটি নিয়ম হিসাবে উল্লেখ করা যেতে পারে।

অ্যালিয়াসিং শুধুমাত্র "নিয়মিত" লক্ষ্যগুলির জন্য কাজ করে। বিশেষ করে, package_group এবং test_suite করা যাবে না।

উপনাম নিয়মের নিজস্ব দৃশ্যমানতা ঘোষণা আছে। অন্য সব ক্ষেত্রে, এটি যে নিয়মটি উল্লেখ করে তার মতো আচরণ করে (উদাহরণস্বরূপ শুধুমাত্র উপনামের উপর testonly উপেক্ষা করা হয়; এর পরিবর্তে উল্লেখিত নিয়মের testonly-ness ব্যবহার করা হয়) কিছু ছোটখাটো ব্যতিক্রম সহ:

  • কমান্ড লাইনে তাদের উপনাম উল্লেখ করা থাকলে পরীক্ষা চালানো হয় না। একটি উপনাম সংজ্ঞায়িত করতে যা রেফারেন্স করা পরীক্ষা চালায়, একটি test_suite নিয়ম ব্যবহার করুন যার tests অ্যাট্রিবিউটে একটি টার্গেট আছে।
  • পরিবেশের গোষ্ঠীগুলিকে সংজ্ঞায়িত করার সময়, environment নিয়মগুলির উপনামগুলি সমর্থিত নয়৷ এগুলি --target_environment কমান্ড লাইন বিকল্পেও সমর্থিত নয়।

উদাহরণ

filegroup(
    name = "data",
    srcs = ["data.txt"],
)

alias(
    name = "other",
    actual = ":data",
)

যুক্তি

গুণাবলী
name

Name ; required

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

actual

Label ; required

লক্ষ্য এই উপনাম বোঝায়. এটি একটি নিয়ম হওয়ার দরকার নেই, এটি একটি ইনপুট ফাইলও হতে পারে।

config_setting

config_setting(name, constraint_values, define_values, deprecation, distribs, features, flag_values, licenses, tags, testonly, values, visibility)

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

উদাহরণ

নিম্নলিখিতগুলি যে কোনও বিল্ডের সাথে মেলে যা --compilation_mode=opt বা -c opt সেট করে (হয় স্পষ্টভাবে কমান্ড লাইনে বা .bazelrc ফাইল থেকে স্পষ্টভাবে):

  config_setting(
      name = "simple",
      values = {"compilation_mode": "opt"}
  )
  

নিম্নলিখিতগুলি যেকোন বিল্ডের সাথে মেলে যা এআরএমকে লক্ষ্য করে এবং কাস্টম ডিফাইন FOO=bar প্রয়োগ করে (উদাহরণস্বরূপ, bazel build --cpu=arm --define FOO=bar ... ):

  config_setting(
      name = "two_conditions",
      values = {
          "cpu": "arm",
          "define": "FOO=bar"
      }
  )
  

নিম্নলিখিত যে কোনো বিল্ডের সাথে মেলে যা ব্যবহারকারী-নির্ধারিত পতাকা সেট করে --//custom_flags:foo=1 (হয় স্পষ্টভাবে কমান্ড লাইনে বা .bazelrc ফাইল থেকে স্পষ্টভাবে):

  config_setting(
      name = "my_custom_flag_is_set",
      flag_values = { "//custom_flags:foo": "1" },
  )
  

নিম্নলিখিতটি যেকোন বিল্ডের সাথে মেলে যা একটি x86_64 আর্কিটেকচার এবং glibc সংস্করণ 2.25 সহ একটি প্ল্যাটফর্মকে লক্ষ্য করে, লেবেল //example:glibc_2_25 সহ একটি constraint_value এর অস্তিত্ব অনুমান করে। মনে রাখবেন যে একটি প্ল্যাটফর্ম এখনও মেলে যদি এটি এই দুটির বাইরে অতিরিক্ত সীমাবদ্ধতার মান নির্ধারণ করে।

  config_setting(
      name = "64bit_glibc_2_25",
      constraint_values = [
          "@platforms//cpu:x86_64",
          "//example:glibc_2_25",
      ]
  )
  
এই সমস্ত ক্ষেত্রে, বিল্ডের মধ্যে কনফিগারেশন পরিবর্তন করা সম্ভব, উদাহরণস্বরূপ যদি একটি টার্গেট এর ডিপ থেকে ভিন্ন প্ল্যাটফর্মের জন্য তৈরি করা প্রয়োজন। এর মানে হল যে এমনকি যখন একটি config_setting শীর্ষ-স্তরের কমান্ড-লাইন পতাকার সাথে মেলে না, তবুও এটি কিছু বিল্ড লক্ষ্যের সাথে মেলে।

মন্তব্য

  • একাধিক config_setting বর্তমান কনফিগারেশন অবস্থার সাথে মেলে তখন কি হয় তার জন্য নির্বাচন দেখুন।
  • শর্টহ্যান্ড ফর্মগুলিকে সমর্থন করে এমন পতাকার জন্য (যেমন --compilation_mode বনাম -c ), values সংজ্ঞাগুলি অবশ্যই সম্পূর্ণ ফর্ম ব্যবহার করবে। যেকোনও ফর্ম ব্যবহার করে এইগুলি স্বয়ংক্রিয়ভাবে আমন্ত্রণের সাথে মেলে।
  • যদি একটি পতাকা একাধিক মান গ্রহণ করে (যেমন --copt=-Da --copt=-Db বা একটি তালিকা-টাইপ করা Starlark পতাকা ), values = { "flag": "a" } মেলে যদি "a" এর যেকোনো জায়গায় থাকে প্রকৃত তালিকা।

    values = { "myflag": "a,b" } একইভাবে কাজ করে: এটি মেলে --myflag=a --myflag=b , --myflag=a --myflag=b --myflag=c , --myflag=a,b , এবং --myflag=c,b,a । সঠিক শব্দার্থবিদ্যা পতাকার মধ্যে পরিবর্তিত হয়। উদাহরণস্বরূপ, --copt একই উদাহরণে একাধিক মান সমর্থন করে না: --copt=a,b উৎপন্ন করে ["a,b"] যখন --copt=a --copt=b উৎপন্ন করে ["a", "b"] (তাই values = { "copt": "a,b" } আগেরটির সাথে মেলে কিন্তু পরেরটির সাথে নয়)। কিন্তু --ios_multi_cpus (অ্যাপলের নিয়মের জন্য) করে : -ios_multi_cpus=a,b এবং ios_multi_cpus=a --ios_multi_cpus=b উভয়ই ["a", "b"] উৎপন্ন করে। পতাকা সংজ্ঞা পরীক্ষা করুন এবং সঠিক প্রত্যাশা যাচাই করতে সাবধানে আপনার শর্ত পরীক্ষা করুন.

  • আপনি যদি এমন শর্তগুলি সংজ্ঞায়িত করতে চান যেগুলি অন্তর্নির্মিত বিল্ড পতাকাগুলির দ্বারা মডেল করা হয় না, স্টারলার্ক-সংজ্ঞায়িত পতাকা ব্যবহার করুন। আপনি --define ব্যবহার করতে পারেন, তবে এটি দুর্বল সমর্থন প্রদান করে এবং সুপারিশ করা হয় না। আরো আলোচনার জন্য এখানে দেখুন.
  • বিভিন্ন প্যাকেজে অভিন্ন config_setting সংজ্ঞা পুনরাবৃত্তি করা এড়িয়ে চলুন। পরিবর্তে, একটি সাধারণ config_setting উল্লেখ করুন যা একটি ক্যানোনিকাল প্যাকেজে সংজ্ঞায়িত করা হয়েছে।
  • values , define_values ​​, এবং constraint_values ​​একই config_setting এ যেকোনো সংমিশ্রণে ব্যবহার করা যেতে পারে তবে যে কোনো প্রদত্ত config_setting জন্য অন্তত একটি সেট করতে হবে।

যুক্তি

গুণাবলী
name

Name ; required

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

constraint_values

List of labels ; optional; nonconfigurable

এই config_setting এর সাথে মেলানোর জন্য লক্ষ্য প্ল্যাটফর্মকে অবশ্যই নির্দিষ্ট করতে হবে constraint_values ন্যূনতম সেট। (এখানে এক্সিকিউশন প্ল্যাটফর্ম বিবেচনা করা হয় না।) প্ল্যাটফর্মের যে কোনো অতিরিক্ত সীমাবদ্ধতা মান উপেক্ষা করা হয়। বিস্তারিত জানার জন্য কনফিগারযোগ্য বিল্ড অ্যাট্রিবিউট দেখুন।

যে ক্ষেত্রে দুটি config_setting উভয়ই একই select সাথে মিলে যায়, এই বৈশিষ্ট্যটি config_setting s-এর মধ্যে একটি অন্যটির একটি বিশেষীকরণ কিনা তা নির্ধারণের উদ্দেশ্যে বিবেচনা করা হয় না। অন্য কথায়, একটি config_setting একটি প্ল্যাটফর্মের সাথে অন্যটির চেয়ে বেশি দৃঢ়ভাবে মেলে না।

define_values

Dictionary: String -> String; optional; nonconfigurable

values মতই কিন্তু বিশেষভাবে --define পতাকার জন্য।

--define বিশেষ কারণ এর সিনট্যাক্স ( --define KEY=VAL ) মানে KEY=VAL হল একটি Bazel ফ্ল্যাগ দৃষ্টিকোণ থেকে একটি মান

মানে:

            config_setting(
                name = "a_and_b",
                values = {
                    "define": "a=1",
                    "define": "b=2",
                })
          

কাজ করে না কারণ অভিধানে একই কী ( define করুন) দুবার উপস্থিত হয়। এই বৈশিষ্ট্যটি সেই সমস্যার সমাধান করে:

            config_setting(
                name = "a_and_b",
                define_values = {
                    "a": "1",
                    "b": "2",
                })
          

সঠিকভাবে bazel build //foo --define a=1 --define b=2

--define এখনও সাধারণ ফ্ল্যাগ সিনট্যাক্স সহ values উপস্থিত হতে পারে এবং এই বৈশিষ্ট্যের সাথে অবাধে মিশ্রিত করা যেতে পারে যতক্ষণ না অভিধান কীগুলি স্বতন্ত্র থাকে।

flag_values

Dictionary: label -> String; optional; nonconfigurable

values হিসাবে একই কিন্তু ব্যবহারকারী-সংজ্ঞায়িত বিল্ড পতাকাগুলির জন্য।

এটি একটি স্বতন্ত্র বৈশিষ্ট্য কারণ ব্যবহারকারী-সংজ্ঞায়িত পতাকাগুলিকে লেবেল হিসাবে উল্লেখ করা হয় যখন অন্তর্নির্মিত পতাকাগুলি নির্বিচারে স্ট্রিং হিসাবে উল্লেখ করা হয়৷

values

Dictionary: String -> String; optional; nonconfigurable

কনফিগারেশন মানগুলির সেট যা এই নিয়মের সাথে মেলে (বিল্ড ফ্ল্যাগ হিসাবে প্রকাশ করা হয়)

এই নিয়মটি কনফিগার করা লক্ষ্যের কনফিগারেশনের উত্তরাধিকারসূত্রে প্রাপ্ত হয় যা এটিকে একটি select বিবৃতিতে উল্লেখ করে। এটি একটি Bazel আমন্ত্রণকে "মিল" বলে মনে করা হয় যদি, অভিধানে প্রতিটি এন্ট্রির জন্য, এর কনফিগারেশন এন্ট্রির প্রত্যাশিত মানের সাথে মেলে। উদাহরণ স্বরূপ values = {"compilation_mode": "opt"} টার্গেট-কনফিগার করা নিয়মে bazel build --compilation_mode=opt ... এবং bazel build -c opt ... এর সাথে মেলে।

সুবিধার জন্য, কনফিগারেশন মানগুলি বিল্ড পতাকা হিসাবে নির্দিষ্ট করা হয়েছে (পূর্ববর্তী "--" ছাড়া)। তবে মনে রাখবেন যে দুটি এক নয়। এর কারণ একই বিল্ডের মধ্যে একাধিক কনফিগারেশনে লক্ষ্যগুলি তৈরি করা যেতে পারে। উদাহরণস্বরূপ, একটি হোস্ট কনফিগারেশনের "cpu" --cpu --host_cpu । তাই একই config_setting এর বিভিন্ন দৃষ্টান্ত একই আমন্ত্রণের সাথে ভিন্নভাবে মিলতে পারে তাদের ব্যবহার করে নিয়মের কনফিগারেশনের উপর নির্ভর করে।

যদি একটি পতাকা কমান্ড লাইনে স্পষ্টভাবে সেট করা না থাকে, তবে এর ডিফল্ট মান ব্যবহার করা হয়। অভিধানে একটি কী একাধিকবার উপস্থিত হলে, শুধুমাত্র শেষ উদাহরণটি ব্যবহার করা হয়। যদি একটি কী এমন একটি পতাকা উল্লেখ করে যা কমান্ড লাইনে একাধিকবার সেট করা যেতে পারে (যেমন bazel build --copt=foo --copt=bar --copt=baz ... ), এই সেটিংসগুলির যে কোনো একটি মিলে গেলে একটি মিল ঘটে।

ফাইলগ্রুপ

filegroup(name, srcs, data, compatible_with, deprecation, distribs, features, licenses, output_group, restricted_to, tags, target_compatible_with, testonly, visibility)

টার্গেটের সংগ্রহে একটি সুবিধাজনক নাম দিতে filegroup ব্যবহার করুন। এইগুলি তারপর অন্যান্য নিয়ম থেকে উল্লেখ করা যেতে পারে.

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

উদাহরণ

দুটি উৎস ফাইলের সমন্বয়ে একটি filegroup তৈরি করতে, করুন

filegroup(
    name = "mygroup",
    srcs = [
        "a_file.txt",
        "some/subdirectory/another_file.txt",
    ],
)

অথবা, একটি glob ডিরেক্টরি তৈরি করতে একটি গ্লোব ব্যবহার করুন:

filegroup(
    name = "exported_testdata",
    srcs = glob([
        "testdata/*.dat",
        "testdata/logs/**/*.log",
    ]),
)

এই সংজ্ঞাগুলি ব্যবহার করতে, যেকোনো নিয়ম থেকে একটি লেবেল সহ filegroup উল্লেখ করুন:

cc_library(
    name = "my_library",
    srcs = ["foo.cc"],
    data = [
        "//my_package:exported_testdata",
        "//my_package:mygroup",
    ],
)

যুক্তি

গুণাবলী
name

Name ; required

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

srcs

List of labels ; optional

টার্গেটের তালিকা যারা ফাইল গ্রুপের সদস্য।

srcs অ্যাট্রিবিউটের মানের জন্য একটি srcs এক্সপ্রেশনের ফলাফল ব্যবহার করা সাধারণ।

data

List of labels ; optional

রানটাইমে এই নিয়মের জন্য প্রয়োজনীয় ফাইলের তালিকা।

data অ্যাট্রিবিউটে নাম দেওয়া লক্ষ্যগুলি এই filegroup নিয়মের runfiles যোগ করা হবে। যখন filegroup অন্য নিয়মের data অ্যাট্রিবিউটে উল্লেখ করা হয় তখন এর runfiles নির্ভরশীল নিয়মের runfiles যোগ করা হবে। ডেটা নির্ভরতা বিভাগ এবং ডেটা ফাইলগুলির উপর নির্ভর এবং ব্যবহার করার বিষয়ে আরও তথ্যের জন্য data সাধারণ ডকুমেন্টেশন দেখুন।

output_group

String; optional

যে আউটপুট গ্রুপ থেকে উৎস থেকে শিল্পকর্ম সংগ্রহ করা হবে। যদি এই বৈশিষ্ট্যটি নির্দিষ্ট করা থাকে, ডিফল্ট আউটপুট গোষ্ঠীর পরিবর্তে নির্ভরতার নির্দিষ্ট আউটপুট গ্রুপ থেকে আর্টিফ্যাক্টগুলি রপ্তানি করা হবে।

একটি "আউটপুট গ্রুপ" হল একটি লক্ষ্যের আউটপুট আর্টিফ্যাক্টের একটি বিভাগ, যে নিয়মের বাস্তবায়নে নির্দিষ্ট করা হয়েছে।

genquery

genquery(name, deps, data, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, expression, features, licenses, opts, restricted_to, scope, strict, tags, target_compatible_with, testonly, visibility)

genquery() ব্লেজ কোয়েরি ভাষায় নির্দিষ্ট করা একটি কোয়েরি চালায় এবং ফলাফলটিকে একটি ফাইলে ডাম্প করে।

বিল্ডকে সামঞ্জস্যপূর্ণ রাখার জন্য, scope অ্যাট্রিবিউটে নির্দিষ্ট করা লক্ষ্যগুলির ট্রানজিটিভ ক্লোজার দেখার জন্য ক্যোয়ারীটি অনুমোদিত। এই নিয়ম লঙ্ঘন করা প্রশ্নগুলি কার্যকর করার সময় ব্যর্থ হবে যদি strict অনির্দিষ্ট বা সত্য হয় (যদি strict মিথ্যা হয়, তবে সুযোগের বাইরের লক্ষ্যগুলি কেবল একটি সতর্কতার সাথে এড়িয়ে যাবে)। এটি যাতে না ঘটে তা নিশ্চিত করার সবচেয়ে সহজ উপায় হল কোয়েরি এক্সপ্রেশনের মতো স্কোপে একই লেবেল উল্লেখ করা।

এখানে এবং কমান্ড লাইনে অনুমোদিত প্রশ্নের মধ্যে একমাত্র পার্থক্য হল যে ওয়াইল্ডকার্ড টার্গেট স্পেসিফিকেশন (যেমন //pkg:* বা //pkg:all ) সম্বলিত প্রশ্নগুলি এখানে অনুমোদিত নয়। এর কারণগুলি দ্বিগুণ: প্রথমত, কারণ genquery আউটপুটকে প্রভাবিত করার জন্য কোয়েরির ট্রানজিটিভ ক্লোজারের বাইরে লক্ষ্যগুলি প্রতিরোধ করার জন্য একটি সুযোগ নির্দিষ্ট করতে হবে; এবং, দ্বিতীয়, কারণ BUILD ফাইলগুলি ওয়াইল্ডকার্ড নির্ভরতা সমর্থন করে না (যেমন deps=["//a/..."] অনুমোদিত নয়)।

ডিটারমিনিস্টিক আউটপুট প্রয়োগ করার জন্য genquery-এর আউটপুট --order_output=full ব্যবহার করে অর্ডার করা হয়।

আউটপুট ফাইলের নাম হল নিয়মের নাম।

উদাহরণ

এই উদাহরণটি একটি ফাইলে নির্দিষ্ট টার্গেটের ট্রানজিটিভ ক্লোজারে লেবেলের তালিকা লিখে।

genquery(
    name = "kiwi-deps",
    expression = "deps(//kiwi:kiwi_lib)",
    scope = ["//kiwi:kiwi_lib"],
)

যুক্তি

গুণাবলী
name

Name ; required

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

expression

String; required

যে প্রশ্নটি চালানো হবে। কমান্ড লাইন এবং BUILD ফাইলের অন্যান্য স্থানের বিপরীতে, এখানে লেবেলগুলি ওয়ার্কস্পেসের রুট ডিরেক্টরির সাপেক্ষে সমাধান করা হয়েছে। উদাহরণস্বরূপ, a/BUILD ফাইলের এই বৈশিষ্ট্যের লেবেল :b টার্গেট //:b উল্লেখ করবে।
opts

List of strings; optional

যে বিকল্পগুলি কোয়েরি ইঞ্জিনে পাস করা হয়। এগুলি কমান্ড লাইনের বিকল্পগুলির সাথে সঙ্গতিপূর্ণ যা bazel query পাস করা যেতে পারে। কিছু ক্যোয়ারী বিকল্প এখানে অনুমোদিত নয়: --keep_going , --query_file , --universe_scope , --order_results এবং --order_output । এখানে উল্লেখ করা হয়নি এমন বিকল্পগুলির ডিফল্ট মান থাকবে ঠিক যেমন bazel query কমান্ড লাইনে।
scope

null; required

প্রশ্নের সুযোগ। এই লক্ষ্যগুলির ট্রানজিটিভ ক্লোজারের বাইরে কোয়েরিটি লক্ষ্যগুলি স্পর্শ করার অনুমতি নেই৷
strict

Boolean; optional; default is True

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

রীতি

genrule(name, srcs, outs, cmd, cmd_bash, cmd_bat, cmd_ps, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, exec_tools, executable, features, licenses, local, message, output_licenses, output_to_bindir, restricted_to, tags, target_compatible_with, testonly, toolchains, tools, visibility)

একটি genrule একটি ব্যবহারকারী-সংজ্ঞায়িত Bash কমান্ড ব্যবহার করে এক বা একাধিক ফাইল তৈরি করে।

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

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

ক্রস-সংকলন বিবেচনা

ক্রস-সংকলন সম্পর্কে আরও তথ্যের জন্য ব্যবহারকারী ম্যানুয়াল দেখুন।

বিল্ডের সময় জেনরুলগুলি চালানোর সময়, তাদের আউটপুটগুলি প্রায়শই বিল্ডের পরে, স্থাপনা বা পরীক্ষার জন্য ব্যবহার করা হয়। একটি মাইক্রোকন্ট্রোলারের জন্য সি কোড কম্পাইল করার উদাহরণটি বিবেচনা করুন: কম্পাইলার সি সোর্স ফাইল গ্রহণ করে এবং একটি মাইক্রোকন্ট্রোলারে চলে এমন কোড তৈরি করে। উত্পন্ন কোড স্পষ্টতই CPU-তে চলতে পারে না যা এটি নির্মাণের জন্য ব্যবহৃত হয়েছিল, তবে C কম্পাইলার (যদি উত্স থেকে সংকলিত হয়) নিজেই করতে হবে।

বিল্ড সিস্টেম হোস্ট কনফিগারেশন ব্যবহার করে মেশিন(গুলি) বর্ণনা করতে যার উপর বিল্ড চলে এবং লক্ষ্য কনফিগারেশন ব্যবহার করে মেশিন(গুলি) বর্ণনা করার জন্য যার উপর বিল্ডের আউটপুট চালানোর কথা। এটি এইগুলির প্রতিটি কনফিগার করার বিকল্পগুলি প্রদান করে এবং এটি দ্বন্দ্ব এড়াতে সংশ্লিষ্ট ফাইলগুলিকে পৃথক ডিরেক্টরিতে বিভক্ত করে।

জেনরুলের জন্য, বিল্ড সিস্টেম নিশ্চিত করে যে নির্ভরতাগুলি যথাযথভাবে তৈরি করা হয়েছে: লক্ষ্য কনফিগারেশনের জন্য srcs তৈরি করা হয় (যদি প্রয়োজন হয়), হোস্ট কনফিগারেশনের জন্য tools তৈরি করা হয়, এবং আউটপুটকে লক্ষ্য কনফিগারেশনের জন্য বিবেচনা করা হয়। এটি "মেক" ভেরিয়েবলও সরবরাহ করে যা জেনরুল কমান্ডগুলি সংশ্লিষ্ট সরঞ্জামগুলিতে পাস করতে পারে।

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

বিশেষ ক্ষেত্রে

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

JDK এবং C++ টুলিং : JDK বা C++ কম্পাইলার স্যুট থেকে একটি টুল ব্যবহার করতে, বিল্ড সিস্টেম ব্যবহার করার জন্য ভেরিয়েবলের একটি সেট প্রদান করে। বিস্তারিত জানার জন্য "বানান" ভেরিয়েবল দেখুন।

জেনরুল এনভায়রনমেন্ট

genrule কমান্ডটি একটি Bash শেল দ্বারা নির্বাহ করা হয় যা set -e -o pipefail ব্যবহার করে একটি কমান্ড বা পাইপলাইন ব্যর্থ হলে ব্যর্থ হওয়ার জন্য কনফিগার করা হয়।

বিল্ড টুলটি একটি স্যানিটাইজড প্রসেস এনভায়রনমেন্টে ব্যাশ কমান্ড চালায় যা শুধুমাত্র PATH , PWD , TMPDIR , এবং আরও কয়েকটির মতো মূল ভেরিয়েবলগুলিকে সংজ্ঞায়িত করে৷ বিল্ডগুলি পুনরুত্পাদনযোগ্য তা নিশ্চিত করার জন্য, ব্যবহারকারীর শেল পরিবেশে সংজ্ঞায়িত বেশিরভাগ ভেরিয়েবলগুলি জেনরুলের কমান্ডে পাস করা হয় না। যাইহোক, ব্যাজেল (কিন্তু ব্লেজ নয়) ব্যবহারকারীর PATH এনভায়রনমেন্ট ভেরিয়েবলের মান দিয়ে যায়। PATH এর মান পরিবর্তনের ফলে Bazel পরবর্তী বিল্ডে কমান্ডটি পুনরায় কার্যকর করবে।

একটি genrule কমান্ড নেটওয়ার্কে প্রবেশ করা উচিত নয় শুধুমাত্র কমান্ডের সন্তান, যদিও এটি বর্তমানে প্রয়োগ করা হয়নি।

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

সাধারণ উপদেশ

  • নিশ্চিত করুন যে একটি জেনরুল দ্বারা চালিত সরঞ্জামগুলি নির্ধারক এবং হারমেটিক। তাদের আউটপুটে টাইমস্ট্যাম্প লেখা উচিত নয়, এবং তাদের সেট এবং মানচিত্রের জন্য স্থিতিশীল ক্রম ব্যবহার করা উচিত, সেইসাথে আউটপুটে শুধুমাত্র আপেক্ষিক ফাইল পাথ লেখা উচিত, কোনো পরম পাথ নয়। এই নিয়মটি অনুসরণ না করা অপ্রত্যাশিত বিল্ড আচরণের দিকে পরিচালিত করবে (ব্যাজেল এমন একটি জেনরুল পুনর্নির্মাণ করছে না যা আপনি ভেবেছিলেন) এবং ক্যাশে কর্মক্ষমতা হ্রাস পাবে।
  • আউটপুট, সরঞ্জাম এবং উত্সের জন্য $(location) ব্যাপকভাবে ব্যবহার করুন। বিভিন্ন কনফিগারেশনের জন্য আউটপুট ফাইলের পৃথকীকরণের কারণে, জেরুলগুলি হার্ড-কোডেড এবং/অথবা পরম পাথের উপর নির্ভর করতে পারে না।
  • একটি সাধারণ স্টারলার্ক ম্যাক্রো লিখুন যদি একই বা খুব অনুরূপ জেনরুল একাধিক জায়গায় ব্যবহার করা হয়। ধরণটি জটিল হলে, এটিকে স্ক্রিপ্টে বা স্টারলার্ক নিয়ম হিসাবে প্রয়োগ করার কথা বিবেচনা করুন। এটি পঠনযোগ্যতার পাশাপাশি পরীক্ষাযোগ্যতা উন্নত করে।
  • নিশ্চিত করুন যে প্রস্থান কোড সঠিকভাবে জেনরুলের সাফল্য বা ব্যর্থতা নির্দেশ করে।
  • stdout বা stderr-এ তথ্যমূলক বার্তা লিখবেন না। ডিবাগিংয়ের জন্য দরকারী হলেও, এটি সহজেই শব্দ হয়ে উঠতে পারে; একটি সফল রীতি নীরব হওয়া উচিত। অন্যদিকে, একটি ব্যর্থ জেনরুল ভাল ত্রুটি বার্তা নির্গত করা উচিত।
  • $$ evaluates to a $, a literal dollar-sign, so in order to invoke a shell command containing dollar-signs such as ls $(dirname $x), one must escape it thus: ls $$(dirname $$x)
  • সিমলিংক এবং ডিরেক্টরি তৈরি করা এড়িয়ে চলুন। Bazel জেনরুল দ্বারা তৈরি ডিরেক্টরি/সিমলিংক কাঠামোর উপর অনুলিপি করে না এবং ডিরেক্টরিগুলির নির্ভরতা পরীক্ষা করা অমূলক।
  • অন্যান্য নিয়মে জেনরুল উল্লেখ করার সময়, আপনি হয় জেনরুলের লেবেল বা পৃথক আউটপুট ফাইলের লেবেল ব্যবহার করতে পারেন। কখনও কখনও একটি পদ্ধতি বেশি পঠনযোগ্য হয়, কখনও কখনও অন্যটি: একটি কনজিউমিং নিয়মের srcs এ নাম অনুসারে আউটপুট উল্লেখ করা অনিচ্ছাকৃতভাবে জেনরুলের অন্যান্য আউটপুটগুলি গ্রহণ করা এড়াতে পারে, তবে যদি জেনরুল অনেকগুলি আউটপুট তৈরি করে তবে এটি ক্লান্তিকর হতে পারে।

উদাহরণ

এই উদাহরণ foo.h তৈরি করে। কোন উৎস নেই, কারণ কমান্ড কোন ইনপুট নেয় না। কমান্ড দ্বারা চালিত "বাইনারী" হল জেনরুলের মতো একই প্যাকেজে একটি পার্ল স্ক্রিপ্ট।

genrule(
    name = "foo",
    srcs = [],
    outs = ["foo.h"],
    cmd = "./$(location create_foo.pl) > \"$@\"",
    tools = ["create_foo.pl"],
)

নিম্নলিখিত উদাহরণ দেখায় কিভাবে একটি filegroup এবং অন্য genrule আউটপুট ব্যবহার করতে হয়। মনে রাখবেন যে স্পষ্ট $(location) নির্দেশের পরিবর্তে $(SRCS) ব্যবহার করাও কাজ করবে; এই উদাহরণটি প্রদর্শনের জন্য পরবর্তীটি ব্যবহার করে।

genrule(
    name = "concat_all_files",
    srcs = [
        "//some:files",  # a filegroup with multiple files in it ==> $(locations)
        "//other:gen",   # a genrule with a single output ==> $(location)
    ],
    outs = ["concatenated.txt"],
    cmd = "cat $(locations //some:files) $(location //other:gen) > $@",
)

যুক্তি

গুণাবলী
name

Name ; required

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


আপনি অন্যান্য BUILD নিয়মের srcs বা deps বিভাগে নাম দ্বারা এই নিয়মটি উল্লেখ করতে পারেন। যদি নিয়মটি উৎস ফাইল তৈরি করে, তাহলে আপনার srcs অ্যাট্রিবিউট ব্যবহার করা উচিত।
srcs

List of labels ; optional

এই নিয়মের জন্য ইনপুটগুলির একটি তালিকা, যেমন প্রক্রিয়া করার জন্য উৎস ফাইল।

এই বৈশিষ্ট্যগুলি cmd দ্বারা সঞ্চালিত সরঞ্জামগুলি তালিকাভুক্ত করার জন্য উপযুক্ত নয়; পরিবর্তে তাদের জন্য tools বৈশিষ্ট্য ব্যবহার করুন।

বিল্ড সিস্টেম নিশ্চিত করে যে এই পূর্বশর্তগুলি genrule কমান্ড চালানোর আগে তৈরি করা হয়েছে; তারা মূল বিল্ড অনুরোধ হিসাবে একই কনফিগারেশন ব্যবহার করে নির্মিত হয়. এই পূর্বশর্তগুলির ফাইলগুলির নাম $(SRCS) এ একটি স্থান-বিচ্ছিন্ন তালিকা হিসাবে কমান্ডের কাছে উপলব্ধ রয়েছে; বিকল্পভাবে একটি পৃথক srcs লক্ষ্যের পাথ //x:y $(location //x:y) ব্যবহার করে বা $< ব্যবহার করে প্রাপ্ত করা যেতে পারে তবে এটি srcs এ একমাত্র এন্ট্রি।

outs

List of filenames ; required; nonconfigurable

এই নিয়ম দ্বারা উত্পন্ন ফাইলের একটি তালিকা.

আউটপুট ফাইল প্যাকেজ সীমানা অতিক্রম করা উচিত নয়. আউটপুট ফাইলের নামগুলি প্যাকেজের সাথে সম্পর্কিত হিসাবে ব্যাখ্যা করা হয়।

যদি executable পতাকা সেট করা থাকে, outs অবশ্যই একটি লেবেল থাকতে হবে।

জেনরুল কমান্ড প্রতিটি আউটপুট ফাইল একটি পূর্বনির্ধারিত অবস্থানে তৈরি করবে বলে আশা করা হচ্ছে। অবস্থানটি cmd-এ cmd -নির্দিষ্ট "মেক" ভেরিয়েবল ( $@ , $(OUTS) , $(@D) বা $(RULEDIR) ) বা $(location) প্রতিস্থাপন ব্যবহার করে উপলব্ধ।

cmd

String; optional

চালানোর নির্দেশ। $(location) এবং "মেক" পরিবর্তনশীল প্রতিস্থাপন সাপেক্ষে।
  1. প্রথম $(location) প্রতিস্থাপন প্রয়োগ করা হয়, $(location label ) এবং $(locations label ) (এবং সম্পর্কিত ভেরিয়েবল execpath , execpaths , rootpath এবং rootpaths ব্যবহার করে অনুরূপ নির্মাণ) এর সমস্ত ঘটনা প্রতিস্থাপন করে।
  2. এর পরে, "বানান" ভেরিয়েবলগুলি প্রসারিত হয়। নোট করুন যে পূর্বনির্ধারিত ভেরিয়েবল $(JAVA) , $(JAVAC) এবং $(JAVABASE) হোস্ট কনফিগারেশনের অধীনে প্রসারিত হয়, তাই একটি বিল্ড স্টেপের অংশ হিসাবে চালানো জাভা ইনভোকেশনগুলি সঠিকভাবে ভাগ করা লাইব্রেরি এবং অন্যান্য নির্ভরতা লোড করতে পারে।
  3. অবশেষে, ব্যাশ শেল ব্যবহার করে ফলস্বরূপ কমান্ডটি কার্যকর করা হয়। যদি এর প্রস্থান কোড অ-শূন্য হয় তাহলে কমান্ডটি ব্যর্থ হয়েছে বলে মনে করা হয়।
এটি cmd_bash , cmd_ps এবং cmd_bat এর ফলব্যাক, যদি তাদের কোনটিই প্রযোজ্য না হয়।

যদি কমান্ড লাইনের দৈর্ঘ্য প্ল্যাটফর্মের সীমা অতিক্রম করে (লিনাক্স/ম্যাকস-এ 64K, উইন্ডোজে 8K), তাহলে জেনরুল একটি স্ক্রিপ্টে কমান্ড লিখবে এবং সেই স্ক্রিপ্টটি কার্যকর করতে কাজ করবে। এটি সমস্ত cmd বৈশিষ্ট্যের জন্য প্রযোজ্য ( cmd , cmd_bash , cmd_ps , cmd_bat )৷

cmd_bash

String; optional

চালানোর জন্য Bash কমান্ড।

এই বৈশিষ্ট্যটি cmd এর চেয়ে বেশি অগ্রাধিকার পেয়েছে। কমান্ডটি প্রসারিত হয় এবং cmd বৈশিষ্ট্যের মতো ঠিক একইভাবে চলে।

cmd_bat

String; optional

উইন্ডোজে চালানোর জন্য ব্যাচ কমান্ড।

এই বৈশিষ্ট্যটির cmd এবং cmd_bash এর চেয়ে বেশি অগ্রাধিকার রয়েছে। কমান্ডটি নিম্নলিখিত পার্থক্য সহ cmd অ্যাট্রিবিউটের মতো একইভাবে চলে:

  • এই বৈশিষ্ট্য শুধুমাত্র Windows এ প্রযোজ্য.
  • কমান্ডটি নিম্নলিখিত ডিফল্ট আর্গুমেন্ট সহ cmd.exe /c দিয়ে চলে:
    • /S - প্রথম এবং শেষ উদ্ধৃতি ফালান এবং অন্য সবকিছু যেমন আছে তেমন চালান।
    • /E:ON - বর্ধিত কমান্ড সেট সক্ষম করুন।
    • /V:ON - বিলম্বিত পরিবর্তনশীল সম্প্রসারণ সক্ষম করুন
    • /D - AutoRun রেজিস্ট্রি এন্ট্রি উপেক্ষা করুন।
  • $(অবস্থান) এবং "মেক" ভেরিয়েবল প্রতিস্থাপনের পরে, পাথগুলিকে উইন্ডোজ স্টাইলের পাথে (ব্যাকস্ল্যাশ সহ) প্রসারিত করা হবে।
cmd_ps

String; optional

উইন্ডোজে চালানোর জন্য পাওয়ারশেল কমান্ড।

এই বৈশিষ্ট্যটির cmd , cmd_bash এবং cmd_bat এর চেয়ে বেশি অগ্রাধিকার রয়েছে। কমান্ডটি নিম্নলিখিত পার্থক্য সহ cmd অ্যাট্রিবিউটের মতো একইভাবে চলে:

  • এই বৈশিষ্ট্য শুধুমাত্র Windows এ প্রযোজ্য.
  • কমান্ডটি powershell.exe /c দিয়ে চলে।

পাওয়ারশেল ব্যবহার করা সহজ এবং কম ত্রুটি-প্রবণ করতে, আমরা জেনরুলে পাওয়ারশেল কমান্ড কার্যকর করার আগে পরিবেশ সেট আপ করতে নিম্নলিখিত কমান্ডগুলি চালাই।

  • Set-ExecutionPolicy -Scope CurrentUser RemoteSigned - স্বাক্ষরবিহীন স্ক্রিপ্ট চালানোর অনুমতি দিন।
  • $errorActionPreference='Stop' - যদি একাধিক কমান্ড দ্বারা আলাদা করা থাকে ; , একটি Powershell CmdLet ব্যর্থ হলে ক্রিয়াটি অবিলম্বে প্রস্থান করে, কিন্তু এটি বহিরাগত কমান্ডের জন্য কাজ করে না
  • $PSDefaultParameterValues['*:Encoding'] = 'utf8' - utf-16 থেকে utf-8-এ ডিফল্ট এনকোডিং পরিবর্তন করুন।
exec_tools

List of labels ; optional

এই নিয়মের জন্য টুল নির্ভরতার একটি তালিকা। এটি ঠিক tools অ্যাট্রিবিউটের মতো আচরণ করে, এই নির্ভরতাগুলি হোস্ট কনফিগারেশনের পরিবর্তে নিয়মের এক্সিকিউশন প্ল্যাটফর্মের জন্য কনফিগার করা হবে। এর মানে হল যে exec_tools এ নির্ভরতাগুলি tools নির্ভরশীলতার মতো একই সীমাবদ্ধতার বিষয় নয়। বিশেষ করে, তাদের নিজস্ব ট্রানজিটিভ নির্ভরতার জন্য হোস্ট কনফিগারেশন ব্যবহার করার প্রয়োজন নেই। আরো বিস্তারিত জানার জন্য tools দেখুন.

ব্লেজ টিম exec_tools শব্দার্থবিদ্যা ব্যবহার করার জন্য tools সমস্ত ব্যবহার স্থানান্তর করছে৷ ব্যবহারকারীদেরকে exec_tools কে এমন tools জন্য পছন্দ করতে উত্সাহিত করা হয় যেখানে এটি কোনও সমস্যা সৃষ্টি করে না। কার্যকরী স্থানান্তর সম্পূর্ণ হওয়ার পরে, আমরা exec_tools নাম পরিবর্তন করে tools রাখতে পারি। এটি হওয়ার আগে আপনি একটি অবমূল্যায়ন সতর্কতা এবং মাইগ্রেশন নির্দেশাবলী পাবেন।

executable

Boolean; optional; nonconfigurable ; default is False

আউটপুটকে এক্সিকিউটেবল বলে ঘোষণা করুন।

এই পতাকাটিকে True-এ সেট করার অর্থ হল আউটপুটটি একটি এক্সিকিউটেবল ফাইল এবং run যেতে পারে। এই ক্ষেত্রে জেনরুলটি অবশ্যই একটি আউটপুট তৈরি করবে। যদি এই অ্যাট্রিবিউট সেট করা থাকে, run ফাইলের বিষয়বস্তু নির্বিশেষে এক্সিকিউট করার চেষ্টা করবে।

জেনারেট করা এক্সিকিউটেবলের জন্য ডেটা নির্ভরতা ঘোষণা করা সমর্থিত নয়।

local

Boolean; optional; default is False

যদি True তে সেট করা হয়, তাহলে এই বিকল্পটি "স্থানীয়" কৌশল ব্যবহার করে এই genrule চালানোর জন্য বাধ্য করে, যার অর্থ কোন দূরবর্তী এক্সিকিউশন নেই, কোন স্যান্ডবক্সিং নেই, কোন অবিরাম কর্মী নেই।

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

message

String; optional

একটি অগ্রগতি বার্তা।

একটি অগ্রগতি বার্তা যা এই বিল্ড ধাপটি কার্যকর হওয়ার সাথে সাথে মুদ্রিত হবে। ডিফল্টরূপে, বার্তাটি হল " আউটপুট তৈরি করা" (অথবা সমানভাবে নম্র কিছু) তবে আপনি আরও নির্দিষ্ট একটি প্রদান করতে পারেন। আপনার cmd কমান্ডে echo বা অন্যান্য মুদ্রণ বিবৃতির পরিবর্তে এই বৈশিষ্ট্যটি ব্যবহার করুন, কারণ এটি বিল্ড টুলটিকে এই ধরনের অগ্রগতি বার্তাগুলি মুদ্রিত করা হয়েছে কিনা তা নিয়ন্ত্রণ করতে দেয়।

output_licenses

Licence type; optional

common attributes দেখুন
output_to_bindir

Boolean; optional; nonconfigurable ; default is False

True-এ সেট করা থাকলে, এই বিকল্পের ফলে আউটপুট ফাইলগুলি genfiles ডিরেক্টরির পরিবর্তে bin ডিরেক্টরিতে লেখা হবে।

tools

List of labels ; optional

এই নিয়মের জন্য টুল নির্ভরতার একটি তালিকা। আরও তথ্যের জন্য নির্ভরতার সংজ্ঞা দেখুন।

বিল্ড সিস্টেম নিশ্চিত করে যে এই পূর্বশর্তগুলি genrule কমান্ড চালানোর আগে তৈরি করা হয়েছে; এগুলি হোস্ট কনফিগারেশন ব্যবহার করে তৈরি করা হয়, যেহেতু এই সরঞ্জামগুলি বিল্ডের অংশ হিসাবে কার্যকর করা হয়। $(location //x:y) ব্যবহার করে একটি পৃথক tools টার্গেট //x:y এর পাথ প্রাপ্ত করা যেতে পারে।

যেকোন *_binary বা টুল cmd দ্বারা নির্বাহ করতে হবে এই তালিকায় উপস্থিত হতে হবে, srcs এ নয়, নিশ্চিত করতে যে সেগুলি সঠিক কনফিগারেশনে তৈরি হয়েছে।

পরীক্ষা স্যুট

test_suite(name, compatible_with, deprecation, distribs, features, licenses, restricted_to, tags, target_compatible_with, testonly, tests, visibility)

একটি test_suite পরীক্ষার একটি সেট সংজ্ঞায়িত করে যা মানুষের জন্য "উপযোগী" বলে বিবেচিত হয়। এটি প্রকল্পগুলিকে পরীক্ষার সেটগুলি সংজ্ঞায়িত করতে দেয়, যেমন "চেকইন করার আগে আপনাকে অবশ্যই পরীক্ষা চালাতে হবে", "আমাদের প্রকল্পের চাপ পরীক্ষা" বা "সমস্ত ছোট পরীক্ষা।" ব্লেজ blaze test কমান্ড এই ধরণের সংস্থাকে সম্মান করে: ব্লেজ blaze test //some/test:suite suite-এর মতো একটি আহ্বানের জন্য, ব্লেজ প্রথমে //some/test:suite টার্গেট দ্বারা অন্তর্ভুক্ত সমস্ত পরীক্ষার লক্ষ্যগুলি গণনা করে (আমরা এটিকে "test_suite সম্প্রসারণ" বলি ), তারপর ব্লেজ সেই লক্ষ্যগুলি তৈরি করে এবং পরীক্ষা করে।

উদাহরণ

বর্তমান প্যাকেজে সমস্ত ছোট পরীক্ষা চালানোর জন্য একটি পরীক্ষা স্যুট।

test_suite(
    name = "small_tests",
    tags = ["small"],
)

একটি পরীক্ষা স্যুট যা পরীক্ষাগুলির একটি নির্দিষ্ট সেট চালায়:

test_suite(
    name = "smoke_tests",
    tests = [
        "system_unittest",
        "public_api_unittest",
    ],
)

বর্তমান প্যাকেজে সমস্ত পরীক্ষা চালানোর জন্য একটি পরীক্ষা স্যুট যা অস্পষ্ট নয়।

test_suite(
    name = "non_flaky_test",
    tags = ["-flaky"],
)

যুক্তি

গুণাবলী
name

Name ; required

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

tags

List of strings; optional; nonconfigurable

টেক্সট ট্যাগের তালিকা যেমন "ছোট" বা "ডাটাবেস" বা "-ফ্ল্যাকি"। ট্যাগ কোনো বৈধ স্ট্রিং হতে পারে.

একটি "-" অক্ষর দিয়ে শুরু হওয়া ট্যাগগুলি নেতিবাচক ট্যাগ হিসাবে বিবেচিত হয়। পূর্ববর্তী "-" অক্ষরটিকে ট্যাগের অংশ হিসাবে বিবেচনা করা হয় না, তাই "-small" এর একটি স্যুট ট্যাগ একটি পরীক্ষার "ছোট" আকারের সাথে মেলে। অন্যান্য সমস্ত ট্যাগ ইতিবাচক ট্যাগ হিসাবে বিবেচিত হয়।

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

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

ওয়াইল্ডকার্ড টার্গেট প্যাটার্ন জড়িত ব্লেজ blaze test কমান্ড দ্বারা সম্পাদিত "test_suite সম্প্রসারণ" দ্বারা manual ট্যাগ কীওয়ার্ডটিকে উপরের থেকে আলাদাভাবে বিবেচনা করা হয়। সেখানে, "ম্যানুয়াল" ট্যাগ করা test_suite লক্ষ্যগুলি ফিল্টার করা হয় (এবং এইভাবে প্রসারিত হয় না)। এই আচরণটি blaze build এবং blaze test কিভাবে সাধারণভাবে ওয়াইল্ডকার্ড টার্গেট প্যাটার্ন পরিচালনা করে তার সাথে সামঞ্জস্যপূর্ণ। মনে রাখবেন যে এটি blaze query 'tests(E)' কীভাবে আচরণ করে তার থেকে স্পষ্টভাবে আলাদা, কারণ manual ট্যাগ নির্বিশেষে স্যুটগুলি সর্বদা tests কোয়েরি ফাংশন দ্বারা প্রসারিত হয়।

নোট করুন যে একটি পরীক্ষার size ফিল্টারিংয়ের উদ্দেশ্যে একটি ট্যাগ হিসাবে বিবেচিত হয়।

আপনার যদি পারস্পরিক একচেটিয়া ট্যাগ (যেমন সমস্ত ছোট এবং মাঝারি পরীক্ষা) সহ পরীক্ষা ধারণ করে এমন একটি test_suite প্রয়োজন হয় তবে আপনাকে তিনটি test_suite নিয়ম তৈরি করতে হবে: একটি সমস্ত ছোট পরীক্ষার জন্য, একটি সমস্ত মাঝারি পরীক্ষার জন্য এবং একটি যাতে আগের দুটি অন্তর্ভুক্ত থাকে .

tests

List of labels ; optional; nonconfigurable

যেকোন ভাষার টেস্ট স্যুট এবং পরীক্ষার লক্ষ্যগুলির একটি তালিকা।

যেকোন *_test এখানে গৃহীত হয়, ভাষা থেকে স্বাধীন। কোনো *_binary লক্ষ্যমাত্রা গ্রহণ করা হয় না, এমনকি যদি সেগুলি একটি পরীক্ষা চালাতে হয়। নির্দিষ্ট tags দ্বারা ফিল্টারিং শুধুমাত্র এই অ্যাট্রিবিউটে সরাসরি তালিকাভুক্ত পরীক্ষার জন্য করা হয়। যদি এই বৈশিষ্ট্যটিতে test_suite s থাকে, তবে সেগুলির ভিতরের পরীক্ষাগুলি এই test_suite দ্বারা ফিল্টার করা হবে না (এগুলি ইতিমধ্যেই ফিল্টার করা বলে মনে করা হয়)।

যদি tests অ্যাট্রিবিউটটি অনির্দিষ্ট বা খালি থাকে, তবে বর্তমান বিল্ড ফাইলে manual হিসাবে ট্যাগ করা হয়নি এমন সমস্ত পরীক্ষার নিয়মগুলি অন্তর্ভুক্ত করার জন্য নিয়মটি ডিফল্ট হবে। এই নিয়মগুলি এখনও tag ফিল্টারিং সাপেক্ষে।