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

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

প্ল্যাটফর্ম সহ বিল্ডিং

মডেলিং প্ল্যাটফর্ম এবং টুলচেইনের জন্য Bazel এর অত্যাধুনিক সমর্থন রয়েছে। বাস্তব প্রকল্পের সাথে এটিকে একীভূত করার জন্য কোড মালিক, নিয়ম রক্ষণাবেক্ষণকারী এবং মূল Bazel devs-এর মধ্যে সতর্ক সহযোগিতা প্রয়োজন।

এই পৃষ্ঠাটি প্ল্যাটফর্মের উদ্দেশ্য সংক্ষিপ্ত করে এবং তাদের সাথে কীভাবে তৈরি করা যায় তা দেখায়।

tl;dr: Bazel-এর প্ল্যাটফর্ম এবং টুলচেন APIগুলি উপলব্ধ কিন্তু সমস্ত ভাষার নিয়ম, select() s এবং অন্যান্য লিগ্যাসি রেফারেন্স আপডেট না হওয়া পর্যন্ত সর্বত্র কাজ করবে না। এ কাজ চলমান রয়েছে। অবশেষে সমস্ত বিল্ড প্ল্যাটফর্ম-ভিত্তিক হবে। আপনার বিল্ডগুলি কোথায় উপযুক্ত তা দেখতে নীচে পড়ুন।

আরো আনুষ্ঠানিক ডকুমেন্টেশনের জন্য, দেখুন:

পটভূমি

সফ্টওয়্যার প্রকল্পগুলি কীভাবে বিভিন্ন মেশিনকে টার্গেট করে এবং সঠিক ভাষার সরঞ্জামগুলির সাথে তৈরি করে তা প্রমিত করার জন্য প্ল্যাটফর্ম এবং টুলচেইনগুলি চালু করা হয়েছিল।

এটি Bazel একটি তুলনামূলকভাবে সাম্প্রতিক সংযোজন. এটি পর্যবেক্ষণ দ্বারা অনুপ্রাণিত হয়েছিল যে ভাষা রক্ষণাবেক্ষণকারীরা ইতিমধ্যেই অ্যাডহক, বেমানান উপায়ে এটি করছেন। উদাহরণস্বরূপ, C++ নিয়মগুলি একটি বিল্ডের লক্ষ্য CPU এবং C++ টুলচেইন সেট করতে --cpu এবং --crosstool_top ব্যবহার করে। এগুলোর কোনটিই সঠিকভাবে "প্ল্যাটফর্ম" মডেল করে না। এটি করার ঐতিহাসিক প্রচেষ্টা বিশ্রী এবং ভুল নির্মাণের কারণ। এই পতাকাগুলি জাভা সংকলনকেও নিয়ন্ত্রণ করে না, যা --java_toolchain এর সাথে নিজস্ব স্বাধীন ইন্টারফেস তৈরি করেছে।

Bazel বৃহৎ, বহু-ভাষা, বহু-প্ল্যাটফর্ম প্রকল্পের জন্য উদ্দিষ্ট। এটি এই ধারণাগুলির জন্য আরও নীতিগত সমর্থন দাবি করে, স্পষ্ট API সহ যা ভাষা এবং প্রকল্পের আন্তঃক্রিয়াশীলতাকে উত্সাহিত করে। এই নতুন API এর জন্য কি.

মাইগ্রেশন

প্ল্যাটফর্ম এবং টুলচেন APIগুলি শুধুমাত্র তখনই কাজ করে যখন প্রকল্পগুলি আসলে সেগুলি ব্যবহার করে। এটি তুচ্ছ নয় কারণ একটি প্রকল্পের নিয়ম যুক্তি, টুলচেইন, নির্ভরতা এবং select() গুলিকে তাদের সমর্থন করতে হবে। সমস্ত প্রকল্প এবং তাদের নির্ভরতা সঠিকভাবে কাজ করার জন্য এটি একটি সতর্ক স্থানান্তর ক্রম প্রয়োজন।

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

এই পৃষ্ঠার অবশিষ্ট অংশে এই স্থানান্তর ক্রম এবং কীভাবে এবং কখন আপনার প্রকল্পগুলি ফিট হতে পারে তা বর্ণনা করে৷

গোল

Bazel এর প্ল্যাটফর্ম স্থানান্তর সম্পূর্ণ হয় যখন সমস্ত প্রকল্প ফর্মের সাথে তৈরি হয়:

bazel build //:myproject --platforms=//:myplatform

এই থেকেই বোঝা:

আপনার প্রজেক্ট যে নিয়মগুলি ব্যবহার করে তা //:myplatform থেকে সঠিক টুলচেইন অনুমান করতে পারে।
আপনার প্রকল্পের নির্ভরতা যে নিয়মগুলি ব্যবহার করে তা //:myplatform থেকে সঠিক টুলচেইন অনুমান করতে পারে।
হয় আপনার সমর্থনের উপর নির্ভর করে প্রকল্পগুলি //:myplatform বা আপনার প্রকল্পগুলি লিগ্যাসি API সমর্থন করে (যেমন --crosstool_top )।
//:myplatform রেফারেন্স [সাধারণ ঘোষণা [সাধারণ প্ল্যাটফর্ম ঘোষণা]{: .external} এর CPU , OS , এবং অন্যান্য জেনেরিক ধারণা যা স্বয়ংক্রিয় ক্রস-প্রকল্প সামঞ্জস্যকে সমর্থন করে।
সমস্ত প্রাসঙ্গিক প্রকল্পের select() গুলি //:myplatform দ্বারা উহ্য মেশিনের বৈশিষ্ট্যগুলি বোঝে।
//:myplatform একটি পরিষ্কার, পুনঃব্যবহারযোগ্য জায়গায় সংজ্ঞায়িত করা হয়েছে: আপনার প্রকল্পের রেপোতে যদি প্ল্যাটফর্মটি আপনার প্রকল্পের জন্য অনন্য হয়, অন্যথায় এই প্ল্যাটফর্মটি ব্যবহার করতে পারে এমন সমস্ত প্রকল্প খুঁজে পেতে পারে।

এই লক্ষ্য অর্জনের সাথে সাথে পুরানো API গুলি সরানো হবে৷ তারপর এটি হবে প্রমিত উপায় প্রকল্পগুলি প্ল্যাটফর্ম এবং টুলচেইন নির্বাচন করে।

আমার কি প্ল্যাটফর্ম ব্যবহার করা উচিত?

আপনি যদি কেবল একটি প্রকল্প তৈরি করতে বা ক্রস-কম্পাইল করতে চান তবে আপনাকে প্রকল্পের অফিসিয়াল ডকুমেন্টেশন অনুসরণ করতে হবে।

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

মান

--cpu এর মতো হার্ড-কোডেড পতাকাগুলির পরিবর্তে আপনি select() করতে বা টুলচেইন বেছে নিতে পারেন। উদাহরণস্বরূপ, একাধিক CPU একই নির্দেশনা সেট সমর্থন করতে পারে।
আরো সঠিক বিল্ড. উপরের উদাহরণে আপনি যদি --cpu এর সাথে select() করেন, তাহলে একটি নতুন CPU যোগ করুন যা একই নির্দেশনা সেট সমর্থন করে, select() নতুন CPU চিনতে ব্যর্থ হয়। কিন্তু প্ল্যাটফর্মে একটি select() সঠিক থাকে।
সহজ ব্যবহারকারীর অভিজ্ঞতা। সমস্ত প্রকল্প বুঝতে পারে: --platforms=//:myplatform । কমান্ড লাইনে একাধিক ভাষা-নির্দিষ্ট পতাকার প্রয়োজন নেই।
সহজ ভাষা নকশা. সমস্ত ভাষা টুলচেন সংজ্ঞায়িত করার জন্য, টুলচেন ব্যবহার করে এবং একটি প্ল্যাটফর্মের জন্য সঠিক টুলচেন নির্বাচন করার জন্য একটি সাধারণ API ভাগ করে।
লক্ষ্য প্ল্যাটফর্মের সাথে বেমানান হলে বিল্ড এবং টেস্ট পর্বে লক্ষ্যগুলি এড়িয়ে যেতে পারে।

খরচ

