লেবেল

সমস্ত লক্ষ্য ঠিক একটি প্যাকেজের অন্তর্গত। একটি লক্ষ্যের নাম তার লেবেল বলা হয়। প্রতিটি লেবেল অনন্যভাবে একটি লক্ষ্য চিহ্নিত করে। ক্যানোনিকাল আকারে একটি সাধারণ লেবেল এর মতো দেখায়:

@myrepo//my/app/main:app_binary

লেবেলের প্রথম অংশটি হল সংগ্রহস্থলের নাম, @myrepo// । সাধারণ ক্ষেত্রে যে একটি লেবেল একই রিপোজিটরিকে বোঝায় যেখান থেকে এটি ব্যবহার করা হয়, রিপোজিটরি শনাক্তকারীকে সংক্ষেপে // হিসাবে বলা যেতে পারে। সুতরাং, @myrepo এর ভিতরে এই লেবেলটি সাধারণত লেখা হয়

//my/app/main:app_binary

লেবেলের দ্বিতীয় অংশটি হল অ-যোগ্য প্যাকেজের নাম my/app/main , রিপোজিটরি রুটের সাথে সম্পর্কিত প্যাকেজের পথ। একত্রে, সংগ্রহস্থলের নাম এবং অ-যোগ্য প্যাকেজ নামটি সম্পূর্ণরূপে-যোগ্য প্যাকেজ নাম গঠন করে @myrepo//my/app/main । যখন লেবেলটি একই প্যাকেজকে বোঝায় যেখানে এটি ব্যবহৃত হয়, প্যাকেজের নাম (এবং ঐচ্ছিকভাবে, কোলন) বাদ দেওয়া হতে পারে। সুতরাং, @myrepo//my/app/main ভিতরে, এই লেবেলটি নিম্নলিখিত যে কোনও উপায়ে লেখা হতে পারে:

app_binary
:app_binary

এটি একটি প্রচলিত বিষয় যে কোলন ফাইলের জন্য বাদ দেওয়া হয়, তবে নিয়মের জন্য ধরে রাখা হয়, তবে এটি অন্যথায় তাৎপর্যপূর্ণ নয়।

কোলনের পরে লেবেলের অংশ, app_binary হল অ-যোগ্য লক্ষ্যের নাম। যখন এটি প্যাকেজ পথের শেষ উপাদানের সাথে মেলে, তখন এটি এবং কোলন বাদ দেওয়া যেতে পারে। সুতরাং, এই দুটি লেবেল সমতুল্য:

//my/app/lib
//my/app/lib:lib

প্যাকেজের একটি সাবডিরেক্টরিতে একটি ফাইল টার্গেটের নাম হল প্যাকেজ রুটের সাথে সম্পর্কিত ফাইলের পাথ ( BUILD ফাইল ধারণকারী ডিরেক্টরি)। সুতরাং, এই ফাইলটি সংগ্রহস্থলের my/app/main/testdata সাবডিরেক্টরিতে রয়েছে:

//my/app/main:testdata/input.txt

প্যাকেজ নামের সাথে //my/app এর মতো লেবেলগুলিকে বিভ্রান্ত করবেন না৷ লেবেলগুলি সর্বদা একটি সংগ্রহস্থল শনাক্তকারী দিয়ে শুরু হয় (প্রায়শই সংক্ষেপে // ), কিন্তু প্যাকেজ নামগুলি কখনই তা করে না। এইভাবে, my/app হল প্যাকেজ যাতে //my/app/lib (যাকে //my/app/lib:lib হিসাবেও লেখা যেতে পারে)।

একটি সাধারণ ভুল ধারণা হল যে //my/app একটি প্যাকেজ বা প্যাকেজের সমস্ত লক্ষ্যকে বোঝায়; কোনটিই সত্য নয়। মনে রাখবেন, এটি //my/app:app এর সমতুল্য, তাই এটি বর্তমান সংগ্রহস্থলের my/app প্যাকেজে app টার্গেটের নাম দেয়)।

আপেক্ষিক লেবেল অন্যান্য প্যাকেজের লক্ষ্য উল্লেখ করতে ব্যবহার করা যাবে না; এই ক্ষেত্রে সংগ্রহস্থল শনাক্তকারী এবং প্যাকেজের নাম সর্বদা নির্দিষ্ট করা আবশ্যক। উদাহরণস্বরূপ, যদি সোর্স ট্রিতে প্যাকেজ my/app এবং প্যাকেজ my/app/testdata থাকে (এই দুটি ডিরেক্টরির প্রত্যেকটির নিজস্ব BUILD ফাইল রয়েছে), পরবর্তী প্যাকেজে testdepot.zip নামে একটি ফাইল রয়েছে। এখানে দুটি উপায় রয়েছে (একটি ভুল, একটি সঠিক) এই ফাইলটি //my/app:BUILD মধ্যে উল্লেখ করার জন্য:

ভুল — testdata একটি ভিন্ন প্যাকেজ, তাই আপনি একটি আপেক্ষিক পথ ব্যবহার করতে পারবেন না

testdata/testdepot.zip

সঠিক — এর সম্পূর্ণ পাথ সহ testdata পড়ুন

//my/app/testdata:testdepot.zip

@// দিয়ে শুরু হওয়া লেবেলগুলি হল মূল সংগ্রহস্থলের রেফারেন্স, যা এখনও বহিরাগত সংগ্রহস্থল থেকেও কাজ করবে। তাই @//a/b/c একটি বহিরাগত সংগ্রহস্থল থেকে উল্লেখ করার সময় //a/b/c থেকে আলাদা। পূর্ববর্তীটি মূল সংগ্রহস্থলে ফিরে উল্লেখ করে, যখন পরবর্তীটি বাহ্যিক সংগ্রহস্থলে //a/b/c সন্ধান করে। এটি বিশেষভাবে প্রাসঙ্গিক যখন প্রধান সংগ্রহস্থলে নিয়মগুলি লেখার সময় যা মূল সংগ্রহস্থলের লক্ষ্যগুলি উল্লেখ করে এবং বহিরাগত সংগ্রহস্থল থেকে ব্যবহার করা হবে।

আপনি লক্ষ্যগুলি উল্লেখ করতে পারেন বিভিন্ন উপায় সম্পর্কে তথ্যের জন্য, লক্ষ্য নিদর্শন দেখুন।

একটি লেবেলের আভিধানিক স্পেসিফিকেশন

লেবেল সিনট্যাক্স মেটাক্যারেক্টারের ব্যবহারকে নিরুৎসাহিত করে যেগুলির শেলের বিশেষ অর্থ রয়েছে। এটি অসাবধানতাবশত উদ্ধৃতি সমস্যা এড়াতে সাহায্য করে এবং ব্যাজেল কোয়েরি ল্যাঙ্গুয়েজ এর মতো লেবেলগুলিকে ম্যানিপুলেট করে এমন সরঞ্জাম এবং স্ক্রিপ্টগুলি তৈরি করা সহজ করে তোলে।

অনুমোদিত টার্গেট নামের সুনির্দিষ্ট বিশদ নীচে রয়েছে।

টার্গেট নাম — package-name :target-name

target-name হল প্যাকেজের মধ্যে থাকা টার্গেটের নাম। একটি নিয়মের নাম হল একটি BUILD ফাইলে নিয়মের ঘোষণায় name বৈশিষ্ট্যের মান; একটি ফাইলের নাম হল BUILD ফাইল ধারণকারী ডিরেক্টরির সাথে সম্পর্কিত এর পাথনাম।

টার্গেটের নামগুলি সম্পূর্ণরূপে সেট a – z , A – Z , 0 – 9 , এবং যতিচিহ্ন চিহ্নগুলি থেকে আঁকা অক্ষরগুলির সমন্বয়ে গঠিত হতে হবে !%-@^_"#$&'()*-+,;<=>?[]{|}~/. ।

ফাইলের নামগুলি অবশ্যই স্বাভাবিক আকারে আপেক্ষিক পাথনাম হতে হবে, যার মানে সেগুলি অবশ্যই স্ল্যাশ দিয়ে শুরু বা শেষ হবে না (উদাহরণস্বরূপ, /foo এবং foo/ নিষিদ্ধ) বা পাথ বিভাজক হিসাবে একাধিক ক্রমাগত স্ল্যাশ ধারণ করতে হবে না (উদাহরণস্বরূপ, foo//bar )। একইভাবে, আপ-লেভেল রেফারেন্স ( .. ) এবং বর্তমান-ডিরেক্টরি রেফারেন্স ( ./ ) নিষিদ্ধ।

ভুল — অন্য প্যাকেজে ফাইল উল্লেখ করতে `..` ব্যবহার করবেন না

সঠিক — `// package-name : filename নাম` ব্যবহার করুন

একটি ফাইল টার্গেটের নামে / ব্যবহার করা সাধারণ হলেও, নিয়মের নামে / ব্যবহার এড়িয়ে চলুন। বিশেষ করে যখন একটি লেবেলের শর্টহ্যান্ড ফর্ম ব্যবহার করা হয়, তখন এটি পাঠককে বিভ্রান্ত করতে পারে। //foo/bar/wiz লেবেলটি সর্বদা //foo/bar/wiz:wiz এর জন্য একটি সংক্ষিপ্ত বিবরণ, এমনকি যদি এমন কোনো প্যাকেজ foo/bar/wiz না থাকে; এটি কখনই //foo:bar/wiz কে বোঝায় না, এমনকি যদি সেই লক্ষ্যটি বিদ্যমান থাকে।

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

প্যাকেজের নাম — //package-name: target-name

একটি প্যাকেজের নাম হল তার BUILD ফাইল ধারণকারী ডিরেক্টরির নাম, যা ধারণকারী সংগ্রহস্থলের শীর্ষ-স্তরের ডিরেক্টরির সাথে সম্পর্কিত। যেমন: my/app .

প্যাকেজের নামগুলি সম্পূর্ণরূপে A - Z , a – z , 0 – 9 , ' / ', ' - ', ' সেট থেকে আঁকা অক্ষরগুলির সমন্বয়ে তৈরি করা উচিত . ', ' @ ', এবং ' _ ', এবং একটি স্ল্যাশ দিয়ে শুরু করা যাবে না।

একটি ডিরেক্টরি কাঠামো সহ একটি ভাষার জন্য যা এর মডিউল সিস্টেমের জন্য তাৎপর্যপূর্ণ (উদাহরণস্বরূপ, জাভা), ভাষাতে বৈধ শনাক্তকারী ডিরেক্টরির নামগুলি বেছে নেওয়া গুরুত্বপূর্ণ।

যদিও Bazel ওয়ার্কস্পেসের রুট প্যাকেজে লক্ষ্যগুলিকে সমর্থন করে (উদাহরণস্বরূপ, //:foo ), সেই প্যাকেজটি খালি রাখাই উত্তম যাতে সমস্ত অর্থপূর্ণ প্যাকেজের বর্ণনামূলক নাম থাকে।

প্যাকেজের নামগুলিতে সাবস্ট্রিং // নাও থাকতে পারে এবং স্ল্যাশ দিয়ে শেষ নাও হতে পারে৷

নিয়ম

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

BUILD ফাইলগুলি নিয়ম চালু করে লক্ষ্য ঘোষণা করে।

নীচের উদাহরণে, আমরা cc_binary নিয়ম ব্যবহার করে লক্ষ্য my_app এর ঘোষণা দেখতে পাচ্ছি।

cc_binary(
    name = "my_app",
    srcs = ["my_app.cc"],
    deps = [
        "//absl/base",
        "//absl/strings",
    ],
)

প্রতিটি নিয়মের আমন্ত্রণের একটি name বৈশিষ্ট্য রয়েছে (যা অবশ্যই একটি বৈধ টার্গেট নাম হতে হবে), যা BUILD ফাইলের প্যাকেজের মধ্যে একটি লক্ষ্য ঘোষণা করে।

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

অনেক নিয়মে উপস্থিত srcs অ্যাট্রিবিউটে "লেবেলের তালিকা" টাইপ আছে; এর মান, যদি উপস্থিত থাকে, লেবেলের একটি তালিকা, প্রতিটি একটি লক্ষ্যের নাম যা এই নিয়মের একটি ইনপুট।

কিছু ক্ষেত্রে, নিয়মের ধরণের নাম কিছুটা স্বেচ্ছাচারী, এবং আরও আকর্ষণীয় হল নিয়ম দ্বারা তৈরি করা ফাইলগুলির নাম, এবং এটি জেনুলের ক্ষেত্রে সত্য। আরও তথ্যের জন্য, সাধারণ নিয়ম দেখুন: genrule ।

অন্যান্য ক্ষেত্রে, নামটি তাৎপর্যপূর্ণ: *_binary এবং *_test নিয়মের জন্য, উদাহরণস্বরূপ, নিয়মের নাম বিল্ড দ্বারা উত্পাদিত এক্সিকিউটেবলের নাম নির্ধারণ করে।

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