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

ভেরিয়েবল "বানান"

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

"মেক" ভেরিয়েবল হল প্রসারণযোগ্য স্ট্রিং ভেরিয়েবলের একটি বিশেষ শ্রেণি যা "'মেক ভেরিয়েবল' প্রতিস্থাপনের বিষয়" হিসাবে চিহ্নিত বৈশিষ্ট্যগুলির জন্য উপলব্ধ।

এগুলি ব্যবহার করা যেতে পারে, উদাহরণস্বরূপ, ব্যবহারকারী-নির্মিত বিল্ড অ্যাকশনগুলিতে নির্দিষ্ট টুলচেন পাথগুলি ইনজেকশন করতে।

Bazel উভয় পূর্বনির্ধারিত ভেরিয়েবল প্রদান করে, যা সমস্ত লক্ষ্যের জন্য উপলব্ধ, এবং কাস্টম ভেরিয়েবল, যা নির্ভরতা লক্ষ্যে সংজ্ঞায়িত করা হয় এবং শুধুমাত্র তাদের উপর নির্ভরশীল লক্ষ্যগুলির জন্য উপলব্ধ।

"মেক" শব্দটির কারণ ঐতিহাসিক: এই ভেরিয়েবলের সিনট্যাক্স এবং শব্দার্থবিদ্যা মূলত GNU Make- এর সাথে মেলে।

ব্যবহার করুন

"'মেক ভেরিয়েবল' প্রতিস্থাপনের বিষয়" হিসাবে চিহ্নিত বৈশিষ্ট্যগুলি "মেক" ভেরিয়েবল FOO কে নিম্নরূপ উল্লেখ করতে পারে:

my_attr = "prefix $(FOO) suffix"

অন্য কথায়, $(FOO) এর সাথে মিলে যাওয়া যেকোনো সাবস্ট্রিং FOO এর মান পর্যন্ত প্রসারিত হয়। যদি সেই মানটি "bar" হয়, তাহলে চূড়ান্ত স্ট্রিংটি হয়ে যায়:

my_attr = "prefix bar suffix"

যদি FOO টার্গেটের সাথে পরিচিত একটি ভেরিয়েবলের সাথে সঙ্গতি না করে, তবে Bazel একটি ত্রুটির সাথে ব্যর্থ হয়।

"মেক" ভেরিয়েবল যাদের নাম অ-অক্ষর চিহ্ন, যেমন @ , বন্ধনী ছাড়া শুধুমাত্র ডলার চিহ্ন ব্যবহার করে উল্লেখ করা যেতে পারে। উদাহরণ স্বরূপ:

my_attr = "prefix $@ suffix"

$ একটি স্ট্রিং আক্ষরিক হিসাবে লিখতে (অর্থাৎ পরিবর্তনশীল সম্প্রসারণ রোধ করতে), $$ লিখুন।

পূর্বনির্ধারিত ভেরিয়েবল

পূর্বনির্ধারিত "মেক" ভেরিয়েবল যেকোন টার্গেটে "মেক ভেরিয়েবল' প্রতিস্থাপনের বিষয়" হিসাবে চিহ্নিত যেকোন বৈশিষ্ট্য দ্বারা উল্লেখ করা যেতে পারে।

এই ভেরিয়েবলের তালিকা এবং বিল্ড বিকল্পগুলির একটি নির্দিষ্ট সেটের জন্য তাদের মান দেখতে, চালান

bazel info --show_make_env [build options]

এবং বড় অক্ষর সহ উপরের আউটপুট লাইনগুলি দেখুন।

পূর্বনির্ধারিত ভেরিয়েবলের একটি উদাহরণ দেখুন

টুলচেইন বিকল্প ভেরিয়েবল

পাথ ভেরিয়েবল

  • BINDIR : লক্ষ্য আর্কিটেকচারের জন্য তৈরি করা বাইনারি গাছের ভিত্তি।

    মনে রাখবেন যে ক্রস-কম্পাইলিং সমর্থন করার জন্য হোস্ট আর্কিটেকচারে বিল্ড চলাকালীন প্রোগ্রামগুলির জন্য একটি ভিন্ন ট্রি ব্যবহার করা যেতে পারে।

    আপনি যদি একটি genrule এর মধ্যে থেকে একটি টুল চালাতে চান, তার পাথ পাওয়ার জন্য প্রস্তাবিত উপায় হল $( execpath toolname) genrule টুলস tools তালিকাভুক্ত করা উচিত।

  • GENDIR : টার্গেট আর্কিটেকচারের জন্য জেনারেট করা কোড ট্রির ভিত্তি।

মেশিন আর্কিটেকচার ভেরিয়েবল

  • TARGET_CPU : লক্ষ্য আর্কিটেকচারের CPU, যেমন k8

পূর্বনির্ধারিত জেনরুল ভেরিয়েবল

