واژه نامه بازل

عمل

دستوری برای اجرا در حین ساخت، به عنوان مثال، فراخوانی به یک کامپایلر که آرتیفکت ها را به عنوان ورودی می گیرد و آرتیفکت های دیگری را به عنوان خروجی تولید می کند. شامل ابرداده هایی مانند آرگومان های خط فرمان، کلید عمل، متغیرهای محیطی و مصنوعات ورودی/خروجی اعلام شده است.

همچنین ببینید: مستندات قوانین

اکشن کش

یک کش روی دیسک که نگاشت اقدامات اجرا شده را به خروجی هایی که ایجاد کرده اند ذخیره می کند. کلید حافظه پنهان به عنوان کلید عمل شناخته می شود. یک جزء اصلی برای مدل افزایشی بازل. کش در دایرکتوری پایه خروجی ذخیره می شود و بنابراین از راه اندازی مجدد سرور Bazel جان سالم به در می برد.

نمودار اقدام

یک نمودار در حافظه از اقدامات و مصنوعاتی که این کنش‌ها خوانده و تولید می‌کنند. این نمودار ممکن است شامل مصنوعاتی باشد که به عنوان فایل منبع وجود دارند (مثلاً در سیستم فایل) و همچنین مصنوعات میانی/نهایی تولید شده که در فایل های BUILD ذکر نشده اند. در مرحله تجزیه و تحلیل تولید شده و در مرحله اجرا استفاده می شود.

پرس و جو نمودار اقدام (پرس و جو)

یک ابزار پرس و جو که می تواند در مورد اکشن های ساخت پرس و جو کند. این توانایی تجزیه و تحلیل چگونگی تبدیل قوانین ساخت به کار واقعی ساخت‌ها را فراهم می‌کند.

کلید اقدام

کلید حافظه پنهان یک اقدام . بر اساس ابرداده عمل محاسبه می شود، که ممکن است بسته به عملکرد شامل دستوری باشد که باید در اکشن اجرا شود، پرچم های کامپایلر، مکان های کتابخانه یا سرصفحه های سیستم. Bazel را قادر می سازد تا اقدامات فردی را به طور قطعی ذخیره یا باطل کند.

مرحله تحلیل

فاز دوم ساخت. نمودار هدف مشخص‌شده در فایل‌های BUILD را پردازش می‌کند تا یک نمودار اقدام در حافظه تولید کند که ترتیب عملکردها را در مرحله اجرا تعیین می‌کند. این مرحله ای است که در آن پیاده سازی قوانین ارزیابی می شود.

غیرواقعی، ساختگی

یک فایل منبع یا یک فایل تولید شده. همچنین می‌تواند فهرستی از فایل‌ها باشد که به عنوان مصنوعات درختی شناخته می‌شوند.

یک آرتیفکت ممکن است ورودی برای چندین اقدام باشد، اما باید حداکثر با یک عمل تولید شود.

آرتیفکتی که مربوط به هدف فایل است را می توان با یک برچسب نشان داد.

جنبه

مکانیزمی برای قوانین برای ایجاد اقدامات اضافی در وابستگی های خود. برای مثال، اگر هدف A به B بستگی دارد، می‌توان جنبه‌ای را روی A اعمال کرد که از یک یال وابستگی به B عبور می‌کند و اقدامات اضافی را در B برای تولید و جمع‌آوری فایل‌های خروجی اضافی اجرا می‌کند. این اقدامات اضافی در حافظه پنهان ذخیره می شوند و بین اهدافی که به همان جنبه نیاز دارند، مجددا استفاده می شوند. با تابع aspect() Starlark Build API ایجاد شده است. به عنوان مثال، می توان از آن برای تولید ابرداده برای IDE ها و ایجاد اکشن هایی برای linting استفاده کرد.

همچنین ببینید: مستندات جنبه ها

جنبه در جنبه

مکانیزم ترکیبی که به موجب آن جنبه‌ها می‌توانند بر نتایج سایر جنبه‌ها اعمال شوند. به عنوان مثال، جنبه ای که اطلاعاتی را برای استفاده توسط IDE ها تولید می کند، می تواند در بالای جنبه ای اعمال شود که فایل های .java . را از یک پروتو تولید می کند.