নির্ভরশীল প্রকল্পগুলি যেগুলি এখনও প্ল্যাটফর্ম সমর্থন করে না সেগুলি স্বয়ংক্রিয়ভাবে আপনার সাথে কাজ নাও করতে পারে৷
তাদের কাজ করার জন্য অতিরিক্ত অস্থায়ী রক্ষণাবেক্ষণের প্রয়োজন হতে পারে।
নতুন এবং লিগ্যাসি API-এর সহ-অস্তিত্বের জন্য বিভ্রান্তি এড়াতে আরও সতর্ক ব্যবহারকারীর নির্দেশিকা প্রয়োজন।
OS এবং CPU এর মতো সাধারণ বৈশিষ্ট্যগুলির জন্য ক্যানোনিকাল সংজ্ঞা এখনও বিকশিত হচ্ছে এবং অতিরিক্ত প্রাথমিক অবদানের প্রয়োজন হতে পারে।
ভাষা-নির্দিষ্ট টুলচেইনের ক্যানোনিকাল সংজ্ঞা এখনও বিকশিত হচ্ছে এবং অতিরিক্ত প্রাথমিক অবদানের প্রয়োজন হতে পারে।

API পর্যালোচনা

একটি platform হল constraint_value লক্ষ্যগুলির একটি সংগ্রহ:

platform(
    name = "myplatform",
    constraint_values = [
        "@platforms//os:linux",
        "@platforms//cpu:arm",
    ],
)

একটি constraint_value একটি মেশিনের সম্পত্তি। একই "ধরনের" মানগুলি একটি সাধারণ constraint_setting অধীনে গোষ্ঠীবদ্ধ করা হয়েছে_সেটিং:

constraint_setting(name = "os")
constraint_value(
    name = "linux",
    constraint_setting = ":os",
)
constraint_value(
    name = "mac",
    constraint_setting = ":os",
)

একটি toolchain একটি স্টারলার্ক নিয়ম । এর বৈশিষ্ট্যগুলি একটি ভাষার সরঞ্জাম ঘোষণা করে (যেমন compiler = "//mytoolchain:custom_gcc" )। এর প্রদানকারীরা এই তথ্যগুলিকে সেই নিয়মগুলিতে প্রেরণ করে যা এই সরঞ্জামগুলির সাথে তৈরি করতে হবে৷

টুলচেইনগুলি তারা লক্ষ্য করতে পারে এমন মেশিনগুলির constraint_value মান ঘোষণা করে ( target_compatible_with = ["@platforms//os:linux"] ) এবং যে মেশিনগুলিতে তাদের সরঞ্জামগুলি চলতে পারে ( exec_compatible_with = ["@platforms//os:mac"] )।

$ bazel build //:myproject --platforms=//:myplatform , Bazel স্বয়ংক্রিয়ভাবে একটি টুলচেইন নির্বাচন করে যা বিল্ড মেশিনে চলতে পারে এবং //:myplatform এর জন্য বাইনারি তৈরি করতে পারে। এটি টুলচেইন রেজোলিউশন হিসাবে পরিচিত।

উপলভ্য টুলচেনগুলির সেটটি WORKSPACE এ register_toolchains বা --extra_toolchains এর সাথে কমান্ড লাইনে নিবন্ধিত হতে পারে।

একটি গভীর ডুব জন্য এখানে দেখুন.

স্ট্যাটাস

বর্তমান প্ল্যাটফর্ম সমর্থন ভাষার মধ্যে পরিবর্তিত হয়। Bazel এর সমস্ত প্রধান নিয়ম প্ল্যাটফর্মে চলে যাচ্ছে। তবে এই প্রক্রিয়ায় সময় লাগবে। এটি তিনটি প্রধান কারণের জন্য:

নতুন টুলচেন এপিআই ( ctx.toolchains ) থেকে টুলের তথ্য পেতে এবং --cpu এবং --crosstool_top এর মতো লিগ্যাসি সেটিংস পড়া বন্ধ করতে নিয়ম লজিক আপডেট করতে হবে। এটি তুলনামূলকভাবে সহজবোধ্য।
টুলচেন রক্ষণাবেক্ষণকারীদের অবশ্যই টুলচেন সংজ্ঞায়িত করতে হবে এবং ব্যবহারকারীদের কাছে অ্যাক্সেসযোগ্য করে তুলতে হবে (GitHub সংগ্রহস্থল এবং WORKSPACE এন্ট্রিতে)। এটি প্রযুক্তিগতভাবে সহজবোধ্য কিন্তু একটি সহজ ব্যবহারকারীর অভিজ্ঞতা বজায় রাখার জন্য বুদ্ধিমত্তার সাথে সংগঠিত হতে হবে।
প্ল্যাটফর্মের সংজ্ঞাগুলিও প্রয়োজনীয় (যদি না আপনি একই মেশিনের জন্য তৈরি করেন ব্যাজেল চলে)। সাধারণত, প্রকল্পগুলির নিজস্ব প্ল্যাটফর্ম সংজ্ঞায়িত করা উচিত।
বিদ্যমান প্রকল্প স্থানান্তর করা আবশ্যক. select() s এবং ট্রানজিশনগুলিকেও স্থানান্তরিত করতে হবে। এটাই সবচেয়ে বড় চ্যালেঞ্জ। এটি বহু-ভাষা প্রকল্পের জন্য বিশেষভাবে চ্যালেঞ্জিং (যা ব্যর্থ হতে পারে যদি সব ভাষা পড়তে না পারে --platforms )।

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

সাধারণ প্ল্যাটফর্ম বৈশিষ্ট্য

OS এবং CPU এর মতো প্ল্যাটফর্ম বৈশিষ্ট্যগুলি যেগুলি সমস্ত প্রকল্প জুড়ে সাধারণ, একটি আদর্শ, কেন্দ্রীভূত জায়গায় ঘোষণা করা উচিত। এটি ক্রস-প্রকল্প এবং ক্রস-ভাষা সামঞ্জস্যকে উৎসাহিত করে।

উদাহরণস্বরূপ, যদি MyApp- এর constraint_value @myapp//cpus:arm arm- এ একটি Select select() select() এবং SomeCommonLib-এর @commonlib//constraints:arm এ একটি Select() থাকে, তাহলে এইগুলি বেমানান মানদণ্ডের সাথে তাদের "বাহু" মোড ট্রিগার করে।

বিশ্বব্যাপী সাধারণ বৈশিষ্ট্যগুলি @platforms ঘোষণা করা হয় (তাই উপরের উদাহরণের জন্য ক্যানোনিকাল লেবেল হল @platforms//cpu:arm )। ভাষা-সাধারণ বৈশিষ্ট্য তাদের নিজ নিজ ভাষার রিপোজে ঘোষণা করা উচিত।

ডিফল্ট প্ল্যাটফর্ম

সাধারণত, প্রকল্পের মালিকদের তারা যে ধরনের মেশিন তৈরি করতে চান তা বর্ণনা করার জন্য স্পষ্ট প্ল্যাটফর্মগুলিকে সংজ্ঞায়িত করা উচিত। এইগুলি তারপর --platforms দিয়ে ট্রিগার করা হয়।

যখন --platforms সেট করা হয় না, তখন স্থানীয় বিল্ড মেশিনের প্রতিনিধিত্বকারী একটি platform Bazel ডিফল্ট হয়। এটি @local_config_platform//:host এ স্বয়ংক্রিয়ভাবে তৈরি হয় তাই এটিকে স্পষ্টভাবে সংজ্ঞায়িত করার প্রয়োজন নেই। এটি @platforms এ ঘোষিত constraint_value সহ স্থানীয় মেশিনের OS এবং CPU কে ম্যাপ করে।

সি++

Bazel-এর C++ নিয়মগুলি টুলচেইন নির্বাচন করতে প্ল্যাটফর্ম ব্যবহার করে যখন আপনি --incompatible_enable_cc_toolchain_resolution ( #7260 ) সেট করেন।

এর মানে হল আপনি একটি C++ প্রকল্প কনফিগার করতে পারেন:

bazel build //:my_cpp_project --platforms=//:myplatform

উত্তরাধিকারের পরিবর্তে:

bazel build //:my_cpp_project` --cpu=... --crosstool_top=...  --compiler=...

যদি আপনার প্রজেক্ট খাঁটি C++ হয় এবং নন-C++ প্রোজেক্টের উপর নির্ভরশীল না হয়, তাহলে আপনি নিরাপদে প্ল্যাটফর্ম ব্যবহার করতে পারবেন যতক্ষণ না আপনার select s এবং ট্রানজিশন সামঞ্জস্যপূর্ণ হয়। আরও নির্দেশনার জন্য দেখুন #7260 এবং C++ টুলচেইন কনফিগার করা।

এই মোড ডিফল্টরূপে সক্রিয় করা হয় না. এর কারণ হল অ্যাপল প্রকল্পগুলি এখনও --cpu এবং --crosstool_top ( উদাহরণ ) এর সাথে C++ নির্ভরতা কনফিগার করে। সুতরাং এটি প্ল্যাটফর্মে স্থানান্তরিত অ্যাপলের নিয়মগুলির উপর নির্ভর করে।

জাভা

Bazel এর জাভা নিয়ম প্ল্যাটফর্ম ব্যবহার করে।

এটি উত্তরাধিকার পতাকা --java_toolchain , --host_java_toolchain , --javabase , এবং --host_javabase ।

কনফিগারেশন ফ্ল্যাগগুলি কীভাবে ব্যবহার করবেন তা শিখতে, বেজেল এবং জাভা ম্যানুয়ালটি দেখুন। অতিরিক্ত তথ্যের জন্য, ডিজাইন নথি দেখুন।

আপনি যদি এখনও লিগ্যাসি ফ্ল্যাগ ব্যবহার করে থাকেন, তাহলে ইস্যু #7849 -এ মাইগ্রেশন প্রক্রিয়া অনুসরণ করুন।

অ্যান্ড্রয়েড

যখন আপনি --incompatible_enable_android_toolchain_resolution সেট করেন তখন --incompatible_enable_android_toolchain_resolution এর Android নিয়ম টুলচেইন নির্বাচন করতে প্ল্যাটফর্ম ব্যবহার করে।

এটি ডিফল্টরূপে সক্ষম নয়৷ কিন্তু মাইগ্রেশন তার পথে ভাল।

আপেল

Bazel এর Apple নিয়ম এখনও Apple toolchains নির্বাচন করার জন্য প্ল্যাটফর্ম সমর্থন করে না।

তারা প্ল্যাটফর্ম-সক্ষম C++ নির্ভরতাগুলিকেও সমর্থন করে না কারণ তারা C++ টুলচেইন সেট করতে উত্তরাধিকার --crosstool_top ব্যবহার করে। এটি স্থানান্তরিত না হওয়া পর্যন্ত, আপনি প্ল্যাটর্ম-সক্ষম C++ এর সাথে প্ল্যাটফর্ম ম্যাপিংয়ের সাথে অ্যাপল প্রকল্পগুলি মিশ্রিত করতে পারেন ( উদাহরণ )।

অন্যান্য ভাষাসমূহ

Bazel এর মরিচা নিয়ম সম্পূর্ণরূপে প্ল্যাটফর্ম সমর্থন করে.
Bazel's Go নিয়মগুলি সম্পূর্ণরূপে প্ল্যাটফর্ম সমর্থন করে ( বিস্তারিত )।

আপনি যদি একটি নতুন ভাষার জন্য নিয়ম ডিজাইন করছেন, আপনার ভাষার টুলচেন নির্বাচন করতে প্ল্যাটফর্ম ব্যবহার করুন। একটি ভাল ওয়াকথ্রু জন্য টুলচেন ডকুমেন্টেশন দেখুন.

`select()`

প্রজেক্টগুলি constraint_value লক্ষ্যে select() করতে পারে কিন্তু সম্পূর্ণ প্ল্যাটফর্ম নয়। এটি ইচ্ছাকৃত যাতে select() s যতটা সম্ভব বিভিন্ন ধরনের মেশিনকে সমর্থন করে। ARM নির্দিষ্ট উত্স সহ একটি লাইব্রেরি সমস্ত ARM চালিত মেশিন সমর্থন করবে যদি না আরও নির্দিষ্ট হওয়ার কারণ থাকে।

এক বা একাধিক constraint_value s নির্বাচন করতে, ব্যবহার করুন:

config_setting(
    name = "is_arm",
    constraint_values = [
        "@platforms//cpu:arm",
    ],
)

এটি ঐতিহ্যগতভাবে --cpu তে নির্বাচন করার সমতুল্য:

config_setting(
    name = "is_arm",
    values = {
        "cpu": "arm",
    },
)

এখানে আরো বিস্তারিত.

--cpu , --crosstool_top ইত্যাদিতে s select করুন। --platforms বুঝতে পারছেন না। আপনার প্রকল্পকে প্ল্যাটফর্মে স্থানান্তর করার সময়, আপনাকে অবশ্যই সেগুলিকে constraint_values এ রূপান্তর করতে হবে অথবা মাইগ্রেশন উইন্ডোর মাধ্যমে উভয় শৈলীকে সমর্থন করার জন্য প্ল্যাটফর্ম ম্যাপিং ব্যবহার করতে হবে।

রূপান্তর

স্টারলার্ক ট্রানজিশনগুলি আপনার বিল্ড গ্রাফের কিছু অংশে পতাকা পরিবর্তন করে। যদি আপনার প্রোজেক্ট একটি পরিবর্তন ব্যবহার করে যা --cpu , --crossstool_top , বা অন্যান্য লিগ্যাসি ফ্ল্যাগ সেট করে, তাহলে --platforms পড়া নিয়মগুলি এই পরিবর্তনগুলি দেখতে পাবে না৷

প্ল্যাটফর্মে আপনার প্রোজেক্ট স্থানান্তর করার সময়, আপনাকে অবশ্যই return { "//command_line_option:platforms": "//:my_arm_platform" } return { "//command_line_option:cpu": "arm" } মত পরিবর্তনগুলিকে রূপান্তর করতে হবে অথবা প্ল্যাটফর্ম ম্যাপিংগুলি ব্যবহার করতে হবে মাইগ্রেশন উইন্ডোর মাধ্যমে উভয় শৈলী সমর্থন করে।

আজ কিভাবে প্ল্যাটফর্ম ব্যবহার করবেন

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

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

আপনার প্রকল্পের ভাষাগুলির জন্য "প্ল্যাটফর্মগুলি ব্যবহার করুন" পতাকায় ফ্লিপ করুন ( যদি তাদের একটি থাকে ) এবং আপনি যে প্রকল্পগুলি কাজ করছেন তা দেখার জন্য আপনার যা কিছু পরীক্ষা করা দরকার তা করুন৷
আপনি যে প্রকল্পগুলির বিষয়ে যত্নশীল তা যদি এখনও --cpu এবং --crosstool_top এর মতো লিগ্যাসি ফ্ল্যাগগুলির উপর নির্ভর করে তবে --platforms সাথে এইগুলি একসাথে ব্যবহার করুন:
```
bazel build //:my_mixed_project --platforms==//:myplatform --cpu=... --crosstool_top=...
```
এটির কিছু রক্ষণাবেক্ষণ খরচ রয়েছে (আপনাকে ম্যানুয়ালি নিশ্চিত করতে হবে সেটিংস মেলে)। কিন্তু এই বিদ্রোহী পরিবর্তনের অনুপস্থিতিতে কাজ করা উচিত।
সংশ্লিষ্ট প্ল্যাটফর্মে --cpu সেটিংস ম্যাপিং করে উভয় শৈলী সমর্থন করার জন্য প্ল্যাটফর্ম ম্যাপিং লিখুন এবং এর বিপরীতে।

প্ল্যাটফর্ম ম্যাপিং

প্ল্যাটফর্ম ম্যাপিং হল একটি অস্থায়ী API যা প্ল্যাটফর্ম-চালিত এবং লিগ্যাসি-চালিত লজিককে পরবর্তীটির অবচয় উইন্ডোর মাধ্যমে একই বিল্ডে সহ-অস্তিত্ব করতে দেয়।

একটি প্ল্যাটফর্ম ম্যাপিং হল একটি platform() এর একটি লিগ্যাসি ফ্ল্যাগ বা বিপরীত সেটের একটি মানচিত্র। উদাহরণ স্বরূপ:

platforms:
  # Maps "--platforms=//platforms:ios" to "--cpu=ios_x86_64 --apple_platform_type=ios".
  //platforms:ios
    --cpu=ios_x86_64
    --apple_platform_type=ios

flags:
  # Maps "--cpu=ios_x86_64 --apple_platform_type=ios" to "--platforms=//platforms:ios".
  --cpu=ios_x86_64
  --apple_platform_type=ios
    //platforms:ios

  # Maps "--cpu=darwin --apple_platform_type=macos" to "//platform:macos".
  --cpu=darwin
  --apple_platform_type=macos
    //platforms:macos

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

ডিফল্টরূপে Bazel আপনার ওয়ার্কস্পেস রুটে platform_mappings ফাইল থেকে ম্যাপিং পড়ে। এছাড়াও আপনি --platform_mappings=//:my_custom_mapping সেট করতে পারেন।

সম্পূর্ণ বিবরণের জন্য এখানে দেখুন.

প্রশ্ন

মাইগ্রেশন টাইমলাইন সম্পর্কে সাধারণ সহায়তা এবং প্রশ্নের জন্য, bazel-discuss@googlegroups.com বা উপযুক্ত নিয়মের মালিকদের সাথে যোগাযোগ করুন।

প্ল্যাটফর্ম/টুলচেন API-এর ডিজাইন এবং বিবর্তন নিয়ে আলোচনার জন্য, bazel-dev@googlegroups.com-এ যোগাযোগ করুন।