নিম্নলিখিতগুলি বিশেষভাবে genrule cmd অ্যাট্রিবিউটের জন্য উপলব্ধ এবং সাধারণত সেই অ্যাট্রিবিউটটিকে কাজ করার জন্য গুরুত্বপূর্ণ৷

পূর্বনির্ধারিত জেনরুল ভেরিয়েবলের একটি উদাহরণ দেখুন

  • genrule OUTS outs । আপনার যদি শুধুমাত্র একটি আউটপুট ফাইল থাকে তবে আপনি $@ ব্যবহার করতে পারেন।
  • SRCS : genrule এর srcs তালিকা (বা আরও স্পষ্টভাবে: srcs তালিকার লেবেলের সাথে সম্পর্কিত ফাইলগুলির পাথের নাম)। আপনার যদি শুধুমাত্র একটি উৎস ফাইল থাকে তবে আপনি $< ব্যবহার করতে পারেন।
  • < : SRCS , যদি এটি একটি একক ফাইল হয়। অন্যথা একটি বিল্ড ত্রুটি ট্রিগার.
  • @ : OUTS , যদি এটি একটি একক ফাইল হয়। অন্যথা একটি বিল্ড ত্রুটি ট্রিগার.
  • RULEDIR : টার্গেটের আউটপুট ডিরেক্টরি, অর্থাৎ, genfiles বা bin ট্রির নিচে টার্গেট ধারণকারী প্যাকেজের নামের সাথে সংশ্লিষ্ট ডিরেক্টরি। //my/pkg:my_genrule এর জন্য এটি সর্বদা my/pkg /pkg-এ শেষ হয়, এমনকি যদি //my/pkg:my_genrule এর আউটপুটগুলি সাবডিরেক্টরিতে থাকে।

  • @D : আউটপুট ডিরেক্টরি। আউটস -এর একটি এন্ট্রি থাকলে, এটি সেই ফাইল ধারণকারী ডিরেক্টরিতে প্রসারিত হয়। যদি এটিতে একাধিক এন্ট্রি থাকে, তাহলে এটি genfiles ট্রিতে প্যাকেজের রুট ডিরেক্টরিতে প্রসারিত হয়, এমনকি যদি সমস্ত আউটপুট ফাইল একই সাবডিরেক্টরিতে থাকে !

    দ্রষ্টব্য: @D এর উপরে RULEDIR ব্যবহার করুন কারণ RULEDIR এর সহজ শব্দার্থবিদ্যা রয়েছে এবং আউটপুট ফাইলের সংখ্যা নির্বিশেষে একইভাবে আচরণ করে।

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

    বিশেষ করে ইনপুট ধারণকারী ডিরেক্টরিতে লেখা এড়িয়ে চলুন। তারা শুধুমাত্র পঠনযোগ্য ফাইল সিস্টেমে থাকতে পারে। তা না করলেও উৎস গাছটি ট্র্যাশ করবে।

পূর্বনির্ধারিত উৎস/আউটপুট পাথ ভেরিয়েবল