برای اینکه یک جنبه A در بالای جنبه B اعمال شود، ارائه دهندگانی که B در ویژگی provides خود تبلیغ می کند باید با آنچه A اعلام می required_aspect_providers در ویژگی require_aspect_providers خود مطابقت داشته باشند.

صفت

یک پارامتر برای یک قانون ، که برای بیان اطلاعات ساخت هر هدف استفاده می شود. مثال‌ها عبارتند از srcs ، deps و copts که به ترتیب فایل‌های منبع هدف، وابستگی‌ها و گزینه‌های کامپایلر سفارشی را اعلام می‌کنند. ویژگی های خاص موجود برای یک هدف معین به نوع قانون آن بستگی دارد.

.bazelrc

فایل پیکربندی Bazel برای تغییر مقادیر پیش‌فرض برای پرچم‌های راه‌اندازی و پرچم‌های فرمان ، و برای تعریف گروه‌های مشترک از گزینه‌ها که می‌توانند با استفاده از یک پرچم --config با هم در خط فرمان --config تنظیم شوند، استفاده می‌شود. Bazel می‌تواند تنظیمات را از چندین فایل bazelrc (در سراسر سیستم، در هر فضای کاری، برای هر کاربر یا از یک مکان سفارشی) ترکیب کند، و یک فایل bazelrc ممکن است تنظیمات را از سایر فایل‌های bazelrc نیز وارد کند.

آتش

نسخه داخلی Google Bazel. سیستم اصلی ساخت گوگل برای مخزن تکی آن.

فایل BUILD

یک فایل BUILD فایل پیکربندی اصلی است که به Bazel می‌گوید چه خروجی‌های نرم‌افزاری را بسازد، چه وابستگی‌هایی دارد و چگونه آنها را بسازد. Bazel یک فایل BUILD را به عنوان ورودی می گیرد و از فایل برای ایجاد نموداری از وابستگی ها و استخراج اقداماتی که باید برای ساختن خروجی های نرم افزار میانی و نهایی انجام شود، استفاده می کند. یک فایل BUILD یک دایرکتوری و هر زیرمجموعه‌ای که حاوی فایل BUILD نیست به عنوان یک بسته علامت‌گذاری می‌کند و می‌تواند حاوی اهداف ایجاد شده توسط قوانین باشد. فایل را می توان BUILD.bazel نیز نامید.

فایل BUILD.bazel

فایل BUILD را ببینید. بر یک فایل BUILD در همان دایرکتوری اولویت دارد.

فایل bzl

فایلی که قوانین، ماکروها و ثابت های نوشته شده در Starlark را تعریف می کند. سپس با استفاده از تابع load() می توان آنها را به فایل های BUILD وارد کرد.

ساخت نمودار

نمودار وابستگی که بازل می سازد و برای اجرای یک بیلد از آن عبور می کند. شامل گره هایی مانند اهداف ، اهداف پیکربندی شده ، اقدامات و مصنوعات است . زمانی که تمام آرتیفکت هایی که مجموعه ای از اهداف درخواستی به آنها وابسته است، به روز بودن تأیید شوند، یک ساخت کامل در نظر گرفته می شود.

تنظیم ساخت

یک قطعه پیکربندی تعریف شده توسط Starlark. Transitions می تواند تنظیمات ساخت را برای تغییر پیکربندی زیرگراف تنظیم کند. اگر به عنوان پرچم خط فرمان در معرض کاربر قرار گیرد که به عنوان پرچم ساخت نیز شناخته می شود.

ساخت تمیز

ساختی که از نتایج ساخت‌های قبلی استفاده نمی‌کند. این به طور کلی کندتر از ساخت افزایشی است اما معمولاً صحیح تر است. Bazel تضمین می کند که هر دو ساخت تمیز و افزایشی همیشه درست هستند.

مدل کلاینت-سرور

