פעולה
פקודה שאפשר להריץ במהלך ה-build, לדוגמה, קריאה לקופייללר שמקבלת פריטי מידע שנוצרים בתהליך פיתוח (Artifact) כקלטים, ומפיקה חפצים אחרים כפלט. כולל מטא-נתונים כמו הארגומנטים של שורת הפקודה, מפתח הפעולה, משתני סביבה ופריטי קלט/פלט מוצהרים.
לעיון גם ב: מסמכי תיעוד של כללים
מטמון פעולות
מטמון אחסון שעומד לאחסן את המיפוי של הפעולות שבוצעו לפלטים שהם יצרו. מקש המטמון ידוע בתור מפתח פעולה. רכיב מרכזי במודל המצטבר של Bazel&33. המטמון מאוחסן בספריית הבסיס של הפלט ולכן עשוי להמשיך לעבוד עם שרת Bazel.
תרשים פעולות
תרשים זיכרון של פעולות ופריטי המידע שפעולות אלה קוראות ויוצרות. התרשים עשוי לכלול חפצים הקיימים כקובצי מקור (למשל, במערכת הקבצים), וכן פריטי מידע שנוצרו בתהליך ביניים/סיום סופי שלא מוזכרים בקובצי BUILD. הופקו במהלך שלב הניתוח ונעשה בו שימוש בשלב הביצוע.
שאילתת תרשים פעולה (שאילתה)
כלי שאילתות שיכול לבצע שאילתות לגבי פעולות ב-build. כך אפשר לנתח את האופן שבו כללי Build מתרגמים לתרגום קיים בעבודה.
מקש פעולה
מפתח המטמון של פעולה. החישוב בוצע על סמך מטא-נתונים של הפעולות, שעשויים לכלול את הפקודה לביצוע בפעולה, דגלי המהדרים, מיקומי הספרייה או כותרות המערכת, בהתאם לפעולה. מאפשר ל-Bazel לשמור במטמון או לפסול פעולות ספציפיות באופן דטרמיניסטי.
שלב הניתוח
השלב השני של ה-build. מעבד את תרשים היעד שצוין ב-BUILD קבצים, כדי ליצור תרשים
פעולות בזיכרון שיקבע את סדר הפעולות שירוצו במהלך
שלב הביצוע. השלב הזה הוא ההערכה
של הטמעת הכללים.
פריט מידע שנוצר בתהליך פיתוח (Artifact)
קובץ מקור או קובץ שנוצר. אפשר גם להשתמש בספריית קבצים שנקראים עץ פריטים.
פריט מידע שנוצר בתהליך פיתוח (Artifact) יכול להיות קלט שכולל כמה פעולות, אבל צריך ליצור אותו רק באמצעות פעולה אחת לכל היותר.
תווית שמטופלת עם יעד קובץ יכולה לקבל תווית.
יחס גובה-רוחב
מנגנון ליצירת כללים שיוצרים פעולות נוספות בהתאם לתלויות שלהם. לדוגמה, אם יעד א' תלוי ב-ב', אחד יכול להחיל היבט על א' שמַעבר את קצה התלות ל-B, ומפעיל עוד פעולות ב' כדי ליצור ולאסוף קובצי פלט נוספים. הפעולות הנוספות האלה נשמרות במטמון ונעשה בהן שימוש חוזר בין יעדים שדורשים את אותו היבט. נוצרה באמצעות הפונקציה aspect() של Starlark Build API. לדוגמה, אפשר להשתמש בו כדי ליצור מטא-נתונים ל-IDE, וליצור פעולות למכונה.
ראו גם: מסמכי היבטים
יחס גובה-רוחב
מנגנון הרכב שבו אפשר להחיל היבטים על התוצאות של היבטים אחרים. לדוגמה, אפשר להחיל היבט שיוצר מידע לשימוש עבור הפיתוחים המשולבים (IDE), בנוסף להיבט שיוצר .java קבצים מפרוטוקול.
כדי שהיבטים של A יחולו על היבט B, הספקים שמפרסמים במאפיין ה-provides שלהם חייבים להיות תואמים למה ש-A מצהיר שרוצה לכלול במאפיין ה-required_aspect_providers.
מאפיין
פרמטר כלל, המשמש לביטוי פרטי build של כל יעד.
לדוגמה, srcs, deps ו-copts, שמצהירים בהתאמה על קובצי מקור של יעד, יחסי תלות ואפשרויות של מהדר מותאם אישית. המאפיינים הספציפיים הזמינים ליעד נתון תלויים בסוג הכלל שלו.
.bazelrc
קובץ התצורה של Bazel משמש לשינוי ערכי ברירת המחדל של דגלים להפעלה וסימונים של פקודות, וכדי להגדיר קבוצות נפוצות של אפשרויות שניתן להגדיר יחד בשורת הפקודה של Bazel באמצעות סימון --config. מאחר ש-Bazel יכולה לשלב הגדרות מכמה קובצי Bazelrc
(בכל המערכת, בכל סביבת עבודה, לכל משתמש או ממיקום מותאם אישית), וייתכן שגם קובץ bazelrc יייבא הגדרות מקובץ bazelrc אחר.
Blaze
הגרסה הפנימית של Google של Bazel. מערכת הבנייה הראשית של Google עבור מאגר המונו.
קובץ BUILD
קובץ BUILD הוא קובץ התצורה הראשי שמסביר ל-Bazel אילו תוכנות תוכננו לבנות, מהן יחסי תלות שלהן ואיך ליצור אותן. Bazel משתמשת בקובץ BUILD כקלט ומשתמשת בקובץ כדי ליצור תרשים של יחסי תלות וכדי להסיק את הפעולות שצריך להשלים כדי ליצור פלטי תוכנה בינוניים וסופיים. קובץ BUILD מסמן ספרייה וכל ספריות משנה שאינן מכילות קובץ BUILD כחבילה, והוא יכול להכיל יעדים שנוצרו על ידי כללים. אפשר גם לתת לקובץ שם
BUILD.bazel.
קובץ BUILD.bazel
עיינו בקובץ של BUILD. מקבלת עדיפות על פני קובץ BUILD באותה ספרייה.
קובץ .bzl
קובץ המגדיר כללים, פקודות מאקרו וקבועים שמוגדרים ב-Starlark. לאחר מכן ניתן לייבא את הקבצים האלה ל-BUILD
קבצים באמצעות הפונקציה load().
יצירת תרשים
תרשים התאימות ש-Bazel בונה וחוצה כדי לבצע build. כולל צמתים כמו יעדים, יעדים מוגדרים, פעולות וחפצים. מבנה מוגדר כעסק שהושלם כשכל פריטי המידע שבהם קבוצה של יעדים מבוקשים מתעדכנים כעדכניים.
הגדרת build
קטע של הגדרה לפי הגדרת Starlark. מעברים יכולים לקבוע את הגדרות ה-build כדי לשנות תצורה של כתוביות. אם היא נחשפה למשתמש כסימון שורת הפקודה, שנקראת גם תכונה ניסיונית של build.
גרסת build נקייה
גרסת build שלא משתמשת בתוצאות של גרסאות build קודמות. לרוב, התגובה הזו איטית יותר מגרסה מצטברת אבל לרוב נחשבת כנכונה יותר. מאחר ש-Bazel מבטיח שגרסאות build נקיות ומצטברות יהיו תמיד נכונות.
מודל שרת-הלקוח
לקוח שורת הפקודה bazel מפעיל באופן אוטומטי שרת רקע במחשב המקומי, כדי לבצע פקודות ב-Bazel. השרת ממשיך לפעול בכל הפקודות אבל מפסיק אוטומטית אחרי פרק זמן מסוים של חוסר פעילות (או באופן מפורש באמצעות כיבוי הדפדפן). פיצול Bazel לשרת ולקוח עוזר להפחתה בזמן ההפעלה של JVM ותומך בגרסאות build מצטברות מהר יותר, כי תרשים הפעולה נשאר בזיכרון בין פקודות שונות.
Command
משמש בשורת הפקודה כדי להפעיל פונקציות Bazel שונות, כמו bazel
build, bazel test, bazel run וbazel query.
התרעות לגבי פקודות
קבוצה של סימונים ספציפיים לפקודה. התרעות לגבי פקודות מופיעות אחרי הפקודה (bazel build <command flags>). הסימונים יכולים להופיע בפקודה אחת או יותר. לדוגמה, --configure הוא דגל היחיד עבור הפקודה bazel sync, אבל --keep_going חל על sync, build,
test ועוד. לעיתים קרובות נעשה שימוש בסימונים למטרות הגדרה, כך ששינויים בערכי הדגל עשויים לגרום ל-Bazel לבטל את זמינות התרשימים ולהפעיל מחדש את שלב הניתוח.
הגדרה
מידע מחוץ להגדרות של כלל שמשפיע על האופן שבו כללים יוצרים פעולות. לכל build יש לפחות הגדרה אחת שמציינת את פלטפורמת היעד, את משתני סביבת הפעולה ואת הדגלים של שורת הפקודה. מעברים עשויים ליצור הגדרות נוספות, כמו כלי מארח או הידור מוצלב.
כדאי לעיין גם ב: הגדרות
חיתוך תצורה
התהליך שכולל רק את החלקים של התצורה שקהל היעד שלהם צריך בפועל. לדוגמה, אם תיצרו בינארי של Java //:j עם תלות של C++ //:c, יהיה מיותר לכלול את הערך של --javacopt בהגדרה של //:c כי שינוי של --javacopt יפרוק את הערך של C++ שלא לצורך.
שאילתה מוגדרת (שאילתה)
כלי שאילתות שמבצע שאילתות על יעדים מוגדרים (לאחר השלמת שלב הניתוח). פירוש הדבר הוא שselect() והדגמת build (כגון
--platforms) יבואו לידי ביטוי באופן מדויק בתוצאות.
לעיון גם ב: מסמכי תיעוד של שאילתות
יעד מוגדר
התוצאה של הערכת יעד באמצעות הגדרה. שלב הניתוח יוצר את השילוב על ידי שילוב האפשרויות של Build עם היעדים שצריך ליצור.
לדוגמה, אם המאפיין //:foo יוצר עבור שתי ארכיטקטורה שונות באותו מבנה, קיימים לו שני יעדים מוגדרים: <//:foo, x86> ו-<//:foo, arm>.
נכונות
גרסת build נכונה כאשר הפלט שלה משקף באופן אמין את מצב הקלט החלופי. כדי להשיג את גרסאות ה-build הנכונות, בבז"ל שואפים להיות הרמטיים, מופקים ומגדירים את הניתוח והביצוע של פעולות.
תלות
קצה מכוון בין שני יעדים. ליעד //:foo יש תלויות ביעד ביעד //:bar אם ערכי המאפיינים של //:foo' כוללים הפניה ל-//:bar. ל-//:foo יש תלויות פעולה בתאריך //:bar אם פעולה מסוימת ב-//:foo תלויה ברכיב קלט שנוצר על-ידי פעולה ב-//:bar.
שקופה
מבנה נתונים לאיסוף נתונים על יחסי תלות חולפים. בוצעה אופטימיזציה כך שהמיזוג של רשומות העבודה מייעל את הזמן והשטח כי בדרך כלל יש הרבה רשומות קטנות (מאות אלפי קבצים). הטמעה לצורך התייחסות חוזרת למאגרים אחרים מסיבות של יעילות מקום. הטמעות של אפליקציות לא יכולות ליצור ציטוטים הפלה רחבה נקרא גם קבוצות מקוננות בהטמעה הפנימית של Bazel'.
לעיון גם ב: מסמכי התיעוד של ההדגמה
מטמון אחסון
חנות blob בדיסק מקומי לפיצ'ר של שמירה במטמון במטמון. אפשר להשתמש בו ביחד עם חנות blob מרוחקת בפועל.
דיסקברי
ספרייה לקריאה בלבד שמכילה קבצים ש-Bazel שולף מהאינטרנט באמצעות כללי מאגר. הפעלת גרסאות build ללא חיבור לאינטרנט.
ביצוע דינמי
אסטרטגיית ביצוע שמתבססת על הפעלה מקומית מקומית ומרוחקת על סמך מגוון אמצעים המבוססים על היוריסטיקה. השיטה משתמשת בתוצאות הביצוע של השיטה המהירה והמוצלחת יותר. יש פעולות שמתבצעות מהר יותר באופן מקומי (לדוגמה, קישור) ופעולות אחרות מתבצעות מהר יותר (לדוגמה, אוסף דומה במיוחד). אסטרטגיית הטמעה דינמית יכולה לספק את זמני ה-build הטובים והנקיים ביותר.
שלב ביצוע
השלב השלישי של ה-build. מבצע את הפעולות בתרשים הפעולות שנוצר במהלך שלב הניתוח. הפעולות האלה מפעילות קובצי הפעלה (מהדרים, סקריפטים) לקריאה וכתיבה של פריטי מידע מלאכותיים. אסטרטגיות פריסה קובעות איך הפעולות האלה מתבצעות: בחנות מקומית, מרחוק, דינמית, בארגז חול, בעגינה וכן הלאה.
שורש הביצוע
ספרייה בבסיס הפלט בסביבת העבודה, שבה פעולות מקומיות מתבצעות בבנייה שלא בארגז חול. תוכני הספרייה הם בעיקר סמל סימולטני של פריטי מידע בתהליך פיתוח מסביבת העבודה. הרמה הבסיסית (root) כוללת גם קישורים סימבוליים למאגרים חיצוניים בתור קלט אחר וספרייה bazel-out לאחסון פלטים. מתבצעת הכנה במהלך שלב הטעינה על ידי יצירה של יער קישור סימולטני של הספריות שמייצגות את סגירת החבילות התלויות שבהן ה-build תלוי. נגיש באמצעות bazel info
execution_root בשורת הפקודה.
קובץ
עיינו בחפצים.
הרמוניה
מבנה הוא "הרמיזה" אם אין השפעות חיצוניות על הפעולה שלו ועל בדיקתו, כדי להבטיח שהתוצאות הן דטרמיניסטיות ונכונות. לדוגמה, גרסאות build להרמטיות מונעות בדרך כלל גישה לרשת, מגבילות גישה לקלט מוצהר, משתמשות בחותמות זמן קבועות ובאזורי זמן מוגבלים, מגבילות גישה למשתני סביבה ומשתמשים בזרעים קבועים למחוללי מספרים אקראיים
גרסת build מצטברת
גרסאות build מצטברות עושות שימוש חוזר בתוצאות של גרסאות build קודמות, כדי להפחית את זמן ה-build ואת השימוש במשאבים. בדיקה של תלות ושמירה במטמון נועדו להשיג תוצאות נכונות מסוג זה. מבנה מצטבר הוא ההיפך מבניין נקי.
תווית
המזהה של יעד. תווית בפורמט מלא, כמו //path/to/package:target, מורכבת מ-// כדי לסמן את ספריית הבסיס של סביבת העבודה, path/to/package כספרייה שמכילה את BUILD
הקובץ שמצהיר על היעד, ו-:target בתור שם היעד שמוצהר בקובץ BUILD המדובר. יכול להיות שהקידומת תהיה @my_repository//<..>
כדי לציין שהיעד מוצהר ב ]מאגר
חיצוני] בשם my_repository.
השלב בטעינה
השלב הראשון של build שבו Analytics מנתח את WORKSPACE, את BUILD ואת .bzl הקבצים כדי ליצור חבילות. בשלב זה מתבצעת הערכה של פונקציות מאקרו ופונקציות מסוימות, כמו glob(). השילוב בין השלב השני של ה-build, שלב הניתוח, ליצירת תרשים יעד.
Macro
מנגנון לחיבור של הצהרות יעד כלליות יחד תחת פונקציית Starlark יחידה. מאפשר שימוש חוזר בדפוסי הצהרות של כללים נפוצים ב-BUILD קבצים. הורחבה להצהרות היעד של הכלל הבסיסי
בשלב הטעינה.
מידע נוסף: מסמכי מאקרו
מחזור
מחרוזת קצרה וקריאה אנושית שנבחרה על ידי מחבר הכלל, כדי להבין במהירות מה פעולה בכלל מתבצעת. השימוש בזכרונות יכול לשמש כמזהים לבחירת אסטרטגיית פריסה. כמה דוגמאות לפעולות פעולה הן Javac מכללי Java, CppCompile מכללי C++ ו-AndroidManifestMerger מכללי Android.
כללים מותאמים
כללים מובנים ב-Bazel ומוטמעים ב-Java. כללים כאלה מופיעים ב-.bzl קבצים כפונקציות במודול המקורי (לדוגמה, native.cc_library או native.java_library). כללים שמוגדרים על ידי המשתמש ( שלא מותאמים) נוצרים באמצעות Starlark.
בסיס היציאה
ספרייה ספציפית ל-Workspace לאחסון קובצי פלט של Bazel. משמש להפרדת פלטים מעץ המקור של סביבת העבודה. נמצאים בשורש המשתמש של הפלט.
קבוצות פלט
קבוצה של קבצים שצפויים להיבנות כש-Bazel מסיימת ליצור יעד. הכללים שמים את הפלט הרגיל שלהם ב "ברירת המחדל של קבוצת הפלט"
(למשל קובץ .jar של java_library, .a ו-.so עבור יעדים
cc_library). קבוצת הפלט המוגדרת כברירת מחדל היא קבוצת הפלט שהקריאייטיבים שלה נוצרים כשנשלחת בקשה ליעד בשורת הפקודה.
בכללים אפשר להגדיר קבוצות נוספות של פלט שניתן לציין במפורש בBUILD קבצים (כלל filegroup) או בשורת הפקודה
(סימון --output_groups).
שורש משתמש בפלט
ספרייה ספציפית למשתמש לשמירת התהליכים של Bazel'. שם הספרייה נגזר משם המשתמש של המערכת. מונע התנגשויות של קובצי פלט אם מספר משתמשים בונים את אותו הפרויקט במערכת בו-זמנית. מכיל ספריות משנה שתואמות לפלט של סביבות עבודה נפרדות, שנקראות גם בסיסי פלט.
חבילה
קבוצת היעדים שהוגדרו באמצעות קובץ BUILD. שם חבילה הוא נתיב של קובץ BUILD ביחס לבסיס של סביבת עבודה. חבילה יכולה להכיל חבילות משנה או ספריות משנה שמכילות BUILD קבצים, וכך ליצור היררכיית חבילות.
קבוצת חבילות
יעד שמייצג קבוצה של חבילות. בדרך כלל משתמשים בו
בערכי המאפיינים של visibility.
פלטפורמה
סוג &&סוג מכונה; מעורב בגרסת build. הפלטפורמה כוללת את המכונה Bazel פועלת (הפלטפורמה "host" Platform), את הכלים לבניית מחשבים הפועלים במסגרת ("exec" Platforms), והיעדים של המחשבים מוגדרים עבור ("target Platform").
ספק
סכימה המתארת יחידת מידע שצריך לעבור בין יעדי כללים לאורך קשרי תלות. בדרך כלל הוא מכיל מידע כמו אפשרויות הידור, קובצי מקור או קובצי פלט ובניית מטא-נתונים. בדרך כלל משתמשים בו יחד עם מאגרים כדי לאחסן ביעילות נתונים חולפים. דוגמה לספק מובנה הוא DefaultInfo.
לעיון גם בסעיפים הבאים: מסמכי התיעוד של הספק
שאילתה (קונספט)
תהליך הניתוח של תרשים בנייה כדי להבין את המאפיינים והמבני תלות של יעד. Bazel תומכת בשלוש וריאציות: query, cquery ו-aquery.
שאילתה (Command)
כלי שאילתה שפועל מעל build של #טעינה תרשים יעדים. התהליך הזה מהיר יחסית, אבל לא ניתן לנתח את ההשפעות של select(), על יצירת סימונים, על
חפצים או על פיתוח פעולות.
לעיון גם ב: הדרכה לביצוע, הפניה לשאילתה
מטמון מאגר
מטמון משותף עם תוכן ומתאים לתוכן ש-Bazel הורידו, המיועד לשיתוף בסביבות עבודה. מאפשר גרסאות build אופליין אחרי ההורדה הראשונית. לרוב משמשת לשמירה במטמון של קבצים שהורדו באמצעות כללי מאגר כמו http_archive וממשקי API של מאגרי נתונים כמו repository_ctx.download. הקבצים נשמרים במטמון רק אם מציינים את סכומי ההמחאה מסוג SHA-256 להורדה.
ייצור מחדש
המאפיין של build או בדיקה של קבוצת קלט או תשתיות יפיק תמיד את אותה קבוצת פלט בכל פעם, ללא קשר לזמן, לשיטה או לסביבה. שימו לב שהמצב הזה לא בהכרח מרמז על כך שהפלט נכון או את הפלט הרצוי.
הכלל
סכימה להגדרת יעדי כללים בקובץ BUILD, למשל
cc_library. מנקודת המבט של מחבר/ת קבצים ב-BUILD, כלל מורכב
ממאפיינים ולוגיקת תיבה שחורה. הלוגיקה מורה לטירגוט לפי הכלל איך ליצור פריטי פלט ולהעביר מידע ליעדי כללים אחרים. מנקודת המבט של מחברים .bzl, כללים הם הדרך העיקרית להרחיב את Bazel לתמיכה בשפות תכנות ובסביבות חדשות.
בתהליך היצירה של הכללים יופקו הכללים בשלב הטעינה. בכלל ניתוח הנתונים, יעדים מפרטים מידע לגבי יחסי התלות שלהם ב-downstream בצורה של ספקים, ורושמים פעולות שמתארות איך ליצור את הפלט שלהם. הפעולות האלה מבוצעות בשלב הביצוע.
לעיון גם ב: מסמכי תיעוד של כללים
יעד של כלל
יעד שהוא מופע של כלל. הניגודיות של הקבצים היא של יעדי הקבצים ושל קבוצות החבילות. חשוב להבדיל בין כללים לבין כלל.
קובצי Runrun
התלויות בזמן הריצה של יעד הפעלה. ברוב המקרים, קובץ ההפעלה הוא הפלט שניתן להפעלה של כלל הבדיקה, וקובצי הריצה הם תלויי נתונים בזמן הריצה של הבדיקה. לפני ההפעלה של קובץ ההפעלה (במהלך בדיקת הבסיס), בזל מכין את עץ הרצפים לצד קובץ ההפעלה לבדיקה, בהתאם למבנה ספריית המקור שלו.
מידע נוסף: תיעוד של Runfiles
ארגז חול
שיטה לבידוד פעולהפועלת. המגבלה היא שורש פעולה פעולות מוגבל. כך אפשר לוודא שהיא לא קוראת קלט לא מוצהר או כותבת פלט שלא הוצהר. ארגז החול משפר משמעותית אתהרמוטי, אך בדרך כלל הוא כרוך בעלויות ביצועים ומצריך תמיכה ממערכת ההפעלה. עלות הביצועים תלויה בפלטפורמה. ב-Linux זה לא משמעותי, אבל ב-macOS, אי אפשר להשתמש בארגז החול.
מסגרת עילית
Skyframe היא מסגרת ההערכה המקבילה, הפונקציונלית והמצטברת של Bazel.
הטבעה
תכונה להטמעת מידע נוסף בתוך פריטי מלאכת יד ב-Bazel. לדוגמה, תוכלו להשתמש בנתונים האלה לבקרת מקור, לבנות זמן ולפרטים נוספים של סביבת העבודה או הסביבה, למשל עבור גרסאות build.
הפעלה באמצעות התכונה --workspace_status_command והכללים שתומכים במאפיין החותמת.
סטארלרק
שפת התוסף לכתיבת כללים ופקודות מאקרו. קבוצת משנה מוגבלת של Python (תחבירית ודקדוקית) שמטרתה להגדרת התצורה ולשפר את הביצועים. משתמש בסיומת .bzl
קובץ. BUILD קבצים משתמשים בגרסה מוגבלת יותר של Starlark (כמו הגדרות הפונקציות של def), שנקראה בעבר Skylark.
ראו גם: תיעוד של Starstark
התרעות הפעלה
קבוצת הסימונים שצוינה בין bazel לבין הפקודה, לדוגמה, ה-bazel --host_jvm_debug. הסימונים האלה משנים את התצורה של שרת Bazel, כך שכל שינוי בהתרעות ההפעלה גורם להפעלה מחדש של השרת. התרעות על סטארט-אפ הן לא ספציפיות.
לטירגוט
אובייקט שמוגדר בקובץ BUILD ומזוהה באמצעות תווית. יעדים מייצגים את היחידות הניתנות לבנייה של סביבת עבודה מנקודת המבט של משתמש הקצה.
יעד שמוצהר באמצעות יצירה של כלל נקרא יעד של כלל. בהתאם לכלל, ייתכן שהיעדים האלה ניתנים להפעלה (כמו cc_binary) או ניתנים לבדיקה (למשל cc_test). יעדי כללים תלויים בדרך כלל ביעדים אחרים באמצעות המאפיינים שלהם (למשל deps). התלויות האלה הן הבסיס של תרשים היעד.
פרט ליעדי כללים, יש גם יעדים לקבצים ויעדי קבוצות חבילות. יעדים של קבצים תואמים לפריטי חפצים שיש אליהם הפניה בקובץ BUILD. בכל מקרה מיוחד, קובץ BUILD של חבילה כלשהי נחשב תמיד ליעד של קובץ מקור בחבילה זו.
יעדים מתגלים במהלך שלב הטעינה. במהלך שלב הניתוח, היעדים משויכים להגדרות של Build כדי ליצור יעדים מוגדרים.
תרשים יעד
תרשים זיכרון של יעדים והתלות שלהם. הופק במהלך שלב הטעינה ומשמש כקלט לשלב הניתוח.
דפוס יעד
דרך לציין קבוצה של יעדים בשורת הפקודה. הדפוסים הנפוצים הם :all (כל יעדי הכלל), :* (כל הכללים וכל יעדי הקבצים), ... (חבילה נוכחית וכל חבילות המשנה שוב ושוב). ניתן להשתמש בשילוב של //...:*. לדוגמה, כל היעדים והקבצים שמוגדרים בכל החבילות נמצאים בבסיס הסביבת העבודה.
בדיקות
הכלל יעדים נוצר מכללי הבדיקה, ולכן הוא מכיל קובץ הפעלה להפעלה. קוד חזרה מאפס בסיום ההפעלה מציין שהצלחת הבדיקה. החוזה המדויק בין Bazel לבין בדיקות (כגון משתני סביבת בדיקה, שיטות לאיסוף תוצאות בדיקה) מצוין באנציקלופדיה לבדיקה.
ארגז כלים
קבוצה של כלים ליצירת פלטים עבור שפה. בדרך כלל, כלי עבודה כולל מהדרים, מקשרים, מתורגמנות ו/או לינטרים. גם כלי הכלים עשוי להשתנות בהתאם לפלטפורמה, כלומר, הרכיבים של מהדר מיקסרים של Unix עשויים להיות שונים בווריאציה של Windows, למרות שכלי הכלים מיועד לאותה שפה. בחירת ערכת הכלים הנכונה לפלטפורמה מכונה 'רזולוציית כלים'.
יעד ברמה העליונה
יעד ברמה build הוא ברמה העליונה אם הוא התבקש בשורת הפקודה של Bazel. לדוגמה, אם המאפיין //:foo תלוי ב-//:bar, והפרמטר bazel build //:foo נקרא, אז עבור build זה, //:foo נמצא ברמה העליונה ו-//:bar לא נמצא ברמה העליונה, למרות שיש לבנות את שני היעדים. הבדל חשוב בין יעדים ברמה העליונה לבין יעדים שאינם ברמה העליונה, הוא שסימונים עם פקודה שמוגדרים בשורת הפקודה של Bazel (או באמצעות .bazelrc) יגדירו את ההגדרה יעדים עבור יעדים ברמה עליונה. עם זאת, ניתן לשנות את המעבר של יעדים שאינם ברמה העליונה.
מעבר
מיפוי של הגדרה משתנה ממצב אחד לערך אחר. המדיניות מאפשרת ליעדים בתרשים הבנייה לקבוע הגדרות שונות, גם אם הן נוצרו מאותו כלל. שימושים נפוצים במעברים הם מעברים מסוג פיצול, שבהם חלקים מסוימים בתרשים היעד מחולקים לפי תצורות נפרדות לכל מזלג. לדוגמה, אפשר ליצור APK של Android עם קבצים בינאריים מקומיים בהידור עבור ARM ו-x86, באמצעות מעברים מפוצלים בגרסה build אחת.
מידע נוסף: מעברים שהוגדרו על ידי המשתמש
פריט מידע שנוצר בתהליך פיתוח (Artifact)
פרטי פריט שמייצג אוסף של קבצים. הקבצים האלה הם לא בעצמם, ולכן פעולה שפועלת בהם חייבת לרשום את פריט המידע שנוצר בתהליך הפיתוח (Artifact) כקלט או כפלט.
חשיפה
אחד משני מנגנונים שמונעים מתלויות לא רצויות במערכת Build:
יעד החשיפה שלפיו אפשר לקבוע אם יעד מסוים עשוי להיות תלוי ביעד; ויכולת לראות את הטעינה כדי לקבוע אם קובץ BUILD
או .bzl ייטען עבור קובץ .bzl נתון. ללא הקשר, בדרך כלל המונח
"חשיפה" מתייחס לחשיפת היעד.
לעיון גם ב:מסמכי תיעוד של החשיפה
סביבת עבודה
ספרייה שמכילה קובץ WORKSPACE וקוד מקור לתוכנה שרוצים לבנות. התוויות שמתחילות ב-// הן יחסיות לספרייה של סביבת העבודה.
קובץ WORKSPACE
הגדרת ספרייה כסביבת עבודה. הקובץ יכול להיות ריק, אבל הוא בדרך כלל מכיל הצהרות ממאגר חיצוני כדי לאחזר יחסי תלות נוספים מהרשת או ממערכת הקבצים המקומית.