পূর্বনির্ধারিত ভেরিয়েবল execpath , execpaths , rootpath , rootpaths , location এবং locations লেবেল প্যারামিটার (যেমন $(execpath //foo:bar) ) নেয় এবং সেই লেবেল দ্বারা চিহ্নিত ফাইল পাথগুলিকে প্রতিস্থাপন করে।

সোর্স ফাইলগুলির জন্য, এটি আপনার ওয়ার্কস্পেস রুটের সাথে সম্পর্কিত পথ। নিয়মের আউটপুট ফাইলগুলির জন্য, এটি ফাইলের আউটপুট পথ (নীচের আউটপুট ফাইলগুলির ব্যাখ্যা দেখুন)।

পূর্বনির্ধারিত পাথ ভেরিয়েবলের একটি উদাহরণ দেখুন

  • execpath : execroot- এর নিচের পথ নির্দেশ করে যেখানে Bazel বিল্ড অ্যাকশন চালায়।

    উপরের উদাহরণে, Bazel আপনার ওয়ার্কস্পেস রুটে bazel-myproject দ্বারা লিঙ্ক করা ডিরেক্টরিতে সমস্ত বিল্ড অ্যাকশন চালায়। উৎস ফাইল empty.source পাথ bazel-myproject/testapp/empty.source এ লিঙ্ক করা হয়েছে। তাই এর exec পাথ (যা রুটের নিচের সাবপাথ) testapp/empty.source । এই পাথ বিল্ড অ্যাকশন ফাইল খুঁজে পেতে ব্যবহার করতে পারেন.

    আউটপুট ফাইলগুলি একইভাবে স্টেজ করা হয়, তবে সাবপাথ bazel-out/cpu-compilation_mode/bin (বা নির্দিষ্ট আউটপুটগুলির জন্য: bazel-out/cpu-compilation_mode/genfiles , বা হোস্ট টুলগুলির আউটপুটগুলির জন্য: bazel-out/host/bin )। উপরের উদাহরণে, //testapp:app হল একটি হোস্ট টুল কারণ এটি show_app_output এর tools অ্যাট্রিবিউটে প্রদর্শিত হয়। তাই এর আউটপুট ফাইল app bazel-myproject/bazel-out/host/bin/testapp/app এ লেখা হয়েছে। exec পাথ এইভাবে bazel-out/host/bin/testapp/app । এই অতিরিক্ত উপসর্গটি একই বিল্ডে দুটি ভিন্ন CPU-এর জন্য একই টার্গেট তৈরি করা সম্ভব করে তোলে, ফলাফল একে অপরকে ক্লোবার না করে।

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

  • rootpath : রানফাইল পাথ নির্দেশ করে যা একটি নির্মিত বাইনারি রানটাইমে তার নির্ভরতা খুঁজে পেতে ব্যবহার করতে পারে।

    এটি execpath এর মতই কিন্তু উপরে বর্ণিত আউটপুট উপসর্গগুলি স্ট্রিপ করে। উপরের উদাহরণে এর অর্থ হল empty.source এবং app উভয়ই বিশুদ্ধ ওয়ার্কস্পেস-রিলেটিভ পাথ ব্যবহার করে: testapp/empty.source এবং testapp/app

    এটি execpath হিসাবে একই "একমাত্র আউটপুট" প্রয়োজনীয়তা রয়েছে।

  • location : execpath বা rootpath একটি প্রতিশব্দ, যে বৈশিষ্ট্যটি প্রসারিত হচ্ছে তার উপর নির্ভর করে। এটি একটি লিগ্যাসি প্রাক-স্টারলার্ক আচরণ এবং সুপারিশ করা হয় না যদি না আপনি সত্যিই জানেন যে এটি একটি নির্দিষ্ট নিয়মের জন্য কী করে। বিস্তারিত জানার জন্য #2475 দেখুন।

execpaths , rootpaths , এবং location হল যথাক্রমে execpath , rootpath , এবং locations এর বহুবচন। তারা একাধিক আউটপুট উত্পাদনকারী লেবেলগুলিকে সমর্থন করে, এই ক্ষেত্রে প্রতিটি আউটপুট একটি স্থান দ্বারা আলাদা করা তালিকাভুক্ত করা হয়। জিরো-আউটপুট নিয়ম এবং বিকৃত লেবেল বিল্ড ত্রুটি তৈরি করে।

সমস্ত রেফারেন্সকৃত লেবেল অবশ্যই কনজিউমিং টার্গেটের srcs , আউটপুট ফাইল বা deps এ উপস্থিত হতে হবে। অন্যথায় বিল্ড ব্যর্থ হয়। C++ লক্ষ্যগুলি data লেবেল উল্লেখ করতে পারে।

লেবেলগুলি ক্যানোনিকাল ফর্মে থাকতে হবে না: foo , :foo এবং //somepkg:foo সব ঠিক আছে।

কাস্টম ভেরিয়েবল

কাস্টম "মেক" ভেরিয়েবলগুলিকে "'মেক ভেরিয়েবল' প্রতিস্থাপনের সাপেক্ষে" হিসাবে চিহ্নিত যে কোনও বৈশিষ্ট্য দ্বারা উল্লেখ করা যেতে পারে, তবে কেবলমাত্র সেই লক্ষ্যগুলির উপর নির্ভর করে যা এই ভেরিয়েবলগুলিকে সংজ্ঞায়িত করে।

সর্বোত্তম অনুশীলন হিসাবে সমস্ত ভেরিয়েবলগুলি কাস্টম হওয়া উচিত যদি না সেগুলিকে মূল বেজেলে বেক করার কোনও ভাল কারণ না থাকে। এটি ব্যাজেলকে ভেরিয়েবল সরবরাহ করার জন্য সম্ভাব্য ব্যয়বহুল নির্ভরতাগুলি লোড করার থেকে বাঁচায় যা টেরেটগুলিকে পাত্তা দেয় না।

C++ টুলচেন ভেরিয়েবল

নিম্নলিখিতগুলি C++ টুলচেইনের নিয়মে সংজ্ঞায়িত করা হয়েছে এবং যে কোনও নিয়মে উপলভ্য যা toolchains = ["@bazel_tools//tools/cpp:current_cc_toolchain"] (বা হোস্ট ভ্যালেন্ট টুলচেনের জন্য "@bazel_tools//tools/cpp:current_cc_host_toolchain" )। কিছু নিয়ম, যেমন java_binary , তাদের নিয়মের সংজ্ঞাতে C++ টুলচেনকে অন্তর্নিহিতভাবে অন্তর্ভুক্ত করে। তারা স্বয়ংক্রিয়ভাবে এই ভেরিয়েবলের উত্তরাধিকারী হয়।

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

এই ভেরিয়েবলগুলি বিরল ক্ষেত্রে ভাষা বিশেষজ্ঞদের দ্বারা ব্যবহার করা একটি ফলব্যাক প্রক্রিয়া। আপনি যদি সেগুলি ব্যবহার করতে প্রলুব্ধ হন, অনুগ্রহ করে প্রথমে Bazel devs এর সাথে যোগাযোগ করুন

  • ABI : C++ ABI সংস্করণ।
  • AR : ক্রসটুল থেকে "ar" কমান্ড।
  • C_COMPILER : C/C++ কম্পাইলার শনাক্তকারী, যেমন llvm
  • CC : C এবং C++ কম্পাইলার কমান্ড।

    আমরা দৃঢ়ভাবে CC এর সাথে CC_FLAGS ব্যবহার করার পরামর্শ দিই। আপনার নিজের ঝুঁকিতে এটি করতে ব্যর্থ।

  • CC_FLAGS : C/C++ কম্পাইলারের জন্য ফ্ল্যাগের একটি ন্যূনতম সেট জেনরুল দ্বারা ব্যবহারযোগ্য। বিশেষ করে, CC একাধিক আর্কিটেকচার সমর্থন করলে সঠিক আর্কিটেকচার নির্বাচন করার জন্য এতে পতাকা রয়েছে।
  • NM : ক্রসটুল থেকে "এনএম" কমান্ড।
  • OBJCOPY : C/C++ কম্পাইলারের মতো একই স্যুট থেকে objcopy কমান্ড।
  • STRIP : C/C++ কম্পাইলারের মতো একই স্যুট থেকে স্ট্রিপ কমান্ড।

জাভা টুলচেইন ভেরিয়েবল

নিম্নলিখিতগুলি জাভা টুলচেইনের নিয়মগুলিতে সংজ্ঞায়িত করা হয়েছে এবং যে কোনও নিয়মের জন্য উপলব্ধ যা toolchains = ["@bazel_tools//tools/jdk:current_java_runtime"] (বা হোস্ট টুলচেনের সমতুল্যের জন্য "@bazel_tools//tools/jdk:current_host_java_runtime" )।

JDK-এর বেশিরভাগ টুল সরাসরি ব্যবহার করা উচিত নয়। অন্তর্নির্মিত জাভা নিয়মগুলি জাভা সংকলন এবং প্যাকেজিংয়ের জন্য অনেক বেশি পরিশীলিত পন্থা ব্যবহার করে যা আপস্ট্রিম সরঞ্জামগুলি প্রকাশ করতে পারে, যেমন ইন্টারফেস জার, হেডার ইন্টারফেস জার, এবং অত্যন্ত অপ্টিমাইজ করা জার প্যাকেজিং এবং মার্জিং বাস্তবায়ন।

এই ভেরিয়েবলগুলি বিরল ক্ষেত্রে ভাষা বিশেষজ্ঞদের দ্বারা ব্যবহার করা একটি ফলব্যাক প্রক্রিয়া। আপনি যদি সেগুলি ব্যবহার করতে প্রলুব্ধ হন, অনুগ্রহ করে প্রথমে Bazel devs এর সাথে যোগাযোগ করুন

  • JAVA : "java" কমান্ড (একটি জাভা ভার্চুয়াল মেশিন)। এটি এড়িয়ে চলুন, এবং যেখানে সম্ভব সেখানে একটি java_binary নিয়ম ব্যবহার করুন। আপেক্ষিক পথ হতে পারে। java চালু করার আগে আপনাকে যদি ডিরেক্টরি পরিবর্তন করতে হয়, তাহলে এটি পরিবর্তন করার আগে আপনাকে ওয়ার্কিং ডিরেক্টরি ক্যাপচার করতে হবে।
  • JAVABASE : জাভা ইউটিলিটি ধারণকারী বেস ডিরেক্টরি। আপেক্ষিক পথ হতে পারে। এটির একটি "বিন" সাবডিরেক্টরি থাকবে।

Starlark-সংজ্ঞায়িত ভেরিয়েবল

নিয়ম এবং টুলচেন লেখকরা একটি TemplateVariableInfo প্রদানকারীকে ফিরিয়ে দিয়ে সম্পূর্ণ কাস্টম ভেরিয়েবলকে সংজ্ঞায়িত করতে পারেন। toolchains অ্যাট্রিবিউটের মাধ্যমে এইগুলির উপর নির্ভর করে যে কোনও নিয়ম তারপর তাদের মানগুলি পড়তে পারে:

Starlark-সংজ্ঞায়িত ভেরিয়েবলের একটি উদাহরণ দেখুন