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

এই পৃষ্ঠাটি Cloud Translation API অনুবাদ করেছে।

Bazel কোয়েরি রেফারেন্স

এই পৃষ্ঠাটি ব্যাজেল কোয়েরি ভাষার জন্য রেফারেন্স ম্যানুয়াল যা আপনি যখন বিল্ড নির্ভরতা বিশ্লেষণ করতে bazel query ব্যবহার করেন। এটি আউটপুট ফরম্যাটগুলিও বর্ণনা করে যা bazel query সমর্থন করে।

ব্যবহারিক ব্যবহারের ক্ষেত্রে, Bazel Query How-to দেখুন।

অতিরিক্ত ক্যোয়ারী রেফারেন্স

query ছাড়াও, যা পোস্ট-লোডিং ফেজ টার্গেট গ্রাফে চলে, Bazel অ্যাকশন গ্রাফ ক্যোয়ারী এবং কনফিগারযোগ্য ক্যোয়ারী অন্তর্ভুক্ত করে।

অ্যাকশন গ্রাফ ক্যোয়ারী

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

আরও বিশদ বিবরণের জন্য, অনুসন্ধানের রেফারেন্স দেখুন।

কনফিগারযোগ্য প্রশ্ন

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

আরো বিস্তারিত জানার জন্য, cquery রেফারেন্স দেখুন।

উদাহরণ

মানুষ কিভাবে bazel query ব্যবহার করবেন? এখানে সাধারণ উদাহরণ রয়েছে:

কেন //foo গাছ //bar/baz এর উপর নির্ভর করে? একটি পথ দেখান:

somepath(foo/..., //bar/baz:all)

কোন C++ লাইব্রেরিগুলি সমস্ত foo পরীক্ষা করে তার উপর নির্ভর করে যে foo_bin টার্গেট করে না?

kind("cc_library", deps(kind(".*test rule", foo/...)) except deps(//foo:foo_bin))

টোকেন: আভিধানিক সিনট্যাক্স

ক্যোয়ারী ভাষায় অভিব্যক্তি নিম্নলিখিত টোকেন দ্বারা গঠিত:

কীওয়ার্ড , যেমন let . মূলশব্দগুলি হল ভাষার সংরক্ষিত শব্দ, এবং তাদের প্রতিটি নীচে বর্ণনা করা হয়েছে। কীওয়ার্ডের সম্পূর্ণ সেট হল:
শব্দ , যেমন " foo/... " বা " .*test rule " বা " //bar/baz:all "। যদি একটি অক্ষর ক্রম "উদ্ধৃত" হয় (একটি-উদ্ধৃতি দিয়ে শুরু হয় এবং শেষ হয় ' অথবা একটি ডবল-উদ্ধৃতি " দিয়ে শুরু হয় এবং শেষ হয়), এটি একটি শব্দ৷ যদি একটি অক্ষর ক্রম উদ্ধৃত না হয় তবে এটি একটি হিসাবে পার্স করা হতে পারে শব্দ। উদ্ধৃত শব্দগুলি হল বর্ণমালার অক্ষর A-Za-z, সংখ্যা 0-9, এবং বিশেষ অক্ষরগুলি থেকে আঁকা অক্ষরের ক্রম */@.-_:$~[] (স্টারিস্ক, ফরোয়ার্ড স্ল্যাশ, এট, পিরিয়ড, হাইফেন, আন্ডারস্কোর, কোলন, ডলার চিহ্ন, টিল্ড, বাম বর্গাকার বন্ধনী, ডান বর্গাকার বন্ধনী)। যাইহোক, উদ্ধৃত শব্দগুলি একটি হাইফেন - বা তারকাচিহ্ন * দিয়ে শুরু নাও হতে পারে যদিও আপেক্ষিক [লক্ষ্যের নাম][(/concepts/labels#target- নাম) সেই অক্ষর দিয়ে শুরু হতে পারে।
উদ্ধৃতিহীন শব্দগুলিতে অক্ষর যোগ চিহ্ন + বা সমান চিহ্ন = অক্ষর অন্তর্ভুক্ত নাও হতে পারে, যদিও সেই অক্ষরগুলি লক্ষ্যের নামে অনুমোদিত। কোড লেখার সময় যা কোয়েরি এক্সপ্রেশন তৈরি করে, লক্ষ্যের নাম উদ্ধৃত করা উচিত।
স্ক্রিপ্ট লেখার সময় উদ্ধৃতি প্রয়োজন যা ব্যবহারকারীর সরবরাহ করা মান থেকে Bazel ক্যোয়ারী এক্সপ্রেশন তৈরি করে।
```
 //foo:bar+wiz    # WRONG: scanned as //foo:bar + wiz.
 //foo:bar=wiz    # WRONG: scanned as //foo:bar = wiz.
 "//foo:bar+wiz"  # OK.
 "//foo:bar=wiz"  # OK.
```
মনে রাখবেন যে এই উদ্ধৃতিটি আপনার শেল দ্বারা প্রয়োজন হতে পারে এমন যেকোনো উদ্ধৃতির অতিরিক্ত, যেমন:
```
bazel query ' "//foo:bar=wiz" '   # single-quotes for shell, double-quotes for Bazel.
```
কীওয়ার্ড, যখন উদ্ধৃত করা হয়, তখন সাধারণ শব্দ হিসাবে বিবেচিত হয়। উদাহরণস্বরূপ, some একটি কীওয়ার্ড কিন্তু "কিছু" একটি শব্দ। foo এবং "foo" উভয়ই শব্দ।
যাইহোক, লক্ষ্যবস্তুতে একক বা ডবল উদ্ধৃতি ব্যবহার করার সময় সতর্কতা অবলম্বন করুন। এক বা একাধিক টার্গেট নাম উদ্ধৃত করার সময়, শুধুমাত্র এক ধরনের উদ্ধৃতি ব্যবহার করুন (হয় সমস্ত একক বা সমস্ত দ্বিগুণ উদ্ধৃতি)।
জাভা কোয়েরি স্ট্রিং কি হবে তার উদাহরণ নিচে দেওয়া হল:
```
  'a"'a'         # WRONG: Error message: unclosed quotation.
  "a'"a"         # WRONG: Error message: unclosed quotation.
  '"a" + 'a''    # WRONG: Error message: unexpected token 'a' after query expression '"a" + '
  "'a' + "a""    # WRONG: Error message: unexpected token 'a' after query expression ''a' + '
  "a'a"          # OK.
  'a"a'          # OK.
  '"a" + "a"'    # OK
  "'a' + 'a'"    # OK
```
আমরা এই সিনট্যাক্সটি বেছে নিয়েছি যাতে বেশিরভাগ ক্ষেত্রে উদ্ধৃতি চিহ্নের প্রয়োজন হয় না। (অস্বাভাবিক) ".*test rule" উদাহরণের উদ্ধৃতি প্রয়োজন: এটি একটি পিরিয়ড দিয়ে শুরু হয় এবং একটি স্থান ধারণ করে। "cc_library" উদ্ধৃত করা অপ্রয়োজনীয় কিন্তু ক্ষতিকর।
বিরাম চিহ্ন , যেমন বন্ধনী () , পিরিয়ড . এবং কমা , . বিরাম চিহ্ন সম্বলিত শব্দ (উপরে তালিকাভুক্ত ব্যতিক্রম ব্যতীত) অবশ্যই উদ্ধৃত করতে হবে।

উদ্ধৃত শব্দের বাইরে হোয়াইটস্পেস অক্ষর উপেক্ষা করা হয়।

Bazel ক্যোয়ারী ভাষা ধারণা

Bazel ক্যোয়ারী ভাষা অভিব্যক্তির একটি ভাষা। প্রতিটি অভিব্যক্তি লক্ষ্যের একটি আংশিক-ক্রমযুক্ত সেট , বা সমতুল্যভাবে, লক্ষ্যগুলির একটি গ্রাফ (DAG) মূল্যায়ন করে। এটি একমাত্র ডেটাটাইপ।

সেট এবং গ্রাফ একই ডেটাটাইপকে উল্লেখ করে, কিন্তু এর বিভিন্ন দিককে জোর দেয়, উদাহরণস্বরূপ:

সেট: লক্ষ্যগুলির আংশিক ক্রম আকর্ষণীয় নয়।
গ্রাফ: লক্ষ্যগুলির আংশিক ক্রম উল্লেখযোগ্য।

নির্ভরতা গ্রাফে চক্র

নির্ভরতা গ্রাফ তৈরি করুন অ্যাসাইক্লিক হওয়া উচিত।

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

অন্তর্নিহিত নির্ভরতা

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

প্রতি ডিফল্ট bazel query ক্যোয়ারী ফলাফল গণনা করার সময় অন্তর্নিহিত নির্ভরতা বিবেচনা করে। এই আচরণটি --[no]implicit_deps বিকল্প দিয়ে পরিবর্তন করা যেতে পারে। মনে রাখবেন, ক্যোয়ারী কনফিগারেশন বিবেচনা করে না, সম্ভাব্য টুলচেন কখনই বিবেচনা করা হয় না।

সুস্থতা

Bazel ক্যোয়ারী ভাষার অভিব্যক্তিগুলি বিল্ড নির্ভরতা গ্রাফের উপর কাজ করে, যা সমস্ত BUILD ফাইলের সমস্ত নিয়ম ঘোষণা দ্বারা স্পষ্টভাবে সংজ্ঞায়িত গ্রাফ। এটি বোঝা গুরুত্বপূর্ণ যে এই গ্রাফটি কিছুটা বিমূর্ত, এবং একটি বিল্ডের সমস্ত ধাপগুলি কীভাবে সম্পাদন করতে হয় তার সম্পূর্ণ বিবরণ গঠন করে না। একটি নির্মাণ সম্পাদন করার জন্য, একটি কনফিগারেশনও প্রয়োজন; আরও বিস্তারিত জানার জন্য ব্যবহারকারীর গাইডের কনফিগারেশন বিভাগটি দেখুন।

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

গ্রাফ অর্ডার সংরক্ষণের উপর

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

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

deps(x) union y

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

যে অপারেটরগুলি অর্ডার সীমাবদ্ধতা প্রবর্তন করে তাদের অন্তর্ভুক্ত: allpaths , deps , rdeps , somepath , এবং টার্গেট প্যাটার্ন ওয়াইল্ডকার্ড package:* , dir/... , ইত্যাদি।

আকাশ জিজ্ঞাসা

স্কাই ক্যোয়ারী হল কোয়েরির একটি মোড যা একটি নির্দিষ্ট মহাবিশ্বের সুযোগে কাজ করে।

বিশেষ ফাংশন শুধুমাত্র SkyQuery এ উপলব্ধ

স্কাই কোয়েরি মোডে অতিরিক্ত ক্যোয়ারী ফাংশন allrdeps এবং rbuildfiles । এই ফাংশনগুলি সমগ্র মহাবিশ্বের স্কোপ জুড়ে কাজ করে (যার কারণে তারা সাধারণ ক্যোয়ারির জন্য অর্থবোধ করে না)।

একটি মহাবিশ্বের সুযোগ নির্দিষ্ট করা

স্কাই কোয়েরি মোড নিম্নলিখিত দুটি পতাকা পাস করে সক্রিয় করা হয়েছে: ( --universe_scope বা --infer_universe_scope ) এবং --order_output=no । --universe_scope=<target_pattern1>,...,<target_patternN> টার্গেট প্যাটার্ন দ্বারা নির্দিষ্ট করা টার্গেট প্যাটার্নের ট্রানজিটিভ ক্লোজার প্রিলোড করতে ক্যোয়ারীকে বলে, যা যোগ এবং বিয়োগ উভয়ই হতে পারে। সমস্ত প্রশ্ন তারপর এই "স্কোপ" মূল্যায়ন করা হয়. বিশেষ করে, allrdeps এবং rbuildfiles অপারেটর শুধুমাত্র এই সুযোগ থেকে ফলাফল প্রদান করে। --infer_universe_scope Bazel কে ক্যোয়ারী এক্সপ্রেশন থেকে --universe_scope এর জন্য একটি মান অনুমান করতে বলে। এই অনুমানকৃত মানটি ক্যোয়ারী এক্সপ্রেশনে অনন্য টার্গেট প্যাটার্নের তালিকা, কিন্তু আপনি যা চান তা নাও হতে পারে। উদাহরণ স্বরূপ:

bazel query --infer_universe_scope --order_output=no "allrdeps(//my:target)"

এই ক্যোয়ারী এক্সপ্রেশনে অনন্য টার্গেট প্যাটার্নের তালিকা হল ["//my:target"] , তাই Bazel এটিকে আহ্বানের মতোই বিবেচনা করে:

bazel query --universe_scope=//my:target --order_output=no "allrdeps(//my:target)"

কিন্তু --universe_scope এর সাথে সেই প্রশ্নের ফলাফল শুধুমাত্র //my:target ; //my:target এর বিপরীত নির্ভরতার কোনোটিই মহাবিশ্বে নেই, নির্মাণের মাধ্যমে! অন্যদিকে, বিবেচনা করুন:

bazel query --infer_universe_scope --order_output=no "tests(//a/... + b/...) intersect allrdeps(siblings(rbuildfiles(my/starlark/file.bzl)))"

এটি একটি অর্থপূর্ণ ক্যোয়ারী আমন্ত্রণ যা কিছু ডিরেক্টরির অধীনে লক্ষ্যগুলির পরিপ্রসারণ tests পরীক্ষার লক্ষ্যগুলি গণনা করার চেষ্টা করছে যা ট্রানজিটিভভাবে লক্ষ্যগুলির উপর নির্ভর করে যার সংজ্ঞা একটি নির্দিষ্ট .bzl ফাইল ব্যবহার করে৷ এখানে, --infer_universe_scope হল একটি সুবিধা, বিশেষ করে সেই ক্ষেত্রে যেখানে --universe_scope এর পছন্দের জন্য অন্যথায় আপনাকে নিজের ক্যোয়ারী এক্সপ্রেশনটি পার্স করতে হবে।

সুতরাং, ক্যোয়ারী এক্সপ্রেশনের জন্য যেগুলি allrdeps এবং rbuildfiles এর মত ইউনিভার্স-স্কোপড অপারেটর ব্যবহার করে শুধুমাত্র --infer_universe_scope ব্যবহার করতে ভুলবেন না যদি এর আচরণ আপনি চান।

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

অভিব্যক্তি: ব্যাকরণের সিনট্যাক্স এবং শব্দার্থবিদ্যা

এটি ব্যাজেল কোয়েরি ভাষার ব্যাকরণ, যা EBNF স্বরলিপিতে প্রকাশ করা হয়েছে:

expr ::= word
       | let name = expr in expr
       | (expr)
       | expr intersect expr
       | expr ^ expr
       | expr union expr
       | expr + expr
       | expr except expr
       | expr - expr
       | set(word *)
       | word '(' int | word | expr ... ')'

নিম্নলিখিত বিভাগগুলি এই ব্যাকরণের প্রতিটি প্রযোজনাকে ক্রমানুসারে বর্ণনা করে।

লক্ষ্য নিদর্শন

expr ::= word

সিনট্যাক্টিক্যালি, একটি টার্গেট প্যাটার্ন শুধু একটি শব্দ। এটিকে লক্ষ্যের একটি (অক্রমবিহীন) সেট হিসাবে ব্যাখ্যা করা হয়েছে। সবচেয়ে সহজ লক্ষ্য প্যাটার্ন হল একটি লেবেল, যা একটি একক লক্ষ্য (ফাইল বা নিয়ম) সনাক্ত করে। উদাহরণস্বরূপ, টার্গেট প্যাটার্ন //foo:bar একটি উপাদান, লক্ষ্য, bar নিয়ম সমন্বিত একটি সেটের মূল্যায়ন করে।

টার্গেট প্যাটার্নগুলি প্যাকেজ এবং লক্ষ্যগুলির উপর ওয়াইল্ডকার্ড অন্তর্ভুক্ত করতে লেবেলগুলিকে সাধারণীকরণ করে৷ উদাহরণস্বরূপ, foo/...:all (বা শুধু foo/... ) হল একটি টার্গেট প্যাটার্ন যা foo ডিরেক্টরির নীচে পুনরাবৃত্তভাবে প্রতিটি প্যাকেজের সমস্ত নিয়ম সমন্বিত একটি সেটের মূল্যায়ন করে; bar/baz:all হল একটি টার্গেট প্যাটার্ন যা bar/baz প্যাকেজের সমস্ত নিয়ম সমন্বিত একটি সেটের মূল্যায়ন করে, কিন্তু এর সাবপ্যাকেজ নয়।

একইভাবে, foo/...:* একটি টার্গেট প্যাটার্ন যা foo ডিরেক্টরির নিচে পুনরাবৃত্তভাবে প্রতিটি প্যাকেজে সমস্ত টার্গেট (নিয়ম এবং ফাইল) সমন্বিত একটি সেটের মূল্যায়ন করে; bar/baz:* bar/baz প্যাকেজের সমস্ত লক্ষ্য সমন্বিত একটি সেটের মূল্যায়ন করে, কিন্তু এর সাবপ্যাকেজ নয়।

যেহেতু :* ওয়াইল্ডকার্ড ফাইলের সাথে সাথে নিয়মের সাথে মেলে, এটি প্রায়শই প্রশ্নগুলির জন্য :all এর চেয়ে বেশি কার্যকর। বিপরীতভাবে, :all ওয়াইল্ডকার্ড ( foo/... এর মতো টার্গেট প্যাটার্নে অন্তর্নিহিত) সাধারণত বিল্ডের জন্য বেশি উপযোগী।

bazel query টার্গেট প্যাটার্ন একই কাজ করে যেমন bazel build বিল্ড টার্গেট করে। আরও বিশদ বিবরণের জন্য, লক্ষ্য প্যাটার্নস দেখুন বা bazel help target-syntax টাইপ করুন।

টার্গেট প্যাটার্ন মূল্যায়ন করতে পারে একটি সিঙ্গলটন সেট (লেবেলের ক্ষেত্রে), অনেক উপাদান সমন্বিত একটি সেটে (যেমন foo/... এর ক্ষেত্রে, যার হাজার হাজার উপাদান রয়েছে) অথবা খালি সেটে, যদি লক্ষ্য থাকে প্যাটার্ন কোন লক্ষ্যের সাথে মেলে না।

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

ভেরিয়েবল

expr ::= let name = expr₁ in expr₂
       | $name

Bazel ক্যোয়ারী ভাষা ভেরিয়েবলের সংজ্ঞা এবং উল্লেখ করতে দেয়। একটি let এক্সপ্রেশনের মূল্যায়নের ফলাফল expr ₂ এর মতই, যেখানে পরিবর্তনশীল name সমস্ত বিনামূল্যের ঘটনা expr ₁ এর মান দ্বারা প্রতিস্থাপিত হয়েছে।

উদাহরণস্বরূপ, let v = foo/... in allpaths($v, //common) intersect $v হল allpaths(foo/...,//common) intersect foo/... সমতুল্য।

একটি এনক্লোসিং let name = ... এক্সপ্রেশন ছাড়া অন্য একটি পরিবর্তনশীল রেফারেন্স name একটি ঘটনা একটি ত্রুটি। অন্য কথায়, টপ-লেভেল কোয়েরি এক্সপ্রেশনে ফ্রি ভেরিয়েবল থাকতে পারে না।

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

প্রতিটি let এক্সপ্রেশন শুধুমাত্র একটি একক ভেরিয়েবলকে সংজ্ঞায়িত করে, কিন্তু আপনি তাদের নেস্ট করতে পারেন।

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

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

বন্ধনী অভিব্যক্তি

expr ::= (expr)

বন্ধনীগুলি মূল্যায়নের ক্রম জোরদার করার জন্য সাব এক্সপ্রেশনগুলিকে সংযুক্ত করে। একটি বন্ধনী অভিব্যক্তি তার যুক্তির মান মূল্যায়ন করে।

বীজগণিতীয় সেট অপারেশন: ছেদ, ইউনিয়ন, সেট পার্থক্য

expr ::= expr intersect expr
       | expr ^ expr
       | expr union expr
       | expr + expr
       | expr except expr
       | expr - expr

এই তিনটি অপারেটর তাদের আর্গুমেন্টের উপর স্বাভাবিক সেট অপারেশন গণনা করে। প্রতিটি অপারেটরের দুটি ফর্ম রয়েছে, একটি নামমাত্র ফর্ম, যেমন intersect , এবং একটি প্রতীকী ফর্ম, যেমন ^ । উভয় রূপই সমতুল্য; প্রতীকী ফর্ম দ্রুত টাইপ করা হয়. (স্বচ্ছতার জন্য, এই পৃষ্ঠার বাকি অংশ নামমাত্র ফর্ম ব্যবহার করে।)

উদাহরণ স্বরূপ,

foo/... except foo/bar/...

foo/... এর সাথে মেলে এমন লক্ষ্যের সেটে মূল্যায়ন করে কিন্তু foo/bar/... নয়।

আপনি একই প্রশ্ন লিখতে পারেন:

foo/... - foo/bar/...

intersect ( ^ ) এবং union ( + ) ক্রিয়াকলাপগুলি পরিবর্তনশীল (প্রতিসম); ( - ) except অসমমিত। পার্সার তিনটি অপারেটরকে বাম-সহযোগী এবং সমান অগ্রাধিকার হিসাবে বিবেচনা করে, তাই আপনি বন্ধনী চাইতে পারেন। উদাহরণস্বরূপ, এই অভিব্যক্তিগুলির প্রথম দুটি সমতুল্য, কিন্তু তৃতীয়টি নয়:

x intersect y union z
(x intersect y) union z
x intersect (y union z)

একটি বহিরাগত উত্স থেকে লক্ষ্য পড়ুন: সেট

expr ::= set(word *)

set( a b c ...) অপারেটর শূন্য বা ততোধিক টার্গেট প্যাটার্নের একটি সেটের মিলন গণনা করে, শ্বেতস্থান (কোনও কমা নেই) দ্বারা বিভক্ত।

বোর্ন শেল এর $(...) বৈশিষ্ট্যের সাথে একত্রে, set() একটি নিয়মিত টেক্সট ফাইলে একটি প্রশ্নের ফলাফল সংরক্ষণ করার একটি উপায় প্রদান করে, অন্যান্য প্রোগ্রাম (যেমন স্ট্যান্ডার্ড UNIX শেল টুলস) ব্যবহার করে সেই টেক্সট ফাইলটি পরিচালনা করে এবং তারপর পরবর্তী প্রক্রিয়াকরণের জন্য একটি মান হিসাবে ক্যোয়ারী টুলে ফলাফলটি প্রবর্তন করা হচ্ছে। উদাহরণ স্বরূপ:

bazel query deps(//my:target) --output=label | grep ... | sed ... | awk ... > foo
bazel query "kind(cc_binary, set($(<foo)))"

পরবর্তী উদাহরণে, kind(cc_library, deps(//some_dir/foo:main, 5)) একটি awk প্রোগ্রাম ব্যবহার করে maxrank মান ফিল্টার করে গণনা করা হয়।

bazel query 'deps(//some_dir/foo:main)' --output maxrank | awk '($1 < 5) { print $2;} ' > foo
bazel query "kind(cc_library, set($(<foo)))"

এই উদাহরণগুলিতে, $(<foo) হল $(cat foo) এর একটি সংক্ষিপ্ত বিবরণ, কিন্তু cat ছাড়া অন্য শেল কমান্ডগুলিও ব্যবহার করা যেতে পারে—যেমন পূর্ববর্তী awk কমান্ড।

ফাংশন

expr ::= word '(' int | word | expr ... ')'

ক্যোয়ারী ভাষা বিভিন্ন ফাংশন সংজ্ঞায়িত করে। ফাংশনের নাম এটির প্রয়োজনীয় আর্গুমেন্টের সংখ্যা এবং প্রকার নির্ধারণ করে। নিম্নলিখিত ফাংশন উপলব্ধ:

allpaths
attr
buildfiles
rbuildfiles
deps
filter
kind
labels
loadfiles
rdeps
allrdeps
same_pkg_direct_rdeps
siblings
some
somepath
tests
visible

নির্ভরতা ট্রানজিটিভ ক্লোজার: ডিপস

expr ::= deps(expr)
       | deps(expr, depth)

deps( x ) অপারেটর তার আর্গুমেন্ট সেট x এর নির্ভরতার ট্রানজিটিভ ক্লোজার দ্বারা গঠিত গ্রাফের মূল্যায়ন করে। উদাহরণস্বরূপ, deps(//foo) এর মান হল একক নোড foo তে মূল নির্ভরতা গ্রাফ, এর সমস্ত নির্ভরতা সহ। deps(foo/...) এর মান হল নির্ভরতা গ্রাফ যার মূলগুলি foo ডিরেক্টরির নীচে প্রতিটি প্যাকেজের সমস্ত নিয়ম। এই প্রসঙ্গে, 'নির্ভরতা' মানে শুধুমাত্র নিয়ম এবং ফাইল লক্ষ্যমাত্রা, তাই এই লক্ষ্যগুলি তৈরি করার জন্য BUILD এবং Starlark ফাইলগুলি এখানে অন্তর্ভুক্ত করা হয়নি। এর জন্য আপনাকে buildfiles অপারেটর ব্যবহার করতে হবে।

ফলাফল গ্রাফ নির্ভরতা সম্পর্ক অনুযায়ী আদেশ করা হয়. আরও বিশদ বিবরণের জন্য, গ্রাফ অর্ডারের বিভাগটি দেখুন।

deps অপারেটর একটি ঐচ্ছিক দ্বিতীয় আর্গুমেন্ট গ্রহণ করে, যা একটি পূর্ণসংখ্যা আক্ষরিক যা অনুসন্ধানের গভীরতার উপর একটি ঊর্ধ্ব সীমা নির্দিষ্ট করে। সুতরাং deps(foo:*, 0) foo প্যাকেজে সমস্ত লক্ষ্য ফেরত দেয়, যখন deps(foo:*, 1) foo প্যাকেজে যেকোনো লক্ষ্যের সরাসরি পূর্বশর্ত অন্তর্ভুক্ত করে, এবং deps(foo:*, 2) আরও অন্তর্ভুক্ত করে। deps(foo:*, 1) , ইত্যাদিতে নোড থেকে সরাসরি নোডগুলি পৌঁছানো যায়। (এই সংখ্যাগুলি minrank আউটপুট বিন্যাসে দেখানো র‌্যাঙ্কগুলির সাথে মিলে যায়৷) যদি depth প্যারামিটারটি বাদ দেওয়া হয়, অনুসন্ধানটি সীমাহীন: এটি পূর্বশর্তগুলির প্রতিফলিত ট্রানজিটিভ ক্লোজার গণনা করে৷

বিপরীত নির্ভরতার ট্রানজিটিভ ক্লোজার: rdeps

expr ::= rdeps(expr, expr)
       | rdeps(expr, expr, depth)

rdeps( u , x ) অপারেটর মহাবিশ্ব সেট u এর ট্রানজিটিভ ক্লোজারের মধ্যে আর্গুমেন্ট সেট x এর বিপরীত নির্ভরতাকে মূল্যায়ন করে।

ফলাফল গ্রাফ নির্ভরতা সম্পর্ক অনুযায়ী আদেশ করা হয়. আরও বিস্তারিত জানার জন্য গ্রাফ অর্ডারের বিভাগটি দেখুন।

rdeps অপারেটর একটি ঐচ্ছিক তৃতীয় আর্গুমেন্ট গ্রহণ করে, যা একটি পূর্ণসংখ্যা আক্ষরিক যা অনুসন্ধানের গভীরতার উপর একটি উপরের সীমা নির্দিষ্ট করে। ফলস্বরূপ গ্রাফে শুধুমাত্র আর্গুমেন্ট সেটের যেকোনো নোড থেকে নির্দিষ্ট গভীরতার দূরত্বের মধ্যে নোড অন্তর্ভুক্ত থাকে। সুতরাং rdeps(//foo, //common, 1) এর ট্রানজিটিভ ক্লোজারের সমস্ত নোডের মূল্যায়ন করে যা সরাসরি //foo //common এর উপর নির্ভর করে। (এই সংখ্যাগুলি minrank আউটপুট ফর্ম্যাটে দেখানো র‌্যাঙ্কের সাথে মিলে যায়।) যদি depth পরামিতি বাদ দেওয়া হয়, অনুসন্ধানটি সীমাহীন।

সমস্ত বিপরীত নির্ভরতার ট্রানজিটিভ ক্লোজার: allrdeps

expr ::= allrdeps(expr)
       | allrdeps(expr, depth)

allrdeps অপারেটর ঠিক rdeps অপারেটরের মতো আচরণ করে, আলাদাভাবে নির্দিষ্ট করার পরিবর্তে "ইউনিভার্স সেট" --universe_scope পতাকা মূল্যায়ন করা যাই হোক না কেন। এইভাবে, যদি --universe_scope=//foo/... পাস করা হয়, তাহলে allrdeps(//bar) rdeps(//foo/..., //bar) এর সমতুল্য।

একই প্যাকেজে সরাসরি বিপরীত নির্ভরতা: same_pkg_direct_rdeps

expr ::= same_pkg_direct_rdeps(expr)

same_pkg_direct_rdeps( x ) অপারেটর সেই লক্ষ্যগুলির সম্পূর্ণ সেটের মূল্যায়ন করে যা একই প্যাকেজে থাকে আর্গুমেন্ট সেটের লক্ষ্য হিসাবে, এবং যা সরাসরি এটির উপর নির্ভর করে।

লক্ষ্যের প্যাকেজ নিয়ে কাজ করা: ভাইবোন

expr ::= siblings(expr)

siblings( x ) অপারেটর টার্গেটের সম্পূর্ণ সেটের মূল্যায়ন করে যা আর্গুমেন্ট সেটের লক্ষ্য হিসাবে একই প্যাকেজে থাকে।

নির্বিচারে পছন্দ: কিছু

expr ::= some(expr)
       | some(expr, count )

some( x , k ) অপারেটর তার আর্গুমেন্ট সেট x থেকে নির্বিচারে সর্বাধিক k টার্গেট নির্বাচন করে এবং শুধুমাত্র সেই টার্গেট সমন্বিত একটি সেটে মূল্যায়ন করে। প্যারামিটার k ঐচ্ছিক; যদি অনুপস্থিত থাকে, ফলাফলটি হবে একটি সিঙ্গলটন সেট যাতে শুধুমাত্র একটি লক্ষ্যমাত্রা নির্বিচারে নির্বাচিত হয়। আর্গুমেন্ট সেট x এর আকার k এর থেকে ছোট হলে, পুরো আর্গুমেন্ট সেট x ফেরত দেওয়া হবে।

উদাহরণ স্বরূপ, some(//foo:main union //bar:baz) অভিব্যক্তিটি //foo:main বা //bar:baz ধারণ করে একটি সিঙ্গলটন সেটের মূল্যায়ন করে — যদিও কোনটি সংজ্ঞায়িত করা হয়নি। some(//foo:main union //bar:baz, 2) বা some(//foo:main union //bar:baz, 3) অভিব্যক্তি //foo:main এবং //bar:baz উভয়ই প্রদান করে।

যদি আর্গুমেন্টটি সিঙ্গেলটন হয়, তাহলে some পরিচয় ফাংশন গণনা করে: some(//foo:main) //foo:main সমতুল্য।

নির্দিষ্ট আর্গুমেন্ট সেটটি খালি থাকলে এটি একটি ত্রুটি, যেমন অভিব্যক্তি some(//foo:main intersect //bar:baz) ।

পাথ অপারেটর: somepath, allpaths

expr ::= somepath(expr, expr)
       | allpaths(expr, expr)

somepath( S , E ) এবং allpaths( S , E ) অপারেটর দুটি লক্ষ্যের সেটের মধ্যে পাথ গণনা করে। উভয় প্রশ্নই দুটি আর্গুমেন্ট গ্রহণ করে, প্রারম্ভিক বিন্দুর একটি সেট S এবং শেষ বিন্দুর একটি সেট E somepath কিছু নির্বিচারে নোডের গ্রাফকে S এর লক্ষ্য থেকে E তে একটি লক্ষ্যে ফেরত দেয়; allpaths S এর যেকোনো টার্গেট থেকে E এর যেকোনো টার্গেটে সমস্ত পাথে নোডের গ্রাফ ফেরত দেয়।

কিছুপথ — `somepath(S1 + S2, E)` , একটি সম্ভাব্য ফলাফল।

লক্ষ্য ধরনের ফিল্টারিং: ধরনের

expr ::= kind(word, expr)

kind( pattern , input ) অপারেটর লক্ষ্যগুলির একটি সেটে একটি ফিল্টার প্রয়োগ করে এবং সেই লক্ষ্যগুলি বাতিল করে যা প্রত্যাশিত ধরণের নয়। pattern প্যারামিটার নির্দিষ্ট করে কোন ধরনের লক্ষ্য মেলে।

উদাহরণ স্বরূপ, নিচে দেখানো BUILD ফাইল (প্যাকেজ p এর জন্য) দ্বারা সংজ্ঞায়িত চারটি লক্ষ্যের প্রকারগুলি টেবিলে চিত্রিত করা হয়েছে:

কোড	টার্গেট	সদয়
genrule( name = "a", srcs = ["a.in"], outs = ["a.out"], cmd = "...", )	`//p:a`	genrule নিয়ম
	`//p:a.in`	উৎস ফাইল
	`//p:a.out`	উত্পন্ন ফাইল
	`//p:BUILD`	উৎস ফাইল

এইভাবে, kind("cc_.* rule", foo/...) মূল্যায়ন করে সমস্ত cc_library , cc_binary ইত্যাদির সেটে, foo এর নিচে নিয়ম লক্ষ্য এবং kind("source file", deps(//foo)) মূল্যায়ন করে //foo টার্গেটের নির্ভরতার ট্রানজিটিভ ক্লোজারে সমস্ত সোর্স ফাইলের সেটে।

pattern আর্গুমেন্টের উদ্ধৃতি প্রায়ই প্রয়োজন হয় কারণ এটি ছাড়া, অনেক রেগুলার এক্সপ্রেশন , যেমন source file এবং .*_test , পার্সার দ্বারা শব্দ হিসাবে বিবেচিত হয় না।

package group সাথে মিলে যাওয়ার সময়, লক্ষ্যগুলি শেষ হয় :all কোনো ফলাফল নাও দিতে পারে। এর পরিবর্তে :all-targets ব্যবহার করুন।

টার্গেট নাম ফিল্টারিং: ফিল্টার

expr ::= filter(word, expr)

filter( pattern , input ) অপারেটর লক্ষ্যগুলির একটি সেটে একটি ফিল্টার প্রয়োগ করে এবং লক্ষ্যগুলি বাতিল করে যার লেবেলগুলি (পরম আকারে) প্যাটার্নের সাথে মেলে না; এটি তার ইনপুটের একটি উপসেটের মূল্যায়ন করে।

প্রথম যুক্তি, pattern টার্গেট নামের উপর একটি নিয়মিত অভিব্যক্তি ধারণকারী একটি শব্দ। একটি filter এক্সপ্রেশন সমস্ত টার্গেট x সমন্বিত সেটের মূল্যায়ন করে যেমন x সেট input সদস্য এবং x এর লেবেল (পরম আকারে, যেমন //foo:bar ) রেগুলার এক্সপ্রেশন pattern জন্য একটি (অনঙ্করড) মিল রয়েছে . যেহেতু সমস্ত টার্গেট নাম // দিয়ে শুরু হয়, তাই এটি ^ রেগুলার এক্সপ্রেশন অ্যাঙ্করের বিকল্প হিসেবে ব্যবহার করা যেতে পারে।

এই অপারেটর প্রায়ই intersect অপারেটরের জন্য একটি অনেক দ্রুত এবং আরও শক্তিশালী বিকল্প প্রদান করে। উদাহরণস্বরূপ, //foo:foo লক্ষ্যের সমস্ত bar নির্ভরতা দেখতে, কেউ মূল্যায়ন করতে পারে

deps(//foo) intersect //bar/...

এই বিবৃতিটি, যাইহোক, bar ট্রিতে সমস্ত BUILD ফাইলের পার্সিং প্রয়োজন, যা ধীরগতির এবং অপ্রাসঙ্গিক BUILD ফাইলগুলিতে ত্রুটির প্রবণ। একটি বিকল্প হবে:

filter(//bar, deps(//foo))

যা প্রথমে //foo নির্ভরতার সেট গণনা করবে এবং তারপর শুধুমাত্র প্রদত্ত প্যাটার্নের সাথে মিলে যাওয়া লক্ষ্যগুলিকে ফিল্টার করবে—অন্য কথায়, একটি সাবস্ট্রিং হিসাবে //bar ধারণকারী নামের সাথে লক্ষ্যগুলি।

filter( pattern , expr ) অপারেটরের আরেকটি সাধারণ ব্যবহার হল নির্দিষ্ট ফাইলগুলিকে তাদের নাম বা এক্সটেনশন দ্বারা ফিল্টার করা। উদাহরণ স্বরূপ,

filter("\.cc$", deps(//foo))

//foo নির্মাণে ব্যবহৃত সমস্ত .cc ফাইলের একটি তালিকা প্রদান করবে।

নিয়ম বৈশিষ্ট্য ফিল্টারিং: attr

expr ::= attr(word, word, expr)

attr( name , pattern , input ) অপারেটর লক্ষ্যগুলির একটি সেটে একটি ফিল্টার প্রয়োগ করে এবং লক্ষ্যমাত্রাগুলি বাতিল করে যা নিয়ম নয়, নিয়ম লক্ষ্যগুলি যেগুলির বৈশিষ্ট্যের name সংজ্ঞায়িত নেই বা নিয়ম লক্ষ্যগুলি যেখানে বৈশিষ্ট্যের মান প্রদত্ত রেগুলারের সাথে মেলে না অভিব্যক্তি pattern ; এটি তার ইনপুটের একটি উপসেটের মূল্যায়ন করে।

প্রথম আর্গুমেন্ট, name হল নিয়ম অ্যাট্রিবিউটের নাম যা প্রদত্ত রেগুলার এক্সপ্রেশন প্যাটার্নের সাথে মিলিত হওয়া উচিত। দ্বিতীয় যুক্তি, pattern হল অ্যাট্রিবিউট মানগুলির উপর একটি নিয়মিত অভিব্যক্তি। একটি attr অভিব্যক্তি সমস্ত টার্গেট x সমন্বিত সেটের মূল্যায়ন করে যেমন x সেট input সদস্য, এটি সংজ্ঞায়িত অ্যাট্রিবিউট name একটি নিয়ম এবং অ্যাট্রিবিউটের মান রেগুলার এক্সপ্রেশন pattern জন্য একটি (অনঙ্করড) মিল রয়েছে। যদি name একটি ঐচ্ছিক বৈশিষ্ট্য হয় এবং নিয়ম এটি স্পষ্টভাবে উল্লেখ না করে তাহলে ডিফল্ট অ্যাট্রিবিউট মান তুলনা করার জন্য ব্যবহার করা হবে। উদাহরণ স্বরূপ,

attr(linkshared, 0, deps(//foo))

সমস্ত //foo নির্ভরতা নির্বাচন করবে যেগুলি একটি লিঙ্কশেয়ার অ্যাট্রিবিউট (যেমন, cc_binary নিয়ম) রাখার অনুমতি দেওয়া হয়েছে এবং এটিকে স্পষ্টভাবে 0 তে সেট করতে হবে বা এটি একেবারেই সেট করবেন না কিন্তু ডিফল্ট মান 0 (যেমন cc_binary নিয়মগুলির জন্য)।

লিস্ট-টাইপ অ্যাট্রিবিউটগুলি (যেমন srcs , data ইত্যাদি) ফর্মের স্ট্রিংগুলিতে রূপান্তরিত হয় [value<sub>1</sub>, ..., value<sub>n</sub>] , একটি [ দিয়ে শুরু হয় বন্ধনী, একটি ] বন্ধনী দিয়ে শেষ হয় এবং একাধিক মান সীমাবদ্ধ করতে " , " (কমা, স্থান) ব্যবহার করে। লেবেলের পরম ফর্ম ব্যবহার করে লেবেলগুলিকে স্ট্রিংয়ে রূপান্তরিত করা হয়। উদাহরণস্বরূপ, একটি অ্যাট্রিবিউট deps=[":foo", "//otherpkg:bar", "wiz"] স্ট্রিং [//thispkg:foo, //otherpkg:bar, //thispkg:wiz] এ রূপান্তরিত হবে . বন্ধনী সবসময় উপস্থিত থাকে, তাই খালি তালিকাটি মিলের উদ্দেশ্যে স্ট্রিং মান [] ব্যবহার করবে। উদাহরণ স্বরূপ,

attr("srcs", "\[\]", deps(//foo))

একটি খালি srcs অ্যাট্রিবিউট আছে এমন //foo নির্ভরতার মধ্যে সমস্ত নিয়ম নির্বাচন করবে, যখন

attr("data", ".{3,}", deps(//foo))

//foo নির্ভরতাগুলির মধ্যে সমস্ত নিয়ম নির্বাচন করবে যা data অ্যাট্রিবিউটে কমপক্ষে একটি মান নির্দিষ্ট করে (প্রতিটি লেবেল // এবং : এর কারণে কমপক্ষে 3 অক্ষর দীর্ঘ)।

লিস্ট-টাইপ অ্যাট্রিবিউটে একটি নির্দিষ্ট value সহ //foo নির্ভরতার মধ্যে সমস্ত নিয়ম নির্বাচন করতে, ব্যবহার করুন

attr("tags", "[\[ ]value[,\]]", deps(//foo))

এটি কাজ করে কারণ value আগে অক্ষরটি হবে [ বা একটি স্থান এবং value পরে অক্ষরটি একটি কমা বা ] হবে।

নিয়ম দৃশ্যমানতা ফিল্টারিং: দৃশ্যমান

expr ::= visible(expr, expr)

visible( predicate , input ) অপারেটর লক্ষ্যগুলির একটি সেটে একটি ফিল্টার প্রয়োগ করে এবং প্রয়োজনীয় দৃশ্যমানতা ছাড়াই লক্ষ্যগুলি বাতিল করে।

প্রথম আর্গুমেন্ট, predicate হল টার্গেটের একটি সেট যা আউটপুটে সমস্ত টার্গেট অবশ্যই দৃশ্যমান হতে হবে। একটি visible অভিব্যক্তি সমস্ত টার্গেট x সমন্বিত সেটের মূল্যায়ন করে যেমন x সেট input সদস্য, এবং সমস্ত লক্ষ্য y এর জন্য predicate x y এর কাছে দৃশ্যমান। উদাহরণ স্বরূপ:

visible(//foo, //bar:*)

প্যাকেজ //bar সমস্ত লক্ষ্য নির্বাচন করবে যা //foo দৃশ্যমানতা বিধিনিষেধ লঙ্ঘন না করে নির্ভর করতে পারে।

টাইপ লেবেলের নিয়ম বৈশিষ্ট্যের মূল্যায়ন: লেবেল

expr ::= labels(word, expr)

labels( attr_name , inputs ) অপারেটর সেট inputs কিছু নিয়মে "লেবেল" বা "লেবেলের তালিকা" টাইপের অ্যাট্রিবিউট attr_name এ নির্দিষ্ট লক্ষ্যগুলির সেট ফেরত দেয়।

উদাহরণস্বরূপ, labels(srcs, //foo) //foo নিয়মের srcs অ্যাট্রিবিউটে প্রদর্শিত লক্ষ্যগুলির সেট প্রদান করে। inputs সেটে srcs অ্যাট্রিবিউট সহ একাধিক নিয়ম থাকলে, তাদের srcs এর মিলন ফেরত দেওয়া হয়।

test_suites প্রসারিত করুন এবং ফিল্টার করুন: পরীক্ষা

expr ::= tests(expr)

tests( x ) অপারেটর সেট x এ সমস্ত পরীক্ষার নিয়মের সেট ফেরত দেয়, যেকোন test_suite নিয়মগুলিকে পৃথক পরীক্ষার সেটে প্রসারিত করে এবং tag এবং size অনুসারে ফিল্টারিং প্রয়োগ করে।

ডিফল্টরূপে, ক্যোয়ারী মূল্যায়ন সমস্ত test_suite নিয়মে কোনো অ-পরীক্ষা লক্ষ্য উপেক্ষা করে। এটি --strict_test_suite বিকল্পের সাথে ত্রুটিতে পরিবর্তন করা যেতে পারে।

উদাহরণস্বরূপ, ক্যোয়ারী kind(test, foo:*) foo প্যাকেজের সমস্ত *_test এবং test_suite নিয়মগুলি তালিকাভুক্ত করে। সমস্ত ফলাফল (সংজ্ঞা অনুসারে) foo প্যাকেজের সদস্য। বিপরীতে, ক্যোয়ারী tests(foo:*) bazel test foo:* : এতে অন্যান্য প্যাকেজগুলির সাথে সম্পর্কিত পরীক্ষাগুলি অন্তর্ভুক্ত থাকতে পারে, যেগুলি test_suite নিয়মের মাধ্যমে প্রত্যক্ষ বা পরোক্ষভাবে উল্লেখ করা হয়েছে।

প্যাকেজ সংজ্ঞা ফাইল: বিল্ড ফাইল

expr ::= buildfiles(expr)

buildfiles( x ) অপারেটর ফাইলের সেট ফেরত দেয় যা সেট x এ প্রতিটি টার্গেটের প্যাকেজ সংজ্ঞায়িত করে; অন্য কথায়, প্রতিটি প্যাকেজের জন্য, এর BUILD ফাইল, প্লাস যেকোন .bzl ফাইল যা এটি load মাধ্যমে উল্লেখ করে। মনে রাখবেন যে এটি এই load করা ফাইলগুলি ধারণকারী প্যাকেজের BUILD ফাইলগুলিও ফেরত দেয়।

এই অপারেটরটি সাধারণত ব্যবহৃত হয় যখন একটি নির্দিষ্ট টার্গেট তৈরি করার জন্য কোন ফাইল বা প্যাকেজগুলি প্রয়োজন তা নির্ধারণ করার জন্য, প্রায়ই নীচে --output package বিকল্পের সাথে)। উদাহরণ স্বরূপ,

bazel query 'buildfiles(deps(//foo))' --output package

//foo ট্রানজিটিভভাবে নির্ভর করে এমন সমস্ত প্যাকেজের সেট ফেরত দেয়।

সতর্কতা: Bazel ভান করে যে buildfiles দ্বারা উত্পাদিত প্রতিটি .bzl ফাইলের একটি সংশ্লিষ্ট লক্ষ্য থাকে (উদাহরণস্বরূপ, ফাইল a/b.bzl => target //a:b.bzl ), তবে এটি অগত্যা নয়। অতএব, buildfiles অন্যান্য কোয়েরি অপারেটরগুলির সাথে ভালভাবে রচনা করে না এবং এর ফলাফলগুলি বিভ্রান্তিকর হতে পারে যখন একটি কাঠামোগত উপায়ে ফর্ম্যাট করা হয়, যেমন [--output=xml](#output-xml) ৷

প্যাকেজ সংজ্ঞা ফাইল: rbuildfiles

expr ::= rbuildfiles(word, ...)

rbuildfiles অপারেটর পাথের টুকরোগুলির একটি কমা-বিচ্ছিন্ন তালিকা নেয় এবং BUILD ফাইলগুলির সেট ফেরত দেয় যা এই পাথ খণ্ডগুলির উপর নির্ভর করে। উদাহরণস্বরূপ, যদি //foo একটি প্যাকেজ হয়, তাহলে rbuildfiles(foo/BUILD) //foo:BUILD লক্ষ্য ফেরত দেবে। যদি foo/BUILD ফাইলে load('//bar:file.bzl'... থাকে, তাহলে rbuildfiles(bar/file.bzl) //foo:BUILD টার্গেট, সেইসাথে যেকোনও জন্য টার্গেট প্রদান করবে। অন্যান্য BUILD ফাইল যা লোড //bar:file.bzl

এর পরিধি rbuildfiles অপারেটর হল --universe_scope পতাকা দ্বারা নির্দিষ্ট করা মহাবিশ্ব। যে ফাইলগুলি সরাসরি BUILD ফাইল এবং .bzl ফাইলগুলির সাথে সঙ্গতিপূর্ণ নয় সেগুলি ফলাফলগুলিকে প্রভাবিত করে না৷ উদাহরণস্বরূপ, উত্স ফাইলগুলি (যেমন foo.cc ) উপেক্ষা করা হয়, এমনকি যদি সেগুলি BUILD ফাইলে স্পষ্টভাবে উল্লেখ করা থাকে। সিমলিংক, তবে, সম্মান করা হয়, যাতে foo/BUILD যদি bar/BUILD এর একটি সিমলিঙ্ক হয়, তাহলে rbuildfiles(bar/BUILD) এর ফলাফলে //foo:BUILD অন্তর্ভুক্ত করবে।

rbuildfiles অপারেটর প্রায় নৈতিকভাবে buildfiles অপারেটরের বিপরীত। যাইহোক, এই নৈতিক বিপর্যয়টি এক দিক থেকে আরও দৃঢ়ভাবে ধরে রাখে: rbuildfiles buildfiles ; আগেরটিতে শুধুমাত্র প্যাকেজে BUILD ফাইল টার্গেট থাকবে এবং পরবর্তীতে এই ধরনের টার্গেট থাকতে পারে। অন্য দিকে, চিঠিপত্র দুর্বল। buildfiles অপারেটরের আউটপুটগুলি সমস্ত প্যাকেজের সাথে সম্পর্কিত লক্ষ্য এবং . bzl ফাইল একটি প্রদত্ত ইনপুট দ্বারা প্রয়োজন. যাইহোক, rbuildfiles অপারেটরের ইনপুটগুলি সেই লক্ষ্যগুলি নয়, বরং সেই লক্ষ্যগুলির সাথে সামঞ্জস্যপূর্ণ পাথের টুকরোগুলি।

প্যাকেজ সংজ্ঞা ফাইল: লোডফাইল

expr ::= loadfiles(expr)

loadfiles( x ) অপারেটর স্টারলার্ক ফাইলের সেট ফেরত দেয় যা প্রতিটি টার্গেটের প্যাকেজ সেট x এ লোড করার জন্য প্রয়োজন। অন্য কথায়, প্রতিটি প্যাকেজের জন্য, এটি .bzl ফাইলগুলিকে ফেরত দেয় যা তার BUILD ফাইলগুলি থেকে উল্লেখ করা হয়।

সতর্কতা: Bazel ভান করে যে এই .bzl ফাইলগুলির প্রতিটির একটি সংশ্লিষ্ট লক্ষ্য রয়েছে (উদাহরণস্বরূপ, ফাইল a/b.bzl => target //a:b.bzl ), কিন্তু এটি অগত্যা ক্ষেত্রে নয়। অতএব, loadfiles অন্যান্য ক্যোয়ারী অপারেটরগুলির সাথে ভালভাবে রচনা করে না এবং একটি কাঠামোগত উপায়ে ফর্ম্যাট করা হলে এর ফলাফলগুলি বিভ্রান্তিকর হতে পারে, যেমন [--output=xml](#output-xml) ৷

আউটপুট ফরম্যাট

bazel query একটি গ্রাফ তৈরি করে। আপনি --output কমান্ড-লাইন বিকল্পের মাধ্যমে bazel query এই গ্রাফটি উপস্থাপন করে কোন বিষয়বস্তু, বিন্যাস এবং ক্রমানুসারে নির্দিষ্ট করুন।

Sky Query- এর সাথে চলার সময়, শুধুমাত্র এমন আউটপুট ফরম্যাটগুলিকে অনুমতি দেওয়া হয় যেগুলি বিন্যাসহীন আউটপুটের সাথে সামঞ্জস্যপূর্ণ। বিশেষত, graph , minrank , এবং maxrank আউটপুট ফরম্যাটগুলি নিষিদ্ধ৷

কিছু আউটপুট ফরম্যাট অতিরিক্ত বিকল্প গ্রহণ করে। প্রতিটি আউটপুট বিকল্পের নাম আউটপুট বিন্যাসের সাথে প্রিফিক্স করা হয় যেখানে এটি প্রযোজ্য, তাই --graph:factored শুধুমাত্র তখনই প্রযোজ্য হয় যখন --output=graph ব্যবহার করা হয়; graph ছাড়া অন্য কোনো আউটপুট বিন্যাস ব্যবহার করা হলে এর কোনো প্রভাব নেই। একইভাবে, --xml:line_numbers শুধুমাত্র তখনই প্রযোজ্য যখন --output=xml ব্যবহার করা হচ্ছে।

ফলাফল ক্রম উপর

যদিও ক্যোয়ারী এক্সপ্রেশনগুলি সর্বদা " গ্রাফ অর্ডার সংরক্ষণের আইন " অনুসরণ করে, ফলাফলগুলি উপস্থাপন করা হয় নির্ভরতা-অনুযায়ী বা অবিন্যস্ত পদ্ধতিতে করা যেতে পারে। এটি ফলাফল সেটের লক্ষ্য বা কোয়েরিটি কীভাবে গণনা করা হয় তা প্রভাবিত করে না। এটা শুধুমাত্র কিভাবে ফলাফল stdout মুদ্রিত হয় প্রভাবিত করে। Moreover, nodes that are equivalent in the dependency order may or may not be ordered alphabetically. The --order_output flag can be used to control this behavior. (The --[no]order_results flag has a subset of the functionality of the --order_output flag and is deprecated.)

The default value of this flag is auto , which prints results in lexicographical order . However, when somepath(a,b) is used, the results will be printed in deps order instead.

When this flag is no and --output is one of build , label , label_kind , location , package , proto , or xml , the outputs will be printed in arbitrary order. This is generally the fastest option . It is not supported though when --output is one of graph , minrank or maxrank : with these formats, Bazel always prints results ordered by the dependency order or rank.

When this flag is deps , Bazel prints results in some topological order—that is, dependencies first. However, nodes that are unordered by the dependency order (because there is no path from either one to the other) may be printed in any order.

When this flag is full , Bazel prints nodes in a fully deterministic (total) order. First, all nodes are sorted alphabetically. Then, each node in the list is used as the start of a post-order depth-first search in which outgoing edges to unvisited nodes are traversed in alphabetical order of the successor nodes. Finally, nodes are printed in the reverse of the order in which they were visited.

Printing nodes in this order may be slower, so it should be used only when determinism is important.

Print the source form of targets as they would appear in BUILD

--output build

With this option, the representation of each target is as if it were hand-written in the BUILD language. All variables and function calls (such as glob, macros) are expanded, which is useful for seeing the effect of Starlark macros. Additionally, each effective rule reports a generator_name and/or generator_function ) value, giving the name of the macro that was evaluated to produce the effective rule.

Although the output uses the same syntax as BUILD files, it is not guaranteed to produce a valid BUILD file.

Print the label of each target

--output label

With this option, the set of names (or labels ) of each target in the resulting graph is printed, one label per line, in topological order (unless --noorder_results is specified, see notes on the ordering of results ). (A topological ordering is one in which a graph node appears earlier than all of its successors.) Of course there are many possible topological orderings of a graph ( reverse postorder is just one); which one is chosen is not specified.

When printing the output of a somepath query, the order in which the nodes are printed is the order of the path.

Caveat: in some corner cases, there may be two distinct targets with the same label; for example, a sh_binary rule and its sole (implicit) srcs file may both be called foo.sh . If the result of a query contains both of these targets, the output (in label format) will appear to contain a duplicate. When using the label_kind (see below) format, the distinction becomes clear: the two targets have the same name, but one has kind sh_binary rule and the other kind source file .

Print the label and kind of each target

--output label_kind

Like label , this output format prints the labels of each target in the resulting graph, in topological order, but it additionally precedes the label by the kind of the target.

Print the label of each target, in rank order

--output minrank --output maxrank

Like label , the minrank and maxrank output formats print the labels of each target in the resulting graph, but instead of appearing in topological order, they appear in rank order, preceded by their rank number. These are unaffected by the result ordering --[no]order_results flag (see notes on the ordering of results ).

There are two variants of this format: minrank ranks each node by the length of the shortest path from a root node to it. "Root" nodes (those which have no incoming edges) are of rank 0, their successors are of rank 1, etc. (As always, edges point from a target to its prerequisites: the targets it depends upon.)

maxrank ranks each node by the length of the longest path from a root node to it. Again, "roots" have rank 0, all other nodes have a rank which is one greater than the maximum rank of all their predecessors.

All nodes in a cycle are considered of equal rank. (Most graphs are acyclic, but cycles do occur simply because BUILD files contain erroneous cycles.)

These output formats are useful for discovering how deep a graph is. If used for the result of a deps(x) , rdeps(x) , or allpaths query, then the rank number is equal to the length of the shortest (with minrank ) or longest (with maxrank ) path from x to a node in that rank. maxrank can be used to determine the longest sequence of build steps required to build a target.

For example, the graph on the left yields the outputs on the right when --output minrank and --output maxrank are specified, respectively.

      minrank

      0 //c:c
      1 //b:b
      1 //a:a
      2 //b:b.cc
      2 //a:a.cc

      maxrank

      0 //c:c
      1 //b:b
      2 //a:a
      2 //b:b.cc
      3 //a:a.cc

Print the location of each target

--output location

Like label_kind , this option prints out, for each target in the result, the target's kind and label, but it is prefixed by a string describing the location of that target, as a filename and line number. The format resembles the output of grep . Thus, tools that can parse the latter (such as Emacs or vi) can also use the query output to step through a series of matches, allowing the Bazel query tool to be used as a dependency-graph-aware "grep for BUILD files".

The location information varies by target kind (see the kind operator). For rules, the location of the rule's declaration within the BUILD file is printed. For source files, the location of line 1 of the actual file is printed. For a generated file, the location of the rule that generates it is printed. (The query tool does not have sufficient information to find the actual location of the generated file, and in any case, it might not exist if a build has not yet been performed.)

Print the set of packages

--output package

This option prints the name of all packages to which some target in the result set belongs. The names are printed in lexicographical order; duplicates are excluded. Formally, this is a projection from the set of labels (package, target) onto packages.

Packages in external repositories are formatted as @repo//foo/bar while packages in the main repository are formatted as foo/bar .

In conjunction with the deps(...) query, this output option can be used to find the set of packages that must be checked out in order to build a given set of targets.

Display a graph of the result

--output graph

This option causes the query result to be printed as a directed graph in the popular AT&T GraphViz format. Typically the result is saved to a file, such as .png or .svg . (If the dot program is not installed on your workstation, you can install it using the command sudo apt-get install graphviz .) See the example section below for a sample invocation.

This output format is particularly useful for allpaths , deps , or rdeps queries, where the result includes a set of paths that cannot be easily visualized when rendered in a linear form, such as with --output label .

By default, the graph is rendered in a factored form. That is, topologically-equivalent nodes are merged together into a single node with multiple labels. This makes the graph more compact and readable, because typical result graphs contain highly repetitive patterns. For example, a java_library rule may depend on hundreds of Java source files all generated by the same genrule ; in the factored graph, all these files are represented by a single node. This behavior may be disabled with the --nograph:factored option.

`--graph:node_limit n`

The option specifies the maximum length of the label string for a graph node in the output. Longer labels will be truncated; -1 disables truncation. Due to the factored form in which graphs are usually printed, the node labels may be very long. GraphViz cannot handle labels exceeding 1024 characters, which is the default value of this option. This option has no effect unless --output=graph is being used.

`--[no]graph:factored`

By default, graphs are displayed in factored form, as explained above . When --nograph:factored is specified, graphs are printed without factoring. This makes visualization using GraphViz impractical, but the simpler format may ease processing by other tools (such as grep). This option has no effect unless --output=graph is being used.

XML

--output xml

This option causes the resulting targets to be printed in an XML form. The output starts with an XML header such as this

  <?xml version="1.0" encoding="UTF-8"?>
  <query version="2">

and then continues with an XML element for each target in the result graph, in topological order (unless unordered results are requested), and then finishes with a terminating

</query>

Simple entries are emitted for targets of file kind:

  <source-file name='//foo:foo_main.cc' .../>
  <generated-file name='//foo:libfoo.so' .../>

But for rules, the XML is structured and contains definitions of all the attributes of the rule, including those whose value was not explicitly specified in the rule's BUILD file.

Additionally, the result includes rule-input and rule-output elements so that the topology of the dependency graph can be reconstructed without having to know that, for example, the elements of the srcs attribute are forward dependencies (prerequisites) and the contents of the outs attribute are backward dependencies (consumers).

rule-input elements for implicit dependencies are suppressed if --noimplicit_deps is specified.

  <rule class='cc_binary rule' name='//foo:foo' ...>
    <list name='srcs'>
      <label value='//foo:foo_main.cc'/>
      <label value='//foo:bar.cc'/>
      ...
    </list>
    <list name='deps'>
      <label value='//common:common'/>
      <label value='//collections:collections'/>
      ...
    </list>
    <list name='data'>
      ...
    </list>
    <int name='linkstatic' value='0'/>
    <int name='linkshared' value='0'/>
    <list name='licenses'/>
    <list name='distribs'>
      <distribution value="INTERNAL" />
    </list>
    <rule-input name="//common:common" />
    <rule-input name="//collections:collections" />
    <rule-input name="//foo:foo_main.cc" />
    <rule-input name="//foo:bar.cc" />
    ...
  </rule>

Every XML element for a target contains a name attribute, whose value is the target's label, and a location attribute, whose value is the target's location as printed by the --output location .

`--[no]xml:line_numbers`

By default, the locations displayed in the XML output contain line numbers. When --noxml:line_numbers is specified, line numbers are not printed.

`--[no]xml:default_values`

By default, XML output does not include rule attribute whose value is the default value for that kind of attribute (for example, if it were not specified in the BUILD file, or the default value was provided explicitly). This option causes such attribute values to be included in the XML output.

Regular expressions

Regular expressions in the query language use the Java regex library, so you can use the full syntax for java.util.regex.Pattern .

Querying with external repositories

If the build depends on rules from external repositories (defined in the WORKSPACE file) then query results will include these dependencies. For example, if //foo:bar depends on //external:some-lib and //external:some-lib is bound to @other-repo//baz:lib , then bazel query 'deps(//foo:bar)' will list both @other-repo//baz:lib and //external:some-lib as dependencies.

External repositories themselves are not dependencies of a build. That is, in the example above, //external:other-repo is not a dependency. It can be queried for as a member of the //external package, though, for example:

  # Querying over all members of //external returns the repository.
  bazel query 'kind(http_archive, //external:*)'
  //external:other-repo

  # ...but the repository is not a dependency.
  bazel query 'kind(http_archive, deps(//foo:bar))'
  INFO: Empty results