سرویس گیرنده خط فرمان bazel به طور خودکار یک سرور پس زمینه را در ماشین محلی راه اندازی می کند تا دستورات Bazel را اجرا کند. سرور در تمام دستورات ادامه می‌یابد، اما به طور خودکار پس از یک دوره عدم فعالیت (یا به طور صریح از طریق خاموش شدن bazel) متوقف می‌شود. تقسیم Bazel به سرور و کلاینت به استهلاک زمان راه‌اندازی JVM کمک می‌کند و از ساخت‌های افزایشی سریع‌تر پشتیبانی می‌کند زیرا نمودار عمل در بین دستورات در حافظه باقی می‌ماند.

فرمان

در خط فرمان برای فراخوانی توابع مختلف Bazel، مانند bazel build bazel test bazel run bazel query استفاده می شود.

پرچم های فرماندهی

مجموعه ای از پرچم های خاص برای یک دستور . پرچم های فرمان بعد از دستور ( bazel build <command flags> ) مشخص می شوند. پرچم ها می توانند برای یک یا چند فرمان قابل اعمال باشند. به عنوان مثال، --configure یک پرچم منحصرا برای دستور bazel sync bazel است، اما --keep_going برای sync ، build ، test و موارد دیگر قابل استفاده است. پرچم‌ها اغلب برای اهداف پیکربندی استفاده می‌شوند، بنابراین تغییرات در مقادیر پرچم می‌تواند باعث شود Bazel نمودارهای درون حافظه را باطل کند و مرحله تجزیه و تحلیل را مجدداً راه‌اندازی کند.

پیکربندی

اطلاعات خارج از تعاریف قوانین که بر نحوه تولید کنش‌ها تأثیر می‌گذارد. هر ساختنی حداقل یک پیکربندی دارد که پلتفرم هدف، متغیرهای محیط عمل و پرچم‌های ساخت خط فرمان را مشخص می‌کند. انتقال ها ممکن است پیکربندی های اضافی را ایجاد کنند، مانند ابزارهای میزبان یا کامپایل متقابل.

همچنین ببینید: تنظیمات

برش پیکربندی

فرآیندی که فقط شامل قطعات پیکربندی مورد نیاز یک هدف است. به عنوان مثال، اگر جاوا باینری //:j را با وابستگی به C++ //:c بسازید، گنجاندن مقدار --javacopt در پیکربندی //:c بیهوده است زیرا تغییر --javacopt بی جهت قابلیت ذخیره سازی C++ را از بین می برد.

جستجوی پیکربندی شده (کوئری)

یک ابزار پرس و جو که از اهداف پیکربندی شده (پس از تکمیل مرحله تجزیه و تحلیل ) پرس و جو می کند. این بدان معناست که پرچم‌های select() و ساخت (مانند --platforms ) به‌طور دقیق در نتایج منعکس می‌شوند.

همچنین نگاه کنید به: اسناد درخواست

هدف پیکربندی شده

نتیجه ارزیابی یک هدف با یک پیکربندی . مرحله تجزیه و تحلیل این را با ترکیب گزینه های ساخت با اهدافی که باید ساخته شوند، ایجاد می کند. به عنوان مثال، اگر //:foo برای دو معماری مختلف در یک بیلد بسازد، دو هدف پیکربندی شده دارد: <//:foo, x86> و <//:foo, arm> .

صحت

یک ساخت زمانی درست است که خروجی آن به طور صادقانه وضعیت ورودی های انتقالی آن را منعکس کند. برای دستیابی به ساخت‌های صحیح، بازل تلاش می‌کند هرمتیک ، تکرارپذیر باشد و تجزیه و تحلیل ساخت و اجرای عمل را قطعی کند.

وابستگی

یک لبه جهت دار بین دو هدف . یک هدف //:foo وابستگی هدف به هدف //:bar دارد اگر مقادیر ویژگی //:foo حاوی ارجاع به //:bar باشد. //:foo وابستگی عمل به //:bar دارد اگر یک عمل در //:foo به یک مصنوع ورودی ایجاد شده توسط یک عمل در //:bar بستگی دارد.

Depset

یک ساختار داده برای جمع آوری داده ها در مورد وابستگی های گذرا. بهینه‌سازی شده است تا ادغام دپست‌ها در زمان و مکان کارآمد باشد، زیرا داشتن دپست‌های بسیار بزرگ (صدها هزار فایل) معمول است. پیاده‌سازی شده برای ارجاع بازگشتی به سایر عمق‌ها به دلایل کارایی فضا. پیاده سازی قوانین نباید با تبدیل کردن آنها به لیست ها، depset ها را "مسطح" کنند، مگر اینکه این قانون در سطح بالای نمودار ساخت باشد. صاف کردن عمق های بزرگ مصرف حافظه زیادی را به همراه دارد. در اجرای داخلی Bazel به مجموعه های تو در تو نیز معروف است.

همچنین ببینید: اسناد Depset

کش دیسک

یک فروشگاه محلی حباب روی دیسک برای ویژگی حافظه پنهان از راه دور. می توان در ارتباط با فروشگاه واقعی حباب از راه دور استفاده کرد.

Distdir

دایرکتوری فقط خواندنی حاوی فایل هایی که Bazel در غیر این صورت با استفاده از قوانین مخزن از اینترنت دریافت می کرد. ساخت‌ها را قادر می‌سازد تا کاملاً آفلاین اجرا شوند.

اجرای پویا

یک استراتژی اجرایی که بین اجرای محلی و از راه دور بر اساس اکتشافی های مختلف انتخاب می کند و از نتایج اجرای روش موفق سریعتر استفاده می کند. برخی اقدامات به صورت محلی سریعتر اجرا می شوند (مثلاً پیوند دادن) و برخی دیگر از راه دور سریعتر انجام می شوند (مثلاً کامپایل با قابلیت موازی سازی بسیار). یک استراتژی اجرای پویا می تواند بهترین زمان ساخت افزایشی و تمیز را ارائه دهد.

مرحله اجرا

فاز سوم ساخت. اقدامات موجود در نمودار اقدام ایجاد شده در مرحله تجزیه و تحلیل را اجرا می کند. این اقدامات از فایل های اجرایی (کامپایلرها، اسکریپت ها) برای خواندن و نوشتن مصنوعات استفاده می کنند. استراتژی‌های Spawn نحوه اجرای این اقدامات را کنترل می‌کنند: به صورت محلی، از راه دور، پویا، sandboxed، docker و غیره.

ریشه اعدام

دایرکتوری در دایرکتوری پایه خروجی فضای کاری که در آن اکشن های محلی در بیلدهای غیر سندباکس اجرا می شوند . محتویات دایرکتوری عمدتاً پیوندهای نمادین مصنوعات ورودی از فضای کاری هستند. ریشه اجرا همچنین حاوی پیوندهای نمادین به مخازن خارجی به عنوان ورودی های دیگر و دایرکتوری bazel-out برای ذخیره خروجی ها است. در طول فاز بارگذاری با ایجاد یک جنگل سیملینک از دایرکتوری‌هایی که بسته شدن موقت بسته‌هایی را که یک بیلد به آن‌ها بستگی دارد، آماده می‌شود. با bazel info execution_root در خط فرمان قابل دسترسی است.

فایل

مصنوع را ببینید.

هرمتیک

اگر هیچ تأثیر خارجی بر عملیات ساخت و آزمایش آن وجود نداشته باشد، هرمتیک است که به اطمینان از قطعی و صحیح بودن نتایج کمک می کند. برای مثال، ساخت‌های هرمتیک معمولاً دسترسی شبکه به اقدامات را ممنوع می‌کنند، دسترسی به ورودی‌های اعلام‌شده را محدود می‌کنند، از مُهرهای زمانی و مناطق زمانی ثابت استفاده می‌کنند، دسترسی به متغیرهای محیطی را محدود می‌کنند، و از دانه‌های ثابت برای تولیدکننده‌های اعداد تصادفی استفاده می‌کنند.

ساخت افزایشی

یک ساخت افزایشی از نتایج ساخت های قبلی مجددا استفاده می کند تا زمان ساخت و استفاده از منابع را کاهش دهد. چک کردن وابستگی و کش کردن با هدف ایجاد نتایج صحیح برای این نوع ساخت است. ساخت افزایشی برعکس ساخت تمیز است.

برچسب

یک شناسه برای یک هدف . یک برچسب کاملاً واجد شرایط مانند //path/to/package:target شامل // برای علامت گذاری دایرکتوری ریشه فضای کاری، path/to/package به عنوان دایرکتوری حاوی فایل BUILD که هدف را اعلام می کند، و :target به عنوان نام است. هدف اعلام شده در فایل BUILD فوق الذکر. همچنین ممکن است با @my_repository//<..> پیشوند شود تا نشان دهد که هدف در یک ]مخزن خارجی] به نام my_repository شده است.

فاز بارگذاری

مرحله اول ساخت که در آن Bazel فایل های WORKSPACE ، BUILD و .bzl . را برای ایجاد بسته ها تجزیه می کند. ماکروها و توابع خاصی مانند glob() در این مرحله ارزیابی می شوند. با فاز دوم ساخت، مرحله تجزیه و تحلیل ، برای ایجاد یک گراف هدف آمیخته شده است.

ماکرو

مکانیزمی برای ترکیب چند اعلان هدف قانون با هم تحت یک تابع Starlark . استفاده مجدد از الگوهای اعلام قوانین رایج در فایل های BUILD را فعال می کند. در مرحله بارگذاری به اعلامیه های هدف قاعده اساسی گسترش یافت.

همچنین ببینید: مستندات کلان

حفظی

یک رشته کوتاه و قابل خواندن برای انسان که توسط نویسنده قانون انتخاب شده است تا به سرعت بفهمد یک عمل در قانون چه کاری انجام می دهد. Mnemonics می تواند به عنوان شناسه برای انتخاب استراتژی تخم ریزی استفاده شود . برخی از نمونه‌های اکشن Javac عبارتند از Javac از قوانین جاوا، CppCompile از قوانین C++، و AndroidManifestMerger از قوانین Android.

قوانین بومی

قوانینی که در Bazel تعبیه شده و در جاوا پیاده سازی می شوند. چنین قوانینی در فایل‌های .bzl . به عنوان توابعی در ماژول اصلی ظاهر می‌شوند (به عنوان مثال native.cc_library یا native.java_library ). قوانین تعریف شده توسط کاربر (غیر بومی) با استفاده از Starlark ایجاد می شوند.

پایه خروجی

دایرکتوری مخصوص فضای کاری برای ذخیره فایل های خروجی Bazel. برای جدا کردن خروجی ها از درخت منبع فضای کاری استفاده می شود. در ریشه کاربر خروجی قرار دارد.

گروه های خروجی

گروهی از فایل‌ها که انتظار می‌رود زمانی که Bazel ساخت یک هدف را به پایان رساند ساخته شود. قوانین خروجی های معمول خود را در "گروه خروجی پیش فرض" قرار می دهند (به عنوان مثال فایل .jar java_library ، .a و .so برای اهداف cc_library ). گروه خروجی پیش فرض گروه خروجی است که مصنوعات آن هنگام درخواست هدف در خط فرمان ساخته می شوند. قوانین می‌توانند گروه‌های خروجی با نام بیشتری را تعریف کنند که می‌توانند به صراحت در فایل‌های BUILD (قانون گروه filegroup ) یا خط فرمان (پرچم --output_groups ) مشخص شوند.

خروجی کاربر root

دایرکتوری مخصوص کاربر برای ذخیره خروجی های Bazel. نام دایرکتوری از نام کاربری سیستم کاربر مشتق شده است. در صورتی که چندین کاربر همزمان پروژه مشابهی را روی سیستم بسازند، از تصادم فایل های خروجی جلوگیری می کند. شامل دایرکتوری های فرعی مربوط به خروجی های ساخت فضاهای کاری فردی است که به عنوان پایه های خروجی نیز شناخته می شوند.

بسته

مجموعه ای از اهداف تعریف شده توسط یک فایل BUILD . نام بسته، مسیر فایل BUILD نسبت به ریشه فضای کاری است. یک بسته می تواند حاوی زیر بسته ها یا زیر شاخه هایی باشد که حاوی فایل های BUILD هستند، بنابراین یک سلسله مراتب بسته را تشکیل می دهد.

گروه بسته

هدفی که مجموعه ای از بسته ها را نشان می دهد. اغلب در مقادیر ویژگی visibility استفاده می شود.

سکو

یک "نوع ماشین" درگیر در ساخت. این شامل ماشینی است که Bazel روی آن اجرا می شود (پلتفرم "میزبان")، ماشین هایی که ابزار را بر روی (سکوهای "exec") اجرا می کنند، و اهداف ماشین ها برای آنها ("سکوهای هدف") ساخته شده اند.

ارائه دهنده

طرحی که واحدی از اطلاعات را برای انتقال بین اهداف قانون در طول روابط وابستگی توصیف می کند. معمولاً این شامل اطلاعاتی مانند گزینه‌های کامپایلر، فایل‌های منبع انتقالی یا خروجی و متادیتای ساخت است. اغلب در ارتباط با depsets برای ذخیره موثر داده های انتقالی انباشته شده استفاده می شود. نمونه ای از ارائه دهنده داخلی DefaultInfo است.

همچنین نگاه کنید به: مستندات ارائه دهنده

پرس و جو (مفهوم)

فرآیند تجزیه و تحلیل یک نمودار ساخت برای درک ویژگی های هدف و ساختارهای وابستگی. Bazel از سه نوع پرس و جو پشتیبانی می کند: query ، cquery و aquery .

پرس و جو (فرمان)

یک ابزار پرس و جو که بر روی گراف هدف فاز پس از بارگذاری بیلد عمل می کند. این نسبتاً سریع است، اما نمی‌تواند اثرات select() ، ساخت پرچم‌ها ، مصنوعات یا اکشن‌های ساخت را تحلیل کند.

همچنین ببینید: Query how-to , Query reference

کش مخزن

یک حافظه پنهان محتوای آدرس‌پذیر از فایل‌های به اشتراک گذاشته شده توسط Bazel برای ساخت‌ها، قابل اشتراک‌گذاری در بین فضاهای کاری . ساخت های آفلاین را پس از دانلود اولیه فعال می کند. معمولاً برای ذخیره فایل‌های دانلود شده از طریق قوانین مخزن مانند http_archive و APIهای قانون مخزن مانند repository_ctx.download استفاده می‌شود. فایل‌ها تنها در صورتی ذخیره می‌شوند که چک‌سام SHA-256 آنها برای دانلود مشخص شده باشد.

تکرارپذیری

ویژگی یک ساخت یا تست که مجموعه‌ای از ورودی‌ها برای ساخت یا تست همیشه مجموعه‌ای از خروجی‌ها را هر بار بدون در نظر گرفتن زمان، روش یا محیط تولید می‌کنند. توجه داشته باشید که این لزوماً به معنای صحیح بودن خروجی ها یا خروجی های مورد نظر نیست.

قانون

طرحی برای تعریف اهداف قانون در یک فایل BUILD ، مانند cc_library . از دیدگاه یک نویسنده فایل BUILD ، یک قانون شامل مجموعه ای از ویژگی ها و منطق جعبه سیاه است. منطق به هدف قانون می‌گوید که چگونه می‌تواند مصنوعات خروجی تولید کند و اطلاعات را به سایر اهداف قانون منتقل کند. از دیدگاه نویسندگان .bzl ، قوانین راه اصلی برای گسترش Bazel برای پشتیبانی از زبان‌ها و محیط‌های برنامه‌نویسی جدید است.

قوانین برای تولید اهداف قاعده در مرحله بارگذاری نمونه سازی شده اند. در مرحله تجزیه و تحلیل ، هدف‌های قانون، اطلاعات را در قالب ارائه‌دهنده‌ها به وابستگی‌های پایین‌دستی خود منتقل می‌کنند و اقداماتی را ثبت می‌کنند که نحوه تولید مصنوعات خروجی خود را توضیح می‌دهد. این اقدامات در مرحله اجرا اجرا می شوند.

همچنین ببینید: مستندات قوانین

هدف قانون

هدفی که مصداق قاعده است. با اهداف فایل و گروه های بسته تضاد دارد. با قاعده اشتباه نشود.

ران فایل ها

وابستگی های زمان اجرا یک هدف اجرایی. معمولاً فایل اجرایی خروجی اجرایی یک قانون تست است و فایل‌های اجرا وابستگی داده‌های زمان اجرا آزمون هستند. قبل از فراخوانی فایل اجرایی (در حین تست بازل)، Bazel درختی از runfiles را در کنار فایل اجرایی آزمایشی با توجه به ساختار دایرکتوری منبع آنها آماده می کند.

همچنین ببینید: مستندات Runfiles

سندباکس

تکنیکی برای جداسازی یک عمل در حال اجرا در یک ریشه اجرای محدود و موقت، که به اطمینان از خواندن ورودی های اعلام نشده یا نوشتن خروجی های اعلام نشده کمک می کند. Sandboxing تا حد زیادی هرمتیک را بهبود می بخشد، اما معمولاً هزینه عملکردی دارد و نیاز به پشتیبانی از سیستم عامل دارد. هزینه عملکرد به پلت فرم بستگی دارد. در لینوکس، مهم نیست، اما در macOS می‌تواند سندباکس را غیرقابل استفاده کند.

اسکای فریم

Skyframe چارچوب ارزیابی موازی، عملکردی و افزایشی Bazel است.

مهر زدن

قابلیتی برای جاسازی اطلاعات اضافی در مصنوعات ساخته شده بازل. به عنوان مثال، این می تواند برای کنترل منبع، زمان ساخت و سایر فضای کاری یا اطلاعات مربوط به محیط برای ساخت های انتشار استفاده شود. از طریق پرچم --workspace_status_command و قوانینی که از ویژگی stamp پشتیبانی می کنند فعال کنید.

استارلارک

زبان برنامه افزودنی برای نوشتن قوانین و ماکروها . زیرمجموعه ای محدود از پایتون (از نظر نحوی و دستوری) با هدف پیکربندی و عملکرد بهتر. از پسوند فایل .bzl . استفاده می کند. فایل‌های BUILD از نسخه محدودتر Starlark (مانند بدون تعریف تابع def ) استفاده می‌کنند که قبلاً Skylark نام داشت.

همچنین ببینید: مستندات زبان Starlark

پرچم های راه اندازی

مجموعه ای از پرچم های مشخص شده بین bazel و دستور ، به عنوان مثال، --host_jvm_debug build. این پرچم‌ها پیکربندی سرور Bazel را تغییر می‌دهند، بنابراین هرگونه تغییر در پرچم‌های راه‌اندازی باعث راه‌اندازی مجدد سرور می‌شود. پرچم های راه اندازی مختص هیچ دستوری نیستند.

هدف

یک شی که در یک فایل BUILD تعریف شده و با یک برچسب مشخص می شود. اهداف واحدهای قابل ساخت یک فضای کاری را از دیدگاه کاربر نهایی نشان می دهند.

هدفی که با نمونه سازی یک قانون اعلام می شود، هدف قانون نامیده می شود. بسته به قانون، اینها ممکن است قابل اجرا (مانند cc_binary ) یا قابل آزمایش (مانند cc_test ) باشند. اهداف قانون معمولاً از طریق ویژگی های خود (مانند deps ) به اهداف دیگر بستگی دارند. این وابستگی ها اساس نمودار هدف را تشکیل می دهند.

به غیر از اهداف قانون، اهداف فایل و اهداف گروه بسته نیز وجود دارد. اهداف فایل مربوط به مصنوعاتی است که در یک فایل BUILD ارجاع داده می شود. به عنوان یک مورد خاص، فایل BUILD هر بسته همیشه به عنوان هدف فایل منبع در آن بسته در نظر گرفته می شود.

اهداف در مرحله بارگیری کشف می شوند. در طول مرحله تجزیه و تحلیل ، اهداف با پیکربندی های ساخت مرتبط می شوند تا اهداف پیکربندی شده را تشکیل دهند.

نمودار هدف

یک نمودار در حافظه از اهداف و وابستگی های آنها. در مرحله بارگذاری تولید شده و به عنوان ورودی فاز آنالیز استفاده می شود .

الگوی هدف

راهی برای تعیین گروهی از اهداف در خط فرمان. الگوهای رایج مورد استفاده عبارتند از :all (همه اهداف قانون)، :* (همه قوانین + اهداف فایل)، ... ( بسته فعلی و همه بسته های فرعی به صورت بازگشتی). می تواند به صورت ترکیبی استفاده شود، به عنوان مثال، //...:* به معنای تمام قوانین و اهداف فایل در همه بسته ها به صورت بازگشتی از ریشه فضای کاری است.

تست ها

قانون از قوانین تست نمونه برداری می شود و بنابراین شامل یک آزمایش اجرایی است. کد بازگشتی صفر از تکمیل فایل اجرایی نشان دهنده موفقیت تست است. قرارداد دقیق بین Bazel و تست ها (مانند متغیرهای محیط آزمایش، روش های جمع آوری نتایج آزمون) در دایره المعارف تست مشخص شده است.

زنجیره ابزار

مجموعه ای از ابزارها برای ساختن خروجی برای یک زبان. به طور معمول، یک زنجیره ابزار شامل کامپایلرها، پیونددهنده ها، مفسرها یا/یا لینترها است. یک زنجیره ابزار همچنین می‌تواند بسته به پلتفرم متفاوت باشد، یعنی اجزای زنجیره ابزار کامپایلر یونیکس ممکن است برای نوع ویندوز متفاوت باشد، حتی اگر زنجیره ابزار برای یک زبان باشد. انتخاب زنجیره ابزار مناسب برای پلتفرم به عنوان رزولوشن زنجیره ابزار شناخته می شود.

هدف سطح بالا

هدف ساخت اگر در خط فرمان Bazel درخواست شود در سطح بالایی قرار دارد. به عنوان مثال، اگر //:foo به //:bar بستگی دارد، و bazel build //:foo نامیده می شود، برای این ساخت، //:foo سطح بالایی است و //:bar سطح بالایی نیست. ، اگرچه هر دو هدف باید ساخته شوند. یک تفاوت مهم بین اهداف سطح بالا و غیر سطح بالا این است که پرچم های فرمان تنظیم شده در خط فرمان Bazel (یا از طریق .bazelrc ) پیکربندی را برای اهداف سطح بالا تنظیم می کند، اما ممکن است با یک انتقال برای اهداف غیر اصلاح شود. اهداف سطح بالا

انتقال

نگاشت وضعیت پیکربندی از یک مقدار به مقدار دیگر. اهداف موجود در نمودار ساخت را فعال می‌کند تا پیکربندی‌های متفاوتی داشته باشند، حتی اگر از یک قانون نمونه‌سازی شده باشند. استفاده متداول از انتقال ها با انتقال تقسیم است، که در آن بخش های خاصی از نمودار هدف با پیکربندی های مجزا برای هر فورک دوشاخه می شود. برای مثال، می‌توان یک APK Android با باینری‌های بومی که برای ARM و x86 کامپایل شده‌اند، با استفاده از انتقال‌های تقسیم در یک بیلد ایجاد کرد.

همچنین نگاه کنید به: انتقال های تعریف شده توسط کاربر

مصنوع درخت

آرتیفکتی که مجموعه ای از فایل ها را نشان می دهد. از آنجایی که این فایل‌ها خودشان مصنوع نیستند، عملی که روی آن‌ها عمل می‌کند باید در عوض مصنوع درخت را به عنوان ورودی یا خروجی ثبت کند.

دید

یکی از دو مکانیسم برای جلوگیری از وابستگی های ناخواسته در سیستم ساخت: دید هدف برای کنترل اینکه آیا یک هدف می تواند توسط سایر اهداف به آن وابسته باشد یا خیر. و قابلیت مشاهده برای کنترل اینکه آیا یک فایل BUILD یا .bzl ممکن است یک فایل .bzl معین را بارگیری کند، بارگذاری شود. بدون زمینه، معمولاً "رؤیت" به دید هدف اشاره دارد.

همچنین نگاه کنید به: مستندات رویت

فضای کار

دایرکتوری حاوی یک فایل WORKSPACE و کد منبع برای نرم افزاری که می خواهید بسازید. برچسب هایی که با // شروع می شوند نسبت به دایرکتوری فضای کاری هستند.

فایل WORKSPACE

دایرکتوری را به عنوان یک فضای کاری تعریف می کند. این فایل می‌تواند خالی باشد، اگرچه معمولاً حاوی اعلان‌های مخزن خارجی برای واکشی وابستگی‌های اضافی از شبکه یا سیستم فایل محلی است.