ওয়ার্কস্পেস নিয়মগুলি বাহ্যিক নির্ভরতাগুলিকে টানতে ব্যবহৃত হয়, সাধারণত মূল সংগ্রহস্থলের বাইরে অবস্থিত উত্স কোড।
দ্রষ্টব্য: নেটিভ ওয়ার্কস্পেস নিয়মের পাশাপাশি, Bazel বিভিন্ন Starlark ওয়ার্কস্পেস নিয়মগুলিও এম্বেড করে, বিশেষ করে যেগুলি ওয়েবে হোস্ট করা গিট রিপোজিটরি বা আর্কাইভগুলির সাথে মোকাবিলা করার জন্য।
নিয়ম
বাঁধাই করা
bind(name, actual, compatible_with, deprecation, distribs, features, licenses, restricted_to, tags, target_compatible_with, testonly, visibility)
সতর্কতা: bind()
ব্যবহার বাঞ্ছনীয় নয়। এর সমস্যা এবং বিকল্পগুলির একটি দীর্ঘ আলোচনার জন্য " বাঁধাই অপসারণ বিবেচনা করুন " দেখুন৷ বিশেষ করে, repo_mapping
সংগ্রহস্থল বৈশিষ্ট্যের ব্যবহার বিবেচনা করুন।
সতর্কতা: select()
bind()
এ ব্যবহার করা যাবে না। বিস্তারিত জানার জন্য কনফিগারযোগ্য বৈশিষ্ট্য FAQ দেখুন।
//external
প্যাকেজে একটি লক্ষ্যকে একটি উপনাম দেয়।
//external
প্যাকেজটি একটি "স্বাভাবিক" প্যাকেজ নয়: কোনও বহিরাগত/ ডিরেক্টরি নেই, তাই এটিকে একটি "ভার্চুয়াল প্যাকেজ" হিসাবে ভাবা যেতে পারে যাতে সমস্ত আবদ্ধ লক্ষ্য থাকে।
উদাহরণ
একটি লক্ষ্যকে একটি উপনাম দিতে, এটি ওয়ার্কস্পেস ফাইলে bind
করুন। উদাহরণস্বরূপ, ধরুন //third_party/javacc-v2
নামে একটি java_library
টার্গেট আছে। WORKSPACE ফাইলে নিম্নলিখিত যোগ করে এটি উপনাম করা যেতে পারে:
bind( name = "javacc-latest", actual = "//third_party/javacc-v2", )
এখন লক্ষ্যগুলি //third_party/javacc-v2
এর পরিবর্তে //external:javacc-latest
এর উপর নির্ভর করতে পারে। javacc-v3 প্রকাশ করা হলে, bind
নিয়ম আপডেট করা যেতে পারে এবং //external:javacc-latest
এর উপর নির্ভর করে সমস্ত BUILD ফাইল এখন সম্পাদনা করার প্রয়োজন ছাড়াই javacc-v3 এর উপর নির্ভর করবে।
আপনার কর্মক্ষেত্রে উপলব্ধ বহিরাগত সংগ্রহস্থলগুলিতে লক্ষ্যগুলি তৈরি করতে Bind ব্যবহার করা যেতে পারে। উদাহরণস্বরূপ, যদি ওয়ার্কস্পেস ফাইলে @my-ssl
নামে একটি রিমোট রিপোজিটরি আমদানি করা থাকে এবং এটিতে একটি cc_library টার্গেট //src:openssl-lib
থাকে, তাহলে আপনি bind
ব্যবহার করে এই লক্ষ্যের জন্য একটি উপনাম তৈরি করতে পারেন:
bind( name = "openssl", actual = "@my-ssl//src:openssl-lib", )
তারপর, আপনার কর্মক্ষেত্রে একটি বিল্ড ফাইলে, আবদ্ধ লক্ষ্যটি নিম্নরূপ ব্যবহার করা যেতে পারে:
cc_library( name = "sign-in", srcs = ["sign_in.cc"], hdrs = ["sign_in.h"], deps = ["//external:openssl"], )
sign_in.cc
এবং sign_in.h
এর মধ্যে, //external:openssl
দ্বারা উন্মুক্ত হেডার ফাইলগুলিকে তাদের সংগ্রহস্থল রুটের সাথে সম্পর্কিত তাদের পাথ ব্যবহার করার জন্য উল্লেখ করা যেতে পারে। উদাহরণস্বরূপ, যদি @my-ssl//src:openssl-lib
এর নিয়মের সংজ্ঞাটি এরকম দেখায়:
cc_library( name = "openssl-lib", srcs = ["openssl.cc"], hdrs = ["openssl.h"], )
তাহলে sign_in.cc
এর অন্তর্ভুক্ত দেখতে এরকম হতে পারে:
#include "sign_in.h" #include "src/openssl.h"
যুক্তি
গুণাবলী | |
---|---|
name | এই লক্ষ্যের জন্য একটি অনন্য নাম। |
actual | এই টার্গেটটি অবশ্যই বিদ্যমান থাকতে হবে, কিন্তু যেকোন ধরনের নিয়ম হতে পারে (বাঁধাই সহ)। যদি এই অ্যাট্রিবিউটটি বাদ দেওয়া হয়, তাহলে |
local_repository
local_repository(name, path, repo_mapping)
স্থানীয় ডিরেক্টরি থেকে লক্ষ্যগুলিকে আবদ্ধ করার অনুমতি দেয়। এর অর্থ হল বর্তমান সংগ্রহস্থল এই অন্য ডিরেক্টরিতে সংজ্ঞায়িত লক্ষ্যগুলি ব্যবহার করতে পারে। আরো বিস্তারিত জানার জন্য বাঁধন বিভাগ দেখুন.
উদাহরণ
ধরুন বর্তমান সংগ্রহস্থলটি একটি চ্যাট ক্লায়েন্ট, যা ~/chat-app ডিরেক্টরিতে রুট করা হয়েছে। এটি একটি SSL লাইব্রেরি ব্যবহার করতে চায় যা একটি ভিন্ন সংগ্রহস্থলে সংজ্ঞায়িত করা হয়েছে: ~/ssl । SSL লাইব্রেরির একটি টার্গেট আছে //src:openssl-lib
।
ব্যবহারকারী ~/chat-app/WORKSPACE- এ নিম্নলিখিত লাইনগুলি যোগ করে এই লক্ষ্যের উপর নির্ভরতা যোগ করতে পারে:
local_repository( name = "my-ssl", path = "/home/user/ssl", )
লক্ষ্যগুলি @my-ssl//src:openssl-lib
এই লাইব্রেরির উপর নির্ভরশীলতা হিসাবে নির্দিষ্ট করবে।
যুক্তি
গুণাবলী | |
---|---|
name | এই লক্ষ্যের জন্য একটি অনন্য নাম। |
path | এটি অবশ্যই সংগ্রহস্থলের WORKSPACE ফাইল ধারণকারী ডিরেক্টরির একটি পথ হতে হবে। পথটি হয় পরম বা মূল সংগ্রহস্থলের WORKSPACE ফাইলের সাথে সম্পর্কিত হতে পারে। |
repo_mapping | উদাহরণস্বরূপ, একটি এন্ট্রি |
new_local_repository
new_local_repository(name, build_file, build_file_content, path, repo_mapping, workspace_file, workspace_file_content)
একটি স্থানীয় ডিরেক্টরিকে একটি Bazel সংগ্রহস্থলে পরিণত করার অনুমতি দেয়৷ এর অর্থ হল বর্তমান সংগ্রহস্থল ফাইল সিস্টেমের যেকোনো স্থান থেকে লক্ষ্য নির্ধারণ এবং ব্যবহার করতে পারে।
এই নিয়মটি একটি ওয়ার্কস্পেস ফাইল এবং সাবডিরেক্টরি তৈরি করে একটি বেজেল সংগ্রহস্থল তৈরি করে যাতে বিল্ড ফাইল এবং প্রদত্ত পাথের সিমলিঙ্ক রয়েছে। বিল্ড ফাইলটি path
সাথে সম্পর্কিত লক্ষ্যগুলি তৈরি করা উচিত। যে ডিরেক্টরিগুলির জন্য ইতিমধ্যে একটি local_repository
ফাইল এবং একটি BUILD ফাইল রয়েছে, স্থানীয়_রিপোজিটরি নিয়মটি ব্যবহার করা যেতে পারে।
উদাহরণ
ধরুন বর্তমান সংগ্রহস্থলটি একটি চ্যাট ক্লায়েন্ট, যা ~/chat-app ডিরেক্টরিতে রুট করা হয়েছে। এটি একটি SSL লাইব্রেরি ব্যবহার করতে চায় যা একটি ভিন্ন ডিরেক্টরিতে সংজ্ঞায়িত করা হয়েছে: ~/ssl ।
ব্যবহারকারী SSL লাইব্রেরির (~/chat-app/BUILD.my-ssl) জন্য একটি বিল্ড ফাইল তৈরি করে একটি নির্ভরতা যোগ করতে পারে:
java_library( name = "openssl", srcs = glob(['*.java']) visibility = ["//visibility:public"], )
তারপরে তারা নিম্নলিখিত লাইনগুলি ~/chat-app/WORKSPACE এ যোগ করতে পারে:
new_local_repository( name = "my-ssl", path = "/home/user/ssl", build_file = "BUILD.my-ssl", )
এটি একটি @my-ssl
সংগ্রহস্থল তৈরি করবে যা /home/user/ ssl-এর সাথে সিমলিঙ্ক করে। টার্গেটের নির্ভরতা @my-ssl//:openssl
যোগ করে এই লাইব্রেরির উপর নির্ভর করতে পারে।
আপনি শুধুমাত্র ডিরেক্টরি নয়, একক ফাইল অন্তর্ভুক্ত করতে new_local_repository
ব্যবহার করতে পারেন। উদাহরণস্বরূপ, ধরুন আপনার /home/username/Downloads/piano.jar এ একটি জার ফাইল ছিল। আপনি আপনার WORKSPACE ফাইলে নিম্নলিখিত যোগ করে আপনার বিল্ডে ঠিক সেই ফাইলটি যোগ করতে পারেন:
new_local_repository( name = "piano", path = "/home/username/Downloads/piano.jar", build_file = "BUILD.piano", )
এবং নিম্নলিখিত BUILD.piano ফাইল তৈরি করুন:
java_import( name = "play-music", jars = ["piano.jar"], visibility = ["//visibility:public"], )তাহলে piano.jar ব্যবহার করার জন্য লক্ষ্যগুলি
@piano//:play-music
উপর নির্ভর করতে পারে।যুক্তি
গুণাবলী | |
---|---|
name | এই লক্ষ্যের জন্য একটি অনন্য নাম। |
build_file | বিল্ড_ফাইল বা বিল্ড_ফাইল_কন্টেন্ট অবশ্যই নির্দিষ্ট করতে হবে। এই বৈশিষ্ট্যটি প্রধান কর্মক্ষেত্রের সাথে সম্পর্কিত একটি লেবেল। ফাইলটির নাম BUILD করার দরকার নেই, তবে হতে পারে। (BUILD.new-repo-name এর মত কিছু রিপোজিটরির আসল BUILD ফাইল থেকে আলাদা করার জন্য ভাল কাজ করতে পারে।) |
build_file_content | বিল্ড_ফাইল বা বিল্ড_ফাইল_কন্টেন্ট অবশ্যই নির্দিষ্ট করতে হবে। |
path | এটি হয় পরম বা প্রধান সংগ্রহস্থলের WORKSPACE ফাইলের সাথে সম্পর্কিত হতে পারে। |
repo_mapping | উদাহরণস্বরূপ, একটি এন্ট্রি |
workspace_file | হয় ওয়ার্কস্পেস_ফাইল বা ওয়ার্কস্পেস_ফাইল_কন্টেন্ট নির্দিষ্ট করা যেতে পারে, তবে উভয়ই নয়। এই বৈশিষ্ট্যটি প্রধান কর্মক্ষেত্রের সাথে সম্পর্কিত একটি লেবেল। ফাইলটির WORKSPACE নামকরণের প্রয়োজন নেই, তবে হতে পারে। (WORKSPACE.new-repo-name এর মত কিছু রিপোজিটরির আসল WORKSPACE ফাইল থেকে আলাদা করার জন্য ভাল কাজ করতে পারে।) |
workspace_file_content | হয় ওয়ার্কস্পেস_ফাইল বা ওয়ার্কস্পেস_ফাইল_কন্টেন্ট নির্দিষ্ট করা যেতে পারে, তবে উভয়ই নয়। |