এই পৃষ্ঠাটি অনুমান করে যে আপনি Bazel এর সাথে পরিচিত এবং Bazel এর বৈশিষ্ট্যগুলির সম্পূর্ণ সুবিধা নেওয়ার জন্য আপনার প্রকল্পগুলিকে গঠন করার বিষয়ে নির্দেশিকা এবং পরামর্শ প্রদান করে৷
সামগ্রিক লক্ষ্য হল:
- সমান্তরালতা এবং বৃদ্ধির অনুমতি দিতে সূক্ষ্ম-দানাযুক্ত নির্ভরতা ব্যবহার করা।
- নির্ভরতা ভালভাবে এনক্যাপসুলেট রাখা.
- কোড সুগঠিত এবং পরীক্ষাযোগ্য করতে।
- একটি বিল্ড কনফিগারেশন তৈরি করতে যা বোঝা এবং বজায় রাখা সহজ।
এই নির্দেশিকাগুলি প্রয়োজনীয় নয়: কয়েকটি প্রকল্প তাদের সকলকে মেনে চলতে সক্ষম হবে৷ লিন্টের জন্য ম্যান পেজ যেমন বলে, "একটি বাস্তব প্রোগ্রাম তৈরি করার জন্য প্রথম ব্যক্তিকে একটি বিশেষ পুরষ্কার দেওয়া হবে যা কঠোর চেকিংয়ের সাথে কোনও ত্রুটি তৈরি করে না।" যাইহোক, যতটা সম্ভব এই নীতিগুলির মধ্যে অনেকগুলি অন্তর্ভুক্ত করার ফলে একটি প্রকল্পকে আরও পাঠযোগ্য, কম ত্রুটি-প্রবণ এবং দ্রুত নির্মাণ করা উচিত।
এই পৃষ্ঠাটি এই RFC- তে বর্ণিত প্রয়োজনীয় স্তরগুলি ব্যবহার করে৷
চলমান বিল্ড এবং পরীক্ষা
একটি প্রজেক্ট সর্বদা bazel build //... এবং bazel test //... সফলভাবে তার স্থিতিশীল শাখায় চালাতে সক্ষম হওয়া উচিত। যে লক্ষ্যগুলি প্রয়োজনীয় কিন্তু নির্দিষ্ট পরিস্থিতিতে তৈরি হয় না (যেমন, নির্দিষ্ট বিল্ড পতাকা প্রয়োজন, একটি নির্দিষ্ট প্ল্যাটফর্মে তৈরি করবেন না, লাইসেন্স চুক্তির প্রয়োজন) যথাসম্ভব বিশেষভাবে ট্যাগ করা উচিত (উদাহরণস্বরূপ, " requires-osx ") . এই ট্যাগিং লক্ষ্যগুলিকে "ম্যানুয়াল" ট্যাগের চেয়ে আরও সূক্ষ্ম-দানাযুক্ত স্তরে ফিল্টার করার অনুমতি দেয় এবং BUILD ফাইলটি পরিদর্শনকারী কাউকে লক্ষ্যের সীমাবদ্ধতাগুলি বুঝতে দেয়।
তৃতীয় পক্ষের নির্ভরতা
আপনি তৃতীয় পক্ষের নির্ভরতা ঘোষণা করতে পারেন:
- হয় তাদের
WORKSPACEফাইলে দূরবর্তী সংগ্রহস্থল হিসাবে ঘোষণা করুন। - অথবা এগুলিকে আপনার ওয়ার্কস্পেস ডিরেক্টরির অধীনে
third_party/নামক একটি ডিরেক্টরিতে রাখুন।
বাইনারি উপর নির্ভর করে
সবকিছু যখনই সম্ভব উৎস থেকে তৈরি করা উচিত। সাধারণত এর মানে হল, লাইব্রেরি some-library.so এর উপর নির্ভর না করে, আপনি একটি BUILD ফাইল তৈরি করবেন এবং তার উত্স থেকে some-library.so তৈরি করবেন, তারপর সেই লক্ষ্যের উপর নির্ভর করুন।
সর্বদা উৎস থেকে বিল্ডিং নিশ্চিত করে যে একটি বিল্ড একটি লাইব্রেরি ব্যবহার করছে না যা বেমানান পতাকা বা একটি ভিন্ন আর্কিটেকচার দিয়ে তৈরি করা হয়েছিল। কভারেজ, স্ট্যাটিক বিশ্লেষণ বা গতিশীল বিশ্লেষণের মতো কিছু বৈশিষ্ট্যও রয়েছে যা শুধুমাত্র উৎসের উপর কাজ করে।
সংস্করণ
যখনই সম্ভব মাথা থেকে সমস্ত কোড তৈরি করতে পছন্দ করুন। যখন সংস্করণগুলি ব্যবহার করতে হবে, তখন লক্ষ্যের নামে সংস্করণ অন্তর্ভুক্ত করা এড়িয়ে চলুন (উদাহরণস্বরূপ, //guava guava, না //guava-20.0 )। এই নামকরণ লাইব্রেরি আপডেট করা সহজ করে তোলে (শুধুমাত্র একটি লক্ষ্য আপডেট করা প্রয়োজন)। এটি হীরা নির্ভরতার সমস্যাগুলির জন্য আরও স্থিতিস্থাপক: যদি একটি লাইব্রেরি guava-19.0 এর উপর নির্ভর করে এবং একটি guava-20.0 এর উপর নির্ভর করে তবে আপনি একটি লাইব্রেরির সাথে শেষ করতে পারেন যা দুটি ভিন্ন সংস্করণের উপর নির্ভর করার চেষ্টা করে। আপনি যদি একটি guava লাইব্রেরিতে উভয় লক্ষ্যকে নির্দেশ করার জন্য একটি বিভ্রান্তিকর উপনাম তৈরি করেন, তাহলে BUILD ফাইলগুলি বিভ্রান্তিকর।
.bazelrc ফাইল ব্যবহার করে
প্রকল্প-নির্দিষ্ট বিকল্পগুলির জন্য, আপনার workspace /.bazelrc ( bazelrc বিন্যাস দেখুন) কনফিগারেশন ফাইলটি ব্যবহার করুন।
আপনি যদি আপনার প্রকল্পের জন্য প্রতি-ব্যবহারকারী বিকল্পগুলিকে সমর্থন করতে চান যা আপনি উত্স নিয়ন্ত্রণে পরীক্ষা করতে চান না , লাইনটি অন্তর্ভুক্ত করুন:
try-import %workspace%/user.bazelrc
(বা অন্য কোন ফাইলের নাম) আপনার workspace /.bazelrc এবং user.bazelrc আপনার .gitignore এ যোগ করুন।
প্যাকেজ
নির্মাণযোগ্য ফাইল ধারণকারী প্রতিটি ডিরেক্টরি একটি প্যাকেজ হওয়া উচিত। যদি একটি BUILD ফাইল সাবডিরেক্টরিতে ফাইলগুলিকে বোঝায় (যেমন, srcs = ["a/b/C.java"] ) তবে এটি একটি চিহ্ন যে একটি BUILD ফাইল সেই সাবডিরেক্টরিতে যোগ করা উচিত। এই কাঠামোটি যত দীর্ঘ থাকবে, তত বেশি বৃত্তাকার নির্ভরতা অসাবধানতাবশত তৈরি হবে, একটি লক্ষ্যের সুযোগ ক্রমাগত হবে এবং বিপরীত নির্ভরতার একটি ক্রমবর্ধমান সংখ্যা আপডেট করতে হবে।