BazelCon 2022 מגיע בין 16 ל-17 בנובמבר לניו יורק באינטרנט.
הירשמו עוד היום!

פקודות ואפשרויות

קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

הדף הזה מתאר את האפשרויות הזמינות עם פקודות Bazel שונות, כגון bazel build, bazel run ו-bazel test. הדף הזה נלווה לרשימת הפקודות של Bazel ב-Build with Bazel.

תחביר יעד

פקודות מסוימות, כגון build או test, יכולות לפעול ברשימת יעדים. הם משתמשים בתחביר גמיש יותר מתוויות, המתועדות בציון יעדים לבנייה.

אפשרויות

הקטעים הבאים מתארים את האפשרויות הזמינות במהלך ה-build. כאשר משתמשים ב---long בפקודת עזרה, הודעות העזרה אונליין מספקות מידע מסכם לגבי המשמעות, הסוג וערך ברירת המחדל לכל אפשרות.

את רוב האפשרויות ניתן לציין פעם אחת בלבד. אם מציינים מספר פעמים, המופע האחרון מנצח. האפשרויות שניתן לציין מספר רב של פעמים מזוהות עם עזרה מקוונת עם הטקסט 'ניתן להשתמש מספר פעמים'.

מיקום חבילה

--package_path

אפשרות זו מציינת את קבוצת הספריות שמחפשים בקובץ BUILD עבור חבילה נתונה.

Bazel מוצאת את החבילות שלה על ידי חיפוש בנתיב החבילה. זוהי רשימה מופרדת בנקודתיים של ספריות בזל, שכל אחת מהן היא הבסיס לעץ מקור חלקי.

כדי לציין נתיב חבילה מותאם אישית באמצעות האפשרות --package_path:

  % bazel build --package_path %workspace%:/some/other/root

ניתן לציין רכיבים של נתיב חבילה בשלושה פורמטים:

  1. אם התו הראשון הוא /, הנתיב הוא אבסולוטי.
  2. אם הנתיב מתחיל ב-%workspace%, הוא מנותב באופן יחסי לספריית הלוח הצמוד ביותר. למשל, אם ספריית העבודה שלך היא /home/bob/clients/bob_client/bazel/foo, המחרוזת %workspace% בנתיב הנתיב מתרחבת ל-/home/bob/clients/bob_client/bazel.
  3. כל פרט אחר תפוס ביחס לספריית העבודה. לרוב זו לא המטרה, והיא עשויה להתנהג באופן בלתי צפוי אם תשתמש ב-Bazel מספריות שמתחת לסביבת העבודה של באז. לדוגמה, אם נעשה שימוש ברכיב הנתיב של החבילה ., ולאחר מכן בתקליטור לספרייה /home/bob/clients/bob_client/bazel/foo, החבילות יפתרו מהספרייה /home/bob/clients/bob_client/bazel/foo הנתונים.

אם נעשה שימוש בנתיב חבילה שאינו ברירת מחדל, יש לציין אותו בקובץ תצורת Bazel לנוחותך.

Bazel לא דורשת חבילות בספרייה הנוכחית, כך שניתן ליצור build מסביבת עבודה ריקה אם כל החבילות הדרושות נמצאות במקום אחר בנתיב האריזה.

דוגמה: מבנה מלקוח ריק

  % mkdir -p foo/bazel
  % cd foo/bazel
  % touch WORKSPACE
  % bazel build --package_path /some/other/path //foo

--deleted_packages

אפשרות זו מציינת רשימת חבילות המופרדות באמצעות פסיקים שכדאי לשקול למחוק אותן ב-Bazel ולא לנסות לטעון מספרייה כלשהי בנתיב החבילות. אפשר להשתמש באפשרות הזו כדי לדמות מחיקה של חבילות בלי למחוק אותן בפועל.

שגיאה בבדיקה

האפשרויות האלה שולטות בבדיקת השגיאות ו/או האזהרות של Bazel.

--[no]check_visibility

אם אפשרות זו מוגדרת כ'שקר', בדיקות חשיפה יורדות בדרגה לאזהרות. ערך ברירת המחדל של אפשרות זו הוא True, כך שכברירת מחדל, בדיקת החשיפה מתבצעת.

--output_filter=regex

האפשרות --output_filter תציג אזהרות על הידור ואיסוף רק עבור יעדים התואמים לביטוי הרגולרי. אם יעד מסוים אינו תואם את הביטוי הרגולרי הנתון והביצוע שלו מבוצע, הפלט הרגיל והשגיאה הרגילה שלו נזרקים.

הנה כמה ערכים אופייניים לאפשרות זו:

`--Output_filter='^//(first/project|seconds/project):'` הצג את הפלט של החבילות שצוינו.
`--Output_filter='^(((!(first/bad_project|second/bad_project):).*$'` אין להציג פלט עבור החבילות שצוינו.
`--Output_filter=` הצגת הכול.
`--Output_filter=DONT_MATCH_ANYTHE` לא להציג דבר.

דגלים לכלי עבודה

האפשרויות האלה קובעות אילו אפשרויות יועברו ב-Bazel לכלים אחרים.

--copt=cc-option

אפשרות זו קובעת ארגומנט שיועבר אל המהדר. הארגומנט יועבר מהדר בכל פעם שהוא מופעל לעיבוד מראש, הידור ו/או הרכבה של קוד C, C++ או הרכבה. הנתונים לא יועברו בעת הקישור.

ניתן להשתמש באפשרות הזו מספר פעמים. למשל:

  % bazel build --copt="-g0" --copt="-fpic" //foo

ירכיב את הספרייה foo ללא טבלאות ניפוי באגים, ויפיק קוד שאינו תלוי מיקום.

--host_copt=cc-option

אפשרות זו קובעת ארגומנט שיועבר מהדר עבור קובצי המקור המורכבים בתצורת המארח. פעולה זו דומה לאפשרות --copt, אך חלה רק על ההגדרה של המארח.

--host_conlyopt=cc-option

אפשרות זו לוקחת ארגומנט שמועבר אל המהדר עבור קובצי מקור C המורכבים מתצורת המארח. פעולה זו דומה לאפשרות --conlyopt, אך חלה רק על תצורת המארח.

--host_cxxopt=cc-option

אפשרות זו קובעת ארגומנט שיועבר מהדר עבור קובצי המקור מסוג C++ המורכבים בתצורת המארח. פעולה זו דומה לאפשרות --cxxopt, אך חלה רק על ההגדרה של המארח.

--host_linkopt=linker-option

אפשרות זו משתמשת בארגומנט שיועבר לקישור לקובצי מקור שנוצרים בתצורת המארח. פעולה זו דומה לאפשרות --linkopt, אך חלה רק על תצורת המארח.

--conlyopt=cc-option

אפשרות זו קובעת ארגומנט שיועבר למהדר בעת הידור קובצי המקור של C.

האפשרות הזו דומה ל--copt, אבל חלה רק על קומפילציה של C, ולא על קומפילציה של C++ או על קישור. כך ניתן להעביר אפשרויות ספציפיות ל-C (כגון -Wno-pointer-sign) באמצעות --conlyopt.

--cxxopt=cc-option

אפשרות זו קובעת ארגומנט שיועבר מהדר בעת הידור קובצי המקור מסוג C++.

האפשרות הזו דומה ל--copt, אבל חלה רק על קומפילציה של C++ , ולא על קומפילציה של C או על קישורים. כך ניתן להעביר אפשרויות ספציפיות ל-C++ (כמו -fpermissive או -fno-implicit-templates) באמצעות --cxxopt.

למשל:

  % bazel build --cxxopt="-fpermissive" --cxxopt="-Wno-error" //foo/cruddy_code

--linkopt=linker-option

אפשרות זו קובעת ארגומנט שמועבר אל המהדר בעת הקישור.

היא דומה ל--copt, אבל חלה רק על קישורים, ולא על הידור. כך ניתן לעבור אפשרויות של מהדר שרק הגיוניות בזמן הקישור (כמו -lssp או -Wl,--wrap,abort) באמצעות --linkopt. למשל:

  % bazel build --copt="-fmudflap" --linkopt="-lmudflap" //foo/buggy_code

כללי build יכולים גם לציין אפשרויות קישור במאפיינים שלהם. ההגדרות של האפשרות הזו תמיד מקבלות עדיפות. מידע נוסף זמין בכתובת cc_library.linkopts.

--strip (always|never|sometimes)

אפשרות זו קובעת אם Bazel תסיר מידע על ניפוי באגים מכל הקבצים הבינאריים והספריות המשותפות, על ידי הפעלת הקישור עם האפשרות -Wl,--strip-debug. --strip=always פירושו תמיד להסיר מידע על תוצאות ניפוי באגים. המשמעות של --strip=never היא לעולם לא להסיר מידע על ניפוי באגים. ערך ברירת המחדל של --strip=sometimes פירושו רצועה אם --compilation_mode הוא fastbuild.

  % bazel build --strip=always //foo:bar

הידור של היעד תוך הסרת פרטי ניפוי באגים מכל הנתונים הבינאריים שנוצרו.

האפשרות --strip של Bazel מתאימה לאפשרות --strip-debug של : היא רק מסירה מידע על ניפוי באגים. אם מסיבה כלשהי ברצונך להסיר את כל הסמלים, ולא רק סמלי ניפוי באגים, יהיה עליך להשתמש באפשרות --strip-all של ld, ניתן לעשות זאת על ידי העברת --linkopt=-Wl,--strip-all אל Bazel. כמו כן, חשוב לדעת שההגדרה של --strip Bazel תבטל את ההגדרה של --linkopt=-Wl,--strip-all, לכן יש להגדיר רק הגדרה אחת מבין השתיים.

אם יצרת בינארי אחד בלבד וברצונך להסיר את כל הסמלים, אפשר גם להעביר את --stripopt=--strip-all ולבנות את גרסת //foo:bar.stripped של היעד באופן מפורש. כפי שתואר בקטע --stripopt, החלת פעולה על רצועה אחרי שמתבצע קישור של הקובץ הבינארי הסופי, במקום להסיר את כל הפעולות בקישור של ה-build.

--stripopt=strip-option

זוהי אפשרות נוספת למעבר לפקודה strip כשיוצרים בינארי של *.stripped. ברירת המחדל היא -S -p. ניתן להשתמש באפשרות הזו מספר פעמים.

--fdo_instrument=profile-output-dir

האפשרות --fdo_instrument מאפשרת ליצור פלט פרופיל (אופטימיזציה מכוונת משוב) כאשר מופעל הבינארי C/C++. עבור GCC, הארגומנט שסופק משמש כתחילית ספרייה עבור עץ של ספריית קבצים לכל אובייקט .gc .שמכיל מידע על הפרופיל של כל קובץ o.

לאחר יצירת עץ נתוני הפרופיל, עץ הפרופיל צריך להיות דחוס בקובץ zip. יש לספק אותו באפשרות --fdo_optimize=profile-zip Bazel כדי לאפשר את האיסוף של אופטימיזציית FDO.

עבור מהדר LLVM הארגומנט הוא גם הספרייה שבה קובצי ה-LL . בגין נתונים של פרופיל LLVM מושמטים. לדוגמה: --fdo_instrument=/path/to/rawprof/dir/.

לא ניתן להשתמש באפשרויות --fdo_instrument ו---fdo_optimize בו-זמנית.

--fdo_optimize=profile-zip

האפשרות --fdo_optimize מאפשרת שימוש בפרטי פרופיל הקובץ לכל אובייקט כדי לבצע אופטימיזציות של FDO (אופטימיזציה מכוונת משוב) בזמן ההידור. עבור GCC, הארגומנט הנתון הוא קובץ ה-ZIP שמכיל את עץ הקובץ שנוצר בעבר, קובצי .gcda שמכילים פרטי פרופיל עבור כל קובץ .o

לחלופין, הארגומנט שסופק יכול להצביע על פרופיל אוטומטי שזוהה על ידי הסיומת afdo.

עבור מהדר LLVM הארגומנט שצוין צריך להפנות אל קובץ פלט הפרופיל LLVM שנוסף לאינדקס על ידי כלי llvm-profdata, וצריכה להיות לו סיומת .profdata.

לא ניתן להשתמש באפשרויות --fdo_instrument ו---fdo_optimize בו-זמנית.

--[no]output_symbol_counts

אם התכונה מופעלת, כל קישור המופעל על ידי זהב בינארי של C++ מאפשר הפעלה של קובץ ספירות סימבולים (באמצעות האפשרות '--print-symbol-counts זהב'). עבור כל קלט מקשר, הקובץ מתעד את מספר הסמלים שהוגדרו ואת מספר הסמלים שבהם נעשה שימוש בקובץ הבינארי. ניתן להשתמש במידע הזה כדי לעקוב אחר יחסי תלות מיותרים של קישורים. קובץ ספירת הסמלים כתוב לנתיב הפלט הבינארי עם השם [targetname].sc.

האפשרות הזו מושבתת כברירת מחדל.

--java_language_version=version

אפשרות זו מציינת את הגרסה של מקורות Java. למשל:

  % bazel build --java_language_version=8 java/com/example/common/foo:all

סוגי הידור ומאפשרים רק ליצור דגמים התואמים למפרט Java 8. ערך ברירת המחדל הוא 11. --> ערכים אפשריים הם: 8, 9, 10, 11, 14 ו-15. ניתן גם להאריך אותם על ידי רישום סוגי כלים מותאמים אישית ב-Java באמצעות default_java_toolchain.

--tool_java_language_version=version

גרסת השפה של Java המשמשת לבניית כלים המבוצעים במהלך build. ערך ברירת המחדל הוא 11.

--java_runtime_version=version

אפשרות זו מציינת את הגרסה של JVM שיש להשתמש בה כדי לבצע את הקוד ולהריץ את הבדיקות. לדוגמה:

  % bazel run --java_runtime_version=remotejdk_11 java/com/example/common/foo:java_application

מוריד את JDK 11 ממאגר מרוחק ומפעיל את אפליקציית Java באמצעותו.

ערך ברירת המחדל הוא localjdk. ערכים אפשריים הם: localjdk, localjdk_version, remotejdk_11 ו-remote_jdk17. כדי להאריך את הערכים, אפשר לרשום JVM בהתאמה אישית באמצעות כללי המאגר local_java_repository או remote_java_repostory.

--tool_java_runtime_version=version

גרסת JVM המשמשת להפעלת כלים הדרושים לדגם. ערך ברירת המחדל הוא remotejdk_11.

--jvmopt=jvm-option

אפשרות זו מאפשרת להעביר ארגומנטים של אפשרויות אל VM של Java. ניתן להשתמש בו בארגומנט אחד גדול, או מספר פעמים בארגומנטים בודדים. למשל:

  % bazel build --jvmopt="-server -Xms256m" java/com/example/common/foo:all

ישתמש ב-VM של השרת כדי להפעיל את כל הקבצים הבינאריים של Java ולהגדיר את גודל הערימה של ההפעלה עבור ה-VM ל-256MB.

--javacopt=javac-option

אפשרות זו מאפשרת העברת ארגומנטים של אפשרויות ל-Javac. ניתן להשתמש בו בארגומנט אחד גדול, או מספר פעמים בארגומנטים בודדים. למשל:

  % bazel build --javacopt="-g:source,lines" //myprojects:prog

יבנה מחדש את Java_binary עם מידע על ניפוי הבאגים המוגדר כברירת מחדל ב-Javac (במקום ברירת המחדל של bazel).

האפשרות מועברת ל-Javac לאחר אפשרויות ברירת המחדל המובנות של Bazel עבור Javac ולפני האפשרויות לכל כלל. המפרט האחרון של כל אפשרות לזכייה ב-Javac. אפשרויות ברירת המחדל של Javac הן:

  -source 8 -target 8 -encoding UTF-8
-extra_checks[:(off|on)]

האפשרות הזו ב-Javac מאפשרת בדיקות תקינות נוספות. בעיות שנמצאו יוצגו כשגיאות. ניתן להשתמש ב--extra_checks או ב--extra_checks:on כדי לאלץ את הפעלת הבדיקות. -extra_checks:off משביתה לחלוטין את הניתוח. אם לא מציינים את האפשרות הזו, המערכת משתמשת בהתנהגות ברירת המחדל.

--strict_java_deps (default|strict|off|warn|error)

האפשרות הזו קובעת אם מערכת Javac בודקת בעיות של תלות ישירה. יעדי Java חייבים להצהיר במפורש על כל היעדים המשמשים ישירות כתלות של תלות. הסימון הזה מורה ל-Javac לזהות את הכדים שנמצאים בשימוש לבדיקת סוג של כל קובץ Java, ולהזהיר/שגיאה אם הם לא הפלט של תלות ישירה של היעד הנוכחי.

  • off פירושו שהבדיקה מושבתת.
  • המשמעות של warn היא ש-Javac יפיק אזהרות Java סטנדרטיות מסוג [strict] עבור כל תלות ישירה חסרה.
  • default, strict ו-error כל יחידות ה-Javac יגרמו ליצירת שגיאות במקום לאזהרות, וכתוצאה מכך ייכשל היצירה של היעד הקיים אם יתגלו תלות ישירה חסרה. זוהי גם התנהגות ברירת המחדל כשהדגל אינו מצוין.

בניית סמנטי

אפשרויות אלה משפיעות על פקודות build ו/או על תוכן קובץ הפלט.

--compilation_mode (fastbuild|opt|dbg) (ג)

האפשרות --compilation_mode (לעתים קרובות היא מקוצרת ל--c, במיוחד -c opt) מקבלת ארגומנט של fastbuild, dbg או opt ומשפיעה על מגוון C/C++ ליצירת קוד, כגון רמת האופטימיזציה והשלמות של טבלאות ניפוי באגים. Bazel משתמשת בספריית פלט שונה לכל מצב אוסף, כך שניתן לעבור בין מצבים ללא צורך בבנייה מחדש מחדש בכל פעם.

  • המשמעות של fastbuild היא ליצור כמה שיותר מהר: ליצור מידע מינימלי על ניפוי באגים (-gmlt -Wl,-S), ולא לבצע אופטימיזציה. זוהי ברירת המחדל. הערה: -DNDEBUG לא יוגדר.
  • dbg פירושו build עם ניפוי באגים (-g), כך שניתן להשתמש ב-gdb (או במתקן באגים אחר).
  • opt פירושו לבנות עם אופטימיזציה מופעלת וassert() שיחות מושבתות (-O2 -DNDEBUG). פרטי ניפוי באגים לא יווצרו במצב opt, אלא אם תעבור גם --copt -g.

--cpu=cpu

באפשרות זו מציינים את ארכיטקטורת היעד של המעבד (CPU) שישמשה עבור ההידור של בינאריים במהלך ה-build.

--action_env=VAR=VALUE

מציינת את קבוצת המשתנים של סביבה הזמינים במהלך הביצוע של כל הפעולות. ניתן לציין משתנים לפי שם. במקרה כזה, הערך יילקח מסביבת ההפעלה, או על ידי זוג name=value שמגדיר את הערך בנפרד מסביבת ההפעלה.

ניתן לציין את הסימון --action_env מספר פעמים. אם מוקצי ערך לאותו משתנה בכמה סימונים של --action_env, ההקצאה האחרונה תנצח.

--experimental_action_listener=label

האפשרות experimental_action_listener מורה ל-Bazel להשתמש בפרטים מהכלל action_listener שצוין על ידי label כדי להוסיף extra_actions לתרשים ה-build.

--[no]experimental_extra_action_top_level_only

אם אפשרות זו מוגדרת כ-TRUE, פעולות נוספות שצוינו באמצעות אפשרות הפקודה --experimental_action_listener תוזמנו רק ליעדים ברמה העליונה.

--experimental_extra_action_filter=regex

האפשרות experimental_extra_action_filter מורה ל-Bazel לסנן את קבוצת היעדים שלפיהם נקבע לוח זמנים extra_actions.

הסימון הזה חל רק בשילוב עם הדגל --experimental_action_listener.

כברירת מחדל, כל הextra_actions בסגירות עקיפות של יעדים המבוקשים לבנייה מתוכננים להפעלה. --experimental_extra_action_filter תגביל את התזמון ל-extra_actions שבו התווית של הבעלים תתאים לביטוי הרגולרי שצוין.

הדוגמה הבאה תגביל את התזמון של extra_actions כדי שרלוונטי רק לפעולות שבהן התווית של הבעלים מכילה '/bar/':

% bazel build --experimental_action_listener=//test:al //foo/... \
  --experimental_extra_action_filter=.*/bar/.*

--host_cpu=cpu

אפשרות זו מציינת את השם של ארכיטקטורת המעבד (CPU) שצריך להשתמש בה כדי לבנות כלים של מארח.

--fat_apk_cpu=cpu[,cpu]*

יחידות העיבוד המרכזיות (CPU) לבניית ספריות C/C++ עבור deps כללים של android_binary. כללים אחרים של C/C++ אינם מושפעים. לדוגמה, אם cc_library מופיע ב-deps של כלל אחד (android_binary) ולכלל cc_binary, ה-cc_library ייבנה לפחות פעמיים: פעם אחת לכל מעבד שצוין עם --fat_apk_cpu לכלל android_binary, ופעם אחת למעבד שצוין עם --cpu לכלל cc_binary.

ברירת המחדל היא armeabi-v7a.

קובץ .so אחד נוצר וארוז ב-APK לכל CPU שצוין עם --fat_apk_cpu. השם של קובץ .so מקדים את שם הכלל android_binary ל"lib". לדוגמה, אם השם של android_binary הוא "foo", הקובץ הוא libfoo.so.

--per_file_copt=[+-]regex[,[+-]regex]...@option[,option]...

אם קובץ C++ מופיע עם תווית או נתיב של פעולה התואמים לאחד מהביטויים הרגולריים של הביטוי הרגולרי, שאינם תואמים לאף אחד מהביטויים של אי-הכללה, המערכת תבנה אותם באמצעות האפשרויות הנתונות. התאמת התווית משתמשת בצורה הקנונית של התווית (למשל, //package:label_name).

נתיב הביצוע הוא הנתיב היחסי לספרייה של סביבת העבודה, כולל שם הבסיס (כולל התוסף) של קובץ C++. הוא כולל גם קידומות התלויות בפלטפורמה.

כדי להתאים לקבצים שנוצרו (כגון פלט של כלל כללי) ב-Bazel אפשר להשתמש רק בנתיב הביצוע. במקרה הזה, הביטוי הרגולרי לא צריך להתחיל ב-'//' מפני שהוא לא תואם לנתיבי ביצוע כלשהם. ניתן להשתמש בשמות חבילות כך: --per_file_copt=base/.*\.pb\.cc@-g0. פעולה זו מתאימה לכל קובץ .pb.cc בספרייה בשם base.

ניתן להשתמש באפשרות הזו מספר פעמים.

האפשרות מוחלת ללא קשר למצב ההידור. לדוגמה, אפשר להדר עם --compilation_mode=opt וליצור באופן סלקטיבי קבצים מסוימים עם אופטימיזציה חזקה יותר, או שהאופטימיזציה מושבתת.

אזהרה: אם קבצים מסוימים נאספים באופן סלקטיבי עם סמלים לניפוי באגים, ייתכן שהסמלים יוסרו בזמן הקישור. כדי למנוע זאת, יש להגדיר --strip=never.

תחביר: [+-]regex[,[+-]regex]...@option[,option]... כאשר regex מייצג ביטוי רגולרי שניתן להוסיף לו תחילית עם + כדי לזהות דפוסים, ועם - עד זיהוי דפוסי החרגה. option מייצג אפשרות שרירותית שמועברת אל מהדר C++. אם אפשרות מכילה ,, יש לצטט אותה כך \,. האפשרויות יכולות לכלול גם @, מפני שרק @ הראשון משמש להפרדת ביטויים רגולריים מאפשרויות.

דוגמה: --per_file_copt=//foo:.*\.cc,-//foo:file\.cc@-O0,-fprofile-arcs הוספת האפשרויות -O0 ו-fprofile-arcs לשורת הפקודה של מהדר C++ לכל .cc הקבצים. ב//foo/ מלבד file.cc.

--dynamic_mode=mode

הגדרה זו קובעת אם קבצים בינאריים של C++ יקושרו באופן דינמי, ויקיימו אינטראקציה עם המאפיין linkstatic [קישור סטטי] בכללי build.

מצבים:

  • auto: תרגום למצב תלוי-פלטפורמה; default ל-Linux ו-off לסיג'ווין.
  • default: מאפשר ל-Bazel לבחור אם לבצע קישור באופן דינמי. ניתן למצוא מידע נוסף בקישור linkstatic.
  • fully: מקשר את כל היעדים באופן דינמי. הפעולה תזרז את זמן הקישור ותפחית את הגודל של הנתונים הבינאריים שנובעים מכך.
  • off: מקשר את כל היעדים במצב סטטי ברובו. אם -static נמצא ב-linkopts, היעדים ישתנו לסטטיים באופן מלא.

--fission (yes|no|[dbg][,opt][,fastbuild])

מאפשר את האפשרות Fision, הכותבת מידע על ניפוי באגים מסוג C++ בקובצי .dwo ייעודיים במקום בקובצי .o, שאליהם הם היו עוברים בכל מקרה אחר. פעולה זו מפחיתה באופן משמעותי את גודל הקלט לקישורים ומקצרת את זמני הקישורים.

כשהאפשרות מוגדרת כ-[dbg][,opt][,fastbuild] (לדוגמה: --fission=dbg,fastbuild), האפשרות 'דגימה' מופעלת רק עבור ערכת ההידור שצוינה. זה מועיל להגדרות של bazelrc. בהגדרה של הערך yes, ההפעלה מופעלת באופן אוניברסלי. בהגדרה ל-no, Fission מושבת באופן אוניברסלי. ברירת המחדל היא no.

--force_ignore_dash_static

אם הדגל הזה מוגדר, המערכת מתעלמת מכל אחת מהאפשרויות של -static בקישורי cc_* כללים של קובצי BUILD. אפשרות זו משמשת כפתרון בעיות של מבני קשיי ++C בלבד.

--[no]force_pic

אם האפשרות מופעלת, כל אוספי C++ יוצרים קוד שאינו תלוי מיקום ("-fPIC"), קישורים מעדיפים ספריות מוכנות מראש מסוג PIC על פני ספריות שאינן בפורמט PIC, וקישורים מייצרים קובצי הפעלה שאינם תלויים במיקום ("-pie") הנתונים. ברירת המחדל מושבתת.

--android_resource_shrinking

בוחר אם לבצע כיווץ משאבים עבור כללי android_binary. קביעת ברירת המחדל עבור המאפיין shrink_resources בכללי Android_binary; לפרטים נוספים לגבי אותו כלל, יש לעיין בתיעוד שלו. מושבת כברירת מחדל.

--custom_malloc=malloc-library-target

אם מציינים, יש להשתמש תמיד בהטמעה הספציפית של Malloc על פני כל מאפייני malloc="target", כולל ביעדים שמשתמשים בברירת המחדל (ללא ציון malloc).

--crosstool_top=label

האפשרות הזו מציינת את המיקום של חבילת מהדר ה-crosstool שייעשה בה שימוש לכל הידור C++ במהלך build. Bazll תחפש במיקום הזה קובץ CROSSROOM ומשתמשת בו כדי לקבוע באופן אוטומטי הגדרות עבור --compiler.

--host_crosstool_top=label

אם לא צוין ערך, Bazel משתמשת בערך של --crosstool_top כדי להדר קוד בתצורת המארח, כגון כלים שפועלים במהלך ה-build. המטרה העיקרית של סימון זה היא להפעיל הידור.

--apple_crosstool_top=label

הכלי המשולב לשימוש בהידור של כללי C/C++ בdepsנתונים העקיפים של *objc*, ios* ו-apple*. במטרות האלה, הסימון הזה מחליף את --crosstool_top.

--android_crosstool_top=label

הכלי המשולב לשימוש בהידור של כללי C/C++ ב-deps של android_binary הכללים העקיפים. האפשרות הזו שימושית אם יש ב-build יעדים אחרים שמחייבים יצירה של בלוקאל אחר. ברירת המחדל היא להשתמש ב-crosstool שנוצר על ידי הכלל android_ndk_repository בקובץ WORKSPACE. ראו גם --fat_apk_cpu.

--compiler=version

אפשרות זו מציינת את גרסת המהדר C/C++ (כמו gcc-4.1.0) לשימוש בהידור של בינאריות במהלך ה-build. אם ברצונך לבנות עם קרוסלת מותאם אישית, עליך להשתמש בקובץ CROSSROOM במקום לציין את הדגל הזה.

--android_sdk=label

האפשרות הזו מציינת את כלי ה-SDK/פלטפורמה של Android וספריית זמן הריצה של Android שתשמש לבניית כל כלל הקשור ל-Android.

Android SDK ייבחר באופן אוטומטי אם כלל של android_sdk_repository מוגדר בקובץ WORKSPACE.

--java_toolchain=label

אפשרות זו מציינת את התווית של "Java_toolchain", המשמש להידור של קובצי מקור ב-Java.

--host_java_toolchain=label

אם לא צוין ערך, בזל משתמשת בערך של --java_toolchain כדי להדר את הקוד בתצורת המארח, למשל עבור כלים שפועלים במהלך ה-build. המטרה העיקרית של סימון זה היא להפעיל הידור.

--javabase=(label)

אפשרות זו מגדירה את התווית של התקנת Java הבסיסית לשימוש בהרצת מחרוזת, בדיקת בזל ולקובצי בינארי של Java שנבנו על ידי java_binary ו- java_test כללים. אפשרות זו מתייחסת גם לJAVABASE ולJAVA משתני"Make".

--host_javabase=label

אפשרות זו מגדירה את התווית של התקנת Java הבסיסית שתשמש בתצורת המארח, לדוגמה עבור כלים לבניית מארח כולל JavaBuilder ו-Singlejar.

פעולה זו לא בוחרת את מהדר ה-Java המשמש להידור קובצי המקור של Java. אפשר לבחור את המהדר לפי ההגדרות של האפשרות --java_toolchain.

אסטרטגיית ביצוע

האפשרויות האלה משפיעות על האופן שבו Bazel תריץ את ה-build. לא אמורה להיות להם השפעה משמעותית על קובצי הפלט שנוצרים על ידי ה-build. בדרך כלל, ההשפעה העיקרית שלהם היא על מהירות הבנייה.

--spawn_strategy=strategy

אפשרות זו קובעת היכן וכיצד יבוצעו פקודות.

  • standalone גורם לפקודות להתבצע בתור תהליכי משנה מקומיים. הערך הזה הוצא משימוש. יש להשתמש בעמודות local במקומן.
  • sandboxed גורם לפקודות להתבצע בתוך ארגז חול במחשב המקומי. באופן זה, כל קובצי הקלט, תלות הנתונים והכלים יוצגו כתלויות ישירה במאפיינים srcs, data ו-tools. Bazel מאפשר להפעיל ארגז חול מקומי כברירת מחדל, במערכות התומכות בהפעלה בארגז חול.
  • local גורם לפקודות להתבצע בתור תהליכי משנה מקומיים.
  • worker גורם לביצוע פקודות באמצעות קובץ קבוע, אם זמין.
  • docker גורם לפקודות להתבצע בתוך ארגז חול של מעגן במחשב המקומי. כדי לעשות את זה, צריך לעגן את אביזר העגינה.
  • האפליקציה remote מפעילה פקודות מרחוק. אפשרות זו זמינה רק אם מכשיר מרוחק מוגדר בנפרד.

--strategy mnemonic=strategy

האפשרות הזו קובעת איפה ואיך פקודות יבוצעו. היא מבטלת את --spawn_strategy (ואת --genrule_strategy עם זיכרון כללי) -יסוד. אפשר לראות --spawn_strategie את האסטרטגיות הנתמכות וההשפעות שלהן.

--strategy_regexp=<filter,filter,...>=<strategy>

האפשרות הזו מציינת באיזו אסטרטגיה יש להשתמש כדי להפעיל פקודות שכוללות תיאורים שתואמים לregex_filter מסוים. פרטים נוספים על ההתאמה regex_filter אפשר למצוא כאן: --per_file_copt. אפשר לראות --spawn_strategie את האסטרטגיות הנתמכות וההשפעות שלהן.

הערך regex_filter האחרון שתואם לתיאור משמש. אפשרות זו מבטלת סימונים אחרים של ציון אסטרטגיה.

  • דוגמה: --strategy_regexp=//foo.*\\.cc,-//foo/bar=local היא להריץ פעולות באמצעותlocal אם התיאורים שלהם תואמים //foo.*.cc but not //foo/bar.
  • דוגמה: --strategy_regexp='Compiling.*/bar=local' --strategy_regexp=Compiling=sandboxed המערכת מריצה את הפונקציה 'foo/bar/baz' עם השיטה sandboxed, אבל היא מבטלת את ההזמנה באמצעות הפונקציה local.
  • דוגמה: --strategy_regexp='Compiling.*/bar=local,sandboxed' מפעיל 'הידור של //foo/bar/baz' עם השיטה local ויחזור אל sandboxed אם הוא ייכשל.

--genrule_strategy=strategy

זהו קיצור דרך ב---strategy=Genrule=strategy שהוצא משימוש.

--jobs=n (j-)

אפשרות זו, שמתבססת על ארגומנט של מספר שלם, מציינת מגבלה על מספר המשימות שיש לבצע בו-זמנית בשלב ביצוע ה-build.

--progress_report_interval=n

Bazel מדפיסת מעת לעת דוח התקדמות על משרות שטרם הסתיימו (כגון בדיקות ארוכות). אפשרות זו מגדירה את תדירות הדיווח, ההתקדמות תודפס כל n שניות.

ברירת המחדל היא 0. כלומר, אלגוריתם מצטבר: הדוח הראשון יודפס לאחר 10 שניות, לאחר מכן 30 שניות ואחריו התקדמות זו תדווח פעם אחת.

--local_{ram,cpu}_resources resources or resource expression

האפשרויות האלה מציינות את כמות המשאבים המקומיים (RAM ב-MB ומספר הליבות הלוגיות של המעבד) ש-Bazel יכולה להביא בחשבון כשמתזמנים פעילויות build ובדיקה להפעלה מקומית. הם מזינים מספר שלם, או מילת מפתח (HOST_RAM או HOST_CPUS) ואחריה [-|*מספר צף] (לדוגמה, --local_cpu_resources=2, --local_ram_resources=HOST_RAM*.5, --local_cpu_resources=HOST_CPUS-1). הסימונים אינם תלויים זה בזה; ניתן להגדיר אחת מהן או את שתיהן. כברירת מחדל, Bazel מעריכה את כמות ה-RAM ואת מספר הליבות של המעבד ישירות בתצורת המערכת המקומית.

אפשרות זו, שמופעלת כברירת מחדל, מציינת אם יש לבנות קישורים להרצה של קבצים ניסיוניים בינאריים בספריית הפלט. ניתן להשתמש ב---nobuild_runfile_links כדי לאמת אם כל היעדים מתדרדרים בלי לצבור תקורה לבניית עצים להרצה.

כשהבדיקות (או האפליקציות) מבוצעות, סוגי התלות של הנתונים בזמן הריצה נאספים יחד במקום אחד. בעץ הפלט של בזל, עץ "runFiles" בדרך כלל מבוסס על האחות הבינארית או הבדיקה המקבילה. במהלך הפעלת הבדיקה, ניתן לגשת לקובצי הרצה באמצעות נתיבי הטופס $TEST_SRCDIR/workspace/packagename/filename. עץ ההרצה מוודא שיש לבדיקות גישה לכל הקבצים בהם יש להם תלות מוצהרת ולא יותר. כברירת מחדל, עץ הרצת הקבצים מיושם על ידי בניית קבוצת קישורים סמליים לקבצים הנדרשים. ככל שקבוצת הקישורים גדלה, כך עולה עלות הפעולה הזו, ובחלק מהמבנים הגדולים היא יכולה לתרום באופן משמעותי לזמן build כולל, בעיקר מפני שכל בדיקה (או אפליקציה) דורשת בדיקה עץ הקבצים.

--[no]build_runfile_manifests

אפשרות זו, המופעלת כברירת מחדל, מציינת אם יש לכתוב מניפסטים של קובצי הרצה לעץ הפלט. השבתה שלו מרמזת על --nobuild_runfile_links.

ניתן להשבית אותו בביצוע בדיקות מרחוק, מאחר שעצים של פעילות קבצים יווצרו באופן מרוחק ממניפסטים בזיכרון.

--[no]discard_analysis_cache

אם אפשרות זו מופעלת, Bazel תמחק את מטמון הניתוח לפני שההפעלה תתחיל, וכך תפנה עוד זיכרון (כ-10%) עבור שלב הביצוע. החיסרון הוא שגרסאות build מצטברות נוספות יהיו איטיות יותר. ראה גם מצב חיסכון בזיכרון.

--[no]keep_going (k-)

כמו ב-GNU Make, שלב הביצוע של build נפסק כשמתרחשת השגיאה הראשונה. לפעמים כדאי לנסות לבנות לתוכנית פעמים רבות ככל האפשר, אפילו לנוכח שגיאות. אפשרות זו מאפשרת את ההתנהגות הזו, וכאשר היא מצוינת, ה-build ינסה לבנות כל יעד שהדרישות המוקדמות שלו נבנו בהצלחה, אבל הוא יתעלם משגיאות.

האפשרות הזו בדרך כלל משויכת לשלב הביצוע של בנייה, אבל היא משפיעה גם על שלב הניתוח: אם מציינים כמה מטרות בפקודת build, אבל רק חלק מהן ניתנות לניתוח בהצלחה, ה-build ייפסק עם שגיאה, אלא אם יצוין --keep_going, ובמקרה כזה ה-build ימשיך לשלב הביצוע, אבל רק עבור היעדים שננתחו בהצלחה.

--[no]use_ijars

אפשרות זו משנה את האופן שבו הידורים של java_library עוברים על ידי Bazel. במקום להשתמש בפלט של java_library לצורך היערכות של יעדים תלויים java_library, Bazel ייצור צ'אטים של ממשק שמכילים רק את החתימות של חברים שאינם פרטיים (ציבוריים, מוגן וברירת מחדל (שיטות ושדות של גישה) ולהשתמש בכלי הממשק כדי להרכיב את היעדים התלויים. כך ניתן להימנע מ הידור כאשר השינויים מבוצעים רק בגוף מסוים או בחברים פרטיים בכיתה.

--[no]interface_shared_objects

אפשרות זו מפעילה אובייקטים משותפים של אובייקטים. כלומר, קבצים בינאריים וספריות משותפות אחרות תלויים בממשק של אובייקט משותף, במקום ביישום שלו. כאשר רק ההטמעה משתנה, באזל יכולה להימנע מבנייה מחדש של יעדים שתלויים בספרייה המשותפת ששונתה, שלא לצורך.

בחירת פלט

אפשרויות אלה קובעות מה כדאי לבנות או לבדוק.

--[no]build

אפשרות זו גורמת לביצוע שלב ה-build של ה-build; היא מופעלת כברירת מחדל. כאשר הוא מושבת, שלב הביצוע מדלג, ורק שני השלבים הראשונים, הטעינה והניתוח מתרחשים.

האפשרות הזו יכולה להיות שימושית לאימות קובצי BUILD ולזיהוי שגיאות בסוגי הקלט, בלי לבנות שום דבר בפועל.

--[no]build_tests_only

אם צוין אחרת, בזל תבנה רק את מה שנחוץ להפעלת הכללים *_testו-test_suite שלא סוננו עקב הגודל שלהם, timeout, tag או language. אם היא מצוינת, Bazel תתעלם מיעדים אחרים שצוינו בשורת הפקודה. כברירת מחדל, האפשרות הזו מושבתת ו-Bazel תיצור את כל הבקשות, כולל כללים של *_test ו-test_suite שמסוננים מהבדיקה. האפשרות הזו שימושית כי ייתכן שההרצה של bazel test --build_tests_only foo/... לא תזהה את כל מעברי ה-build בעץ foo.

--[no]check_up_to_date

בעקבות אפשרות זו, Bazel לא מבצעת גרסת build, אלא רק בודקת אם כל היעדים שצוינו עדכניים. אם כן, ה-build מסתיים בהצלחה, כרגיל. עם זאת, אם קבצים כלשהם אינם מעודכנים, במקום ליצור אותם, תיווצר שגיאה וה-build ייכשל. אפשרות זו שימושית כדי לקבוע אם גרסה בוצעה לאחרונה יותר מאשר פעולת עריכה של מקור (לדוגמה, עבור בדיקות שליחה מראש) בלי לצבור עלויות של build.

ראו גם --check_tests_up_to_date.

--[no]compile_one_dependency

יש ליצור תלות אחת בכל פעם של קובצי הארגומנטים. אפשרות זו שימושית בבדיקת קובצי מקור בתחביר של IDE, לדוגמה, על ידי בנייה מחדש של יעד יחיד שתלוי בקובץ המקור, כדי לזהות שגיאות בשלב מוקדם ככל האפשר במחזור העריכה/הבנייה/הבדיקה. הארגומנט הזה משפיע על האופן שבו כל הארגומנטים שאינם של סימון מתפרשים: כל ארגומנט חייב להיות תווית יעד של קובץ או שם קובץ פשוט ביחס לספריית העבודה הנוכחית, וכלל אחד התלוי בכל שם קובץ של מקור נבנה. עבור

המקורות של C++ ו-Java, רצויים באותו מרחב שפה. עבור כללים מרובים עם אותה העדפה, הכלל שמופיע ראשון בקובץ ה-BUILD נבחר. דפוס יעד בעל שם מפורש שאינו מפנה לקובץ קובץ המקור עלול לגרום לשגיאה.

--save_temps

האפשרות --save_temps גורמת לשמירת פלט זמני מהמהדר. קבצים אלה כוללים קובצי .semer (קוד הרכב), i. (מעובדים מראש C) וקובצי .ii (+C מעובד מראש) הפלטים האלה שימושיים בדרך כלל לניפוי באגים. הטמפרטורות ייווצרו רק עבור קבוצת היעדים שצוינו בשורת הפקודה.

בשלב זה, הסימון --save_temps פועל רק עם כללי cc_*.

כדי להבטיח שבזל תדפיס את המיקום של קובצי הפלט הנוספים, יש לוודא שההגדרה של --show_result n גבוהה מספיק.

--build_tag_filters=tag[,tag]*

אם היא מצוינת, Bazel תבנה רק יעדים שיש בהם לפחות תג חובה אחד (אם אחד מהם צוין) ולא מכילה תגים שלא נכללו. המסנן של תג Build מצוין כרשימה מופרדת בפסיקים של מילות מפתח של תגים. ניתן להוסיף גם סימן '-' המשמש לסימון תגים מוחרגים. לתגים הנדרשים יכול להיות גם סימן '+' קודם.

בזמן הרצת הבדיקות, Bazel מתעלמת מ---build_tag_filters ליעדי הבדיקה, שנבנות ופועלים גם אם הם לא תואמים למסנן הזה. כדי להימנע מבנייתן, יש לסנן את יעדי הבדיקה באמצעות --test_tag_filters או באמצעות החרגה מפורשת שלהם.

--test_size_filters=size[,size]*

אם צוין, Bazel יבדוק (או יבנה אם צוין גם --build_tests_only) רק יעדי בדיקה בגודל נתון. מסנן גודל הבדיקה מצוין כרשימה מופרדת באמצעות פסיקים של ערכי גודל בדיקה מורשים (קטנים, בינוניים, גדולים או עצומים), אך לפניהם הסימן '-' משמש לציון גדלים של בדיקות שלא נכללו. לדוגמה,

  % bazel test --test_size_filters=small,medium //foo:all
וגם
  % bazel test --test_size_filters=-large,-enormous //foo:all

תבדוק רק בדיקות קטנות ובינוניות בתוך //foo.

כברירת מחדל, סינון גודל הבדיקה לא מוחל.

--test_timeout_filters=timeout[,timeout]*

אם צוין, Bazel יבדוק (או יבנה אם צוין גם --build_tests_only) רק יעדי בדיקה עם הזמן הקצוב לתפוגה. מסנן הזמן הקצוב לבדיקה מוגדר כרשימת ערכים מופרדים בפסיקים של ערכי זמן קצוב לתפוגה המותרים (קצר, מתון, ארוך או נצחי), כשלפניהם סימן '-' המשמש לציון זמנים קצובים לתפוגה של בדיקה שלא נכללו. ראו --test_size_filters לעיון בתחביר לדוגמה.

כברירת מחדל, סינון הזמן הקצוב לתפוגה של בדיקה לא הוחל.

--test_tag_filters=tag[,tag]*

אם היא מצוינת, Bazel תבדוק (או תבנה אם צוין גם --build_tests_only) רק יעדי בדיקה שיש להם לפחות תג חובה אחד (אם אחד מהם צוין) ואין לה תגים שלא נכללו. מסנן הבדיקה של התג מצוין כרשימה מופרדת בפסיקים של מילות מפתח של תגים. לחלופין, ניתן להוסיף לפניו את הסימן '-' כדי לציין תגים שאינם נכללים. לתגים הנדרשים יכול להיות גם סימן '+' קודם.

לדוגמה,

  % bazel test --test_tag_filters=performance,stress,-flaky //myproject:all

יבחן יעדים המתויגים באמצעות תג performance או stress אך אינם מתויגים באמצעות התג flaky.

כברירת מחדל, לא מופעל סינון של תגי בדיקה. לידיעתך, ניתן גם לסנן את התגים size ו-local לבדיקה באופן זה.

--test_lang_filters=lang[,lang]*

מציינת רשימה של שפות בדיקה המופרדות באמצעות פסיקים לשפות עם כלל *_test רשמי (לרשימה המלאה של הקטגוריות האלה יש לעיין במבנה אנציקלופדיה). לפני כל שפה אפשר להוסיף לפניו את הסימן '-' כדי לציין שפות שלא נכללו. השם בכל שפה צריך להיות זהה לשם של קידומת השפה בכלל *_test, לדוגמה, cc, java או sh.

אם היא מצוינת, Bazel תבדוק (או תבנה אם צוין גם --build_tests_only) רק יעדי בדיקה של השפות שצוינו.

לדוגמה,

  % bazel test --test_lang_filters=cc,java foo/...

יבדוק רק את בדיקות C/C++ ו-Java (מוגדר באמצעות cc_test ו-java_test, בהתאמה) ב-foo/..., בזמן

  % bazel test --test_lang_filters=-sh,-java foo/...

יריץ את כל הבדיקות ב-foo/... מלבד הבדיקות sh_test ו-java_test.

כברירת מחדל, לא מוחל סינון מסננים לבדיקה.

--test_filter=filter-expression

מציין מסנן שבו מפעיל הבדיקה יכול להשתמש כדי לבחור קבוצת משנה של בדיקות להפעלה. כל היעדים שצוינו בהפעלת המודעות בנויים, אך בהתאם לביטוי, ניתן ליישם רק חלק מהם; במקרים מסוימים, רק שיטות בדיקה מסוימות פועלות.

הפרשנות הספציפית של filter-expression תלויה במסגרת הבדיקה האחראית להפעלת הבדיקה. הוא יכול להיות גלובוס, מחרוזת משנה או ביטוי רגולרי. --test_filter הוא אמצעי נוח למעבר בין ארגומנטים שונים לסינון --test_arg, אך לא כל המסגרות תומכים בו.

דרגת מלל

אפשרויות אלה שולטות בדרגת המלל של פלט בזל, במסוף או בקובצי יומן נוספים.

--explain=logfile

האפשרות הזו, שמחייבת ארגומנט של שם קובץ, גורמת לבודק התלות בשלב ההפעלה של bazel build להסביר עבור כל שלב build, מדוע היא מתבצעת או למה היא מתבצעת מעודכנות. ההסבר כתוב ב-logfile.

אם אתם נתקלים בבנייה מחדש בלתי צפויה, האפשרות הזו יכולה לעזור להבין את הסיבה. הוסף אותו ל-.bazelrc כך שהרישום יופיע בכל המבנים הבאים, ולאחר מכן בדוק את היומן כשתראה שלב ביצוע שבוצע באופן בלתי צפוי. אפשרות זו עלולה לגרום לפגיעה קטנה בביצועים, ולכן מומלץ לבטל אותה כשאין בה יותר צורך.

--verbose_explanations

אפשרות זו מגדילה את המילול של ההסברים שנוצרים כאשר האפשרות --הסבר מופעלת.

באופן ספציפי, אם מופעלים הסברים מרובי-מלל, וקובץ פלט נבנה מחדש מכיוון שהפקודה ששימשה לבנייתו השתנתה, הפלט בקובץ ההסבר יכלול את הפרטים המלאים של הפקודה החדשה (לפחות עבור רוב הפקודות).

שימוש באפשרות הזו עשוי להאריך משמעותית את אורך קובץ ההסברים שנוצר ואת קנס הביצועים של --explain.

אם --explain אינו מופעל, ל---verbose_explanations אין השפעה.

--profile=file

אפשרות זו, שמקבלת ארגומנט של שם קובץ, גורמת ל-Bazel לכתוב נתוני פרופיל לקובץ. לאחר מכן ניתן לנתח או לנתח את הנתונים באמצעות הפקודה bazel analyze-profile. פרופיל ה-Build יכול לעזור להבין באיזה סביבה של הפקודה של build ב-Bazel.

--[no]show_loading_progress

בעקבות זאת, Bazel יכולה להפיק הודעות לגבי התקדמות טעינת חבילות. אם היא מושבתת, ההודעות לא יוצגו.

--[no]show_progress

אפשרות זו גורמת להצגת הודעות התקדמות; היא מופעלת כברירת מחדל. כאשר אפשרות זו מושבתת, הודעות התקדמות מוסתרות.

--show_progress_rate_limit=n

אפשרות זו גורמת ל-Bazel להציג רק הודעת התקדמות אחת לכל n שניות, כאשר n הוא מספר אמיתי. אם הערך של n הוא -1, כל הודעות ההתקדמות יוצגו. ערך ברירת המחדל עבור האפשרות הזו הוא 0.02. כלומר, בזל יגביל את הודעות ההתקדמות לאחת לכל 0.02 שניות.

--show_result=n

אפשרות זו שולטת בהדפסת פרטי התוצאה בסוף פקודה של bazel build. כברירת מחדל, אם צוין יעד build יחיד, Bazel מדפיסה הודעה שמציינת אם היעד עודכן או לא, ואם כן, את רשימת קובצי הפלט היעד נוצר. אם צוינו יעדים מרובים, פרטי התוצאות לא יוצגו.

מידע על התוצאה עשוי להיות שימושי למבנים של יעד יחיד או של כמה יעדים, אך עבור מבנים גדולים (כמו עץ פרויקט שלם ברמה העליונה), המידע עלול להיות מוצף ומסיח את הדעת. כך ניתן לשלוט בה. --show_result יש לקבל מספר שלם של ארגומנט, שהוא המספר המקסימלי של יעדים שעבורם יש להדפיס מידע על התוצאה המלאה. כברירת מחדל, הערך הוא 1. מעל סף זה, לא מוצגים פרטי תוצאות ליעדים בודדים. לכן, אפס גורם לתוצאה להשתיק תמיד את המידע, וערך גדול מאוד גורם להדפסת התוצאה.

ייתכן שהמשתמשים ירצו לבחור ערך באמצע, בין אם הם מחליפים באופן קבוע בין קבוצה קטנה של יעדים (לדוגמה, במהלך מחזור הידור הבדיקה) לבין קבוצת יעדים גדולה ( לדוגמה, כשאתם יוצרים סביבת עבודה חדשה או מפעילים בדיקות רגרסיה). במקרה הקודם, המידע על התוצאה שימושי מאוד, ואילו במקרה השני, הוא פחות שימושי. כמו בכל אפשרויות אחרות, ניתן לציין זאת באופן לא מפורש באמצעות הקובץ .bazelrc.

הקבצים מודפסים כדי לאפשר העתקה והדבקה של שם הקובץ למעטפת, כדי להפעיל קובצי הפעלה מובנים. ניתן לנתח בקלות את ההודעות "העדכניות" או "נכשלות" של כל יעד על ידי סקריפטים שיוצרים גרסה.

--sandbox_debug

אפשרות זו גורמת ל-Bazel להדפיס מידע נוסף על ניפוי באגים כשמשתמשים בארגז חול לפעולה. אפשרות זו גם שומרת ספריות של ארגז חול, כדי שניתן יהיה לבדוק את הקבצים הגלויים לפעולות במהלך הביצוע.

--subcommands (-s)

אפשרות זו גורמת לשלב הביצוע של בזל להדפיס את שורת הפקודה המלאה עבור כל פקודה לפני ביצועה.

  >>>>> # //examples/cpp:hello-world [action 'Linking examples/cpp/hello-world']
  (cd /home/johndoe/.cache/bazel/_bazel_johndoe/4c084335afceb392cfbe7c31afee3a9f/bazel && \
    exec env - \
    /usr/bin/gcc -o bazel-out/local-fastbuild/bin/examples/cpp/hello-world -B/usr/bin/ -Wl,-z,relro,-z,now -no-canonical-prefixes -pass-exit-codes -Wl,-S -Wl,@bazel-out/local_linux-fastbuild/bin/examples/cpp/hello-world-2.params)

במידת האפשר, הפקודות מודפסות בתחביר התואם למעטפת של Bourne, כדי שניתן יהיה להעתיק ולהדביק אותן בקלות בשורת הפקודה של המעטפת. (הסוגריים הסובבים מסופקים כדי להגן על המעטפת מפני שיחות cd ו-exec; יש להקפיד להעתיק אותם!) עם זאת, חלק מהפקודות מיושמות באופן פנימי בבזל, למשל יצירת עצי קישור. עבור שורות אלה אין שורת פקודה להצגה.

ניתן להעביר את --subcommands=pretty_print כדי להדפיס את הארגומנטים של הפקודה כרשימה, ולא כשורה אחת. כך ניתן לקרוא שורות פקודה ארוכות יותר.

ראו גם --verbose_failures, להלן.

כדי לבצע רישום של פקודות-משנה של קובץ לקובץ בפורמט ידידותי לכלי, ראה --execution_log_json_file וכן --execution_log_binary_file.

--verbose_failures

אפשרות זו גורמת לשלב הביצוע של Bazel להדפיס את שורת הפקודה המלאה עבור פקודות שנכשלו. דבר זה עשוי להיות בעל ערך רב לניפוי באגים בכשל ב-build.

פקודות שנכשלו נדפסות בתחביר תואם למעטפת של Bourne. הן מתאימות להעתקה והדבקה של בקשת מעטפת.

סטטוס סביבת העבודה

ניתן להשתמש באפשרויות האלה כדי "לחתום על בינאריות" שנוצרו על ידי בזל: כדי להטמיע מידע נוסף בקבצים הבינאריים, כמו הגרסה הקודמת של בקרת המקור או מידע אחר שקשור לסביבת העבודה. ניתן להשתמש במנגנון הזה עם כללים שתומכים במאפיין stamp, כגון genrule, cc_binary ועוד.

--workspace_status_command=program

הסימון הזה מאפשר לך לציין קובץ בינארי ש-Bazel מריץ לפני כל בנייה. התוכנית יכולה לדווח על מידע לגבי סביבת העבודה, כגון הגרסה הנוכחית של בקרת המקור.

ערך הסימון חייב להיות נתיב לתוכנית מותאמת. ב-Linux/macOS ניתן להשתמש בכל קובץ הפעלה. ב-Windows, הקובץ צריך להיות בינארי, בדרך כלל קובץ ".exe", ".bat" או ".cmd".

על התוכנית להדפיס אפס או צמדי מפתחות/ערכים לפלט סטנדרטי, ערך אחד בכל שורה, ולאחר מכן לצאת עם אפס (אחרת ה-build ייכשל). השמות העיקריים יכולים להיות כל דבר, אך הם רשאים להשתמש באותיות רישיות ובקווים תחתונים בלבד. הרווח הראשון אחרי שם המפתח יפריד אותו מהערך. הערך הוא שאר השורה (כולל רווחים לבנים נוספים). המפתח והערך לא יכולים לכלול כמה שורות. לא ניתן לשכפל מפתחות.

Bazel מחולקת למחיצות לשתי קטגוריות: "יציבה" ו "יציבה". (השמות "יציבים" ו"הפכפכים" נוגדים את ההיגיון הנגדי, לכן אל תחשוב עליהם היטב).

לאחר מכן, Bazel כותבת את צמדי מפתח-ערך בשני קבצים:

  • bazel-out/stable-status.txt מכיל את כל המפתחות והערכים שבהם שם המפתח מתחיל ב-STABLE_
  • bazel-out/volatile-status.txt מכיל את שאר המפתחות והערכים שלהם

החוזה הוא:

  • הערכים של המפתחות ה"יציבים" אמורים להשתנות לעתים רחוקות, אם הדבר אפשרי. אם התוכן של bazel-out/stable-status.txt משתנה, בזל לא תקפה את הפעולות שתלויות בהן. במילים אחרות, אם הערך של מפתח יציב משתנה, Bazel תפעיל מחדש פעולות עם חותמת. לכן הסטטוס היציב לא יכול לכלול דברים כמו חותמות זמן, כי הן משתנות כל הזמן, וגורמות לבזל להפעיל מחדש פעולות חותמות בכל דגם.

    בזל תמיד יוצרת פלט של המפתחות היציבים הבאים:

    • BUILD_EMBED_LABEL: ערך של --embed_label
    • BUILD_HOST: שם המחשב המארח שבו פועלת בזל
    • BUILD_USER: שם המשתמש ש-Bazel פועלת בו
  • ערכים של מפתחות "תנודתיים" עשויים להשתנות לעתים קרובות. Bazel מצפה שהם ישתנו כל הזמן, כמו עם חותמת הזמן, ומעדכנת כראוי את הקובץ bazel-out/volatile-status.txt. כדי להימנע מהפעלה מחדש של פעולות חתומות כל הזמן, באזל מתחזה שקובץ התנודתי אף פעם לא משתנה. במילים אחרות, אם קובץ הסטטוס משתנה הוא הקובץ היחיד שהתוכן שלו השתנה, Bazel לא תבטל פעולות שתלויות בה. אם אמצעי קלט אחרים של הפעולות השתנו, Bazel תפעיל מחדש את הפעולה והיא תראה את הסטטוס משתנה תנודתי, אבל רק שינוי המצב התנודתי עצמו לא יבטל את הפעולה.

    בזל תמיד יוצרת פלט של מפתחות התנודתיות הבאים:

    • BUILD_TIMESTAMP: זמן ה-build בשניות מאז עידן ה-Unix (הערך של System.currentTimeMillis() מחולק באלף)

ב-Linux/macOS ניתן לעבור אל --workspace_status_command=/bin/trueכדי להשבית את הסטטוס של אחזור סביבת העבודה, כי true לא עושה דבר, בהצלחה (יציאות עם אפס) ומדפיסה ללא פלט. ב-Windows, אתה יכול לעבור את הנתיב של MSYS true.exe לקבלת אותה אפקט.

אם פקודת הסטטוס של סביבת העבודה תיכשל (יציאות, שאינן אפס) מסיבה כלשהי, ה-build ייכשל.

תוכנית לדוגמה ב-Linux באמצעות Git:

#!/bin/bash
echo "CURRENT_TIME $(date +%s)"
echo "RANDOM_HASH $(cat /proc/sys/kernel/random/uuid)"
echo "STABLE_GIT_COMMIT $(git rev-parse HEAD)"
echo "STABLE_USER_NAME $USER"

יש לעבור את הנתיב של התוכנית הזו עם --workspace_status_command, וקובץ הסטטוס היציב יכלול את שורות ה-STABLE ואת קובץ התנודתיות יכלול את שאר השורות.

--[no]stamp

האפשרות הזו, בשילוב עם מאפיין הכלל stamp, קובעת אם להטמיע מידע build בגרסה בינארית.

אפשר להפעיל או להשבית את החותמת באופן מפורש בהתאם לכל כלל, באמצעות המאפיין stamp. לפרטים נוספים, יש לעיין באנציקלופדיה Build. כאשר כלל מגדיר stamp = -1 (ברירת המחדל עבור כללים מסוג *_binary), האפשרות הזו קובעת אם ההחתמה מופעלת.

Bazel לעולם לא חותמת על קבצים בינאריים שנבנו עבור תצורת המארח, ללא קשר לאפשרות הזו או למאפיין stamp. עבור כללים שמגדירים stamp = 0 (ברירת המחדל לכללי *_test), החותמת מושבתת ללא קשר ל---[no]stamp. ציון --stamp לא מאלץ בנייה מחדש של יעדים אם יחסי התלות שלהם לא השתנו.

בדרך כלל, הגדרת ה---nostamp מתאימה ליצירת ביצועים של build, כיוון שהיא מפחיתה את התנודתיות בקלט ומגדילה למקסימום את השמירה במטמון.

פלטפורמה

ניתן להשתמש באפשרויות האלה כדי לשלוט בפלטפורמות המארחות והיעד שמגדירות את אופן הפעולה של גרסאות build, ולקבוע אילו פלטפורמות ביצוע ומאגרי כלים זמינים לכללי Bazel.

מומלץ לקרוא את המידע שברקע, בנושא פלטפורמות וToolchains.

--platforms=labels

התוויות של כללי הפלטפורמה המתארים את פלטפורמות היעד של הפקודה הנוכחית.

--host_platform=label

התווית של כלל פלטפורמה שמתאר את המערכת המארחת.

--extra_execution_platforms=labels

הפלטפורמות שזמינות כפלטפורמות ביצוע להרצת פעולות. ניתן לציין פלטפורמות לפי יעד מדויק או כדפוס יעד. הפלטפורמות האלה יישקלו לפני אלו שהוצהרו בקובץ WORKSPACE על ידי במרשם_לביצוע_ההרשמה הנתונים.

--extra_toolchains=labels

כללי ה-Keychain יחשבו במהלך זיהוי כלים. ניתן לציין Searchchains לפי יעד מדויק, או כדפוס יעד. כלים אלה ישתקלו לפני שהם יוצהרו בקובץ WORKSPACE על ידי רישום_toolchains().

--toolchain_resolution_debug=regex

הדפס מידע על תוצאות ניפוי באגים ומוצא 'כלים' אם הסוג של 'ארגז הכלים' תואם לביטוי הרגולרי. אפשר להפריד בין ביטויים רגולריים מרובים באמצעות פסיקים. ניתן לבטל את הביטוי הרגולרי כדי להשתמש ב-- בהתחלה. הבדיקה הזו יכולה לעזור למפתחים של כללי Bazel או Starlark להיכשל ניפוי באגים עקב חוסר בכלים.

שונות

--flag_alias=alias_name=target_path

דגל נוחות המשמש לאיגוד הגדרות build של Starlark לשם קצר יותר. לפרטים נוספים, עיינו בתצורות של Starlark.

שינוי הקידומת של סמלי הנוחות שנוצרו. ערך ברירת המחדל של הקידומת symlink הוא bazel-, והוא ייצור את הקישורים הסימבוליים bazel-bin, bazel-testlogs ו-bazel-genfiles.

אם לא ניתן ליצור קישורים סימבוליים מסיבה כלשהי, נשלחת אזהרה, אבל ה-build עדיין נחשב להצלחה. בפרט, הדבר מאפשר לכם לבנות ספרייה לקריאה בלבד, או כזו שאין לכם הרשאה לכתוב בה. כל המסלולים המודפסים בהודעות אינפורמטיביות בסיום ה-build ישתמשו בתבנית הקצרה יחסית של קישור סימבולי אם הקישורים בסמלים יצביעו על המיקום הצפוי; במילים אחרות, אתם יכולים לסמוך על נכונות הנתיבים האלה, גם אם אין לכם אפשרות להסתמך על הקישורים הסמליים שאתם יוצרים.

כמה ערכים נפוצים של אפשרות זו:

  • מניעת יצירה של קישורים סימבוליים: --symlink_prefix=/ יגרום ל-Bazel לא ליצור או לעדכן קישורים סימבוליים, כולל bazel-out ו-bazel-<workspace> קישורים סימבוליים הנתונים. אפשרות זו מיועדת למנוע לחלוטין יצירת קישורים סימבוליים.

  • צמצום העומס: --symlink_prefix=.bazel/ יגרום ל-Bazel ליצור קישורים סימבוליים בשם bin (וכו') בתוך ספרייה נסתרת .bazel.

--platform_suffix=string

מוסיפה סיומת לשם המקוצר של התצורה, המשמשת לקביעת ספריית הפלט. הגדרת אפשרות זו לערכים שונים הופכת את הקבצים לספריות שונות, לדוגמה, כדי לשפר את קצבי ההיטים של מטמון עבור גרסאות build שמסתירות זו את זו קבצים אחרים, או כדי לשמור את קובצי הפלט סביבם לצורך השוואות.

--default_visibility=(private|public)

סימון זמני לבדיקת שינויים בהרשאות ברירת המחדל של צוות האבטחה. לא מיועד לשימוש כללי אבל מתועד לשם שלמות.

--[no]use_action_cache

האפשרות הזו מופעלת כברירת מחדל. אם אפשרות זו מושבתת, Bazel לא תשתמש בקובץ השמור של הפעולה המקומית שלה. השבתת המטמון של הפעולה המקומית חוסכת בזיכרון ובשטח האחסון עבור גרסאות build נקיות, אך היא מאיצה את ה-build מצטבר.

--starlark_cpu_profile=_file_

הסימון הזה, שהערך שלו הוא שם של קובץ, גורם ל-Bazel לאסוף נתונים סטטיסטיים לגבי השימוש במעבד על ידי כל השרשורים של Starlark, ולכתוב את הפרופיל בפורמט pprof, לקובץ בשם.

השתמש באפשרות זו כדי לעזור לזהות פונקציות של Starlark שמאטות את הטעינה וניתוח, עקב חישובים מוגזמים. למשל:

$ bazel build --nobuild --starlark_cpu_profile=/tmp/pprof.gz my/project/...
$ pprof /tmp/pprof.gz
(pprof) top
Type: CPU
Time: Feb 6, 2020 at 12:06pm (PST)
Duration: 5.26s, Total samples = 3.34s (63.55%)
Showing nodes accounting for 3.34s, 100% of 3.34s total
      flat  flat%   sum%        cum   cum%
     1.86s 55.69% 55.69%      1.86s 55.69%  sort_source_files
     1.02s 30.54% 86.23%      1.02s 30.54%  expand_all_combinations
     0.44s 13.17% 99.40%      0.44s 13.17%  range
     0.02s   0.6%   100%      3.34s   100%  sorted
         0     0%   100%      1.38s 41.32%  my/project/main/BUILD
         0     0%   100%      1.96s 58.68%  my/project/library.bzl
         0     0%   100%      3.34s   100%  main

לקבלת תצוגות שונות של אותם נתונים, אפשר לנסות את pprof הפקודות svg, web ו-list.

שימוש ב-Bazel למהדורות

ב Baזelל משמשת מהנדסי תוכנה במהלך מחזור הפיתוח, וכן מהנדסי תוכנה לשחרור נתונים בעת הכנת בינאריים לפריסה לייצור. הקטע הזה מספק רשימת טיפים למהנדסי תוכנה שמשתמשים ב-Bazel.

אפשרויות משמעותיות

בעת שימוש ב-Bazel עבור גרסאות build, מתרחשות אותן בעיות כמו בסקריפטים אחרים שמפעילים build. לקבלת פרטים נוספים, אפשר לעיין ב התקשרות אל Bazel מסקריפטים. מומלץ במיוחד לבחור באפשרויות הבאות:

האפשרויות הבאות חשובות גם הן:

  • --package_path
  • --symlink_prefix: לניהול גרסאות build לתצורות מרובות, ייתכן שיהיה נוח להבדיל בין גרסאות build עם מזהה ייחודי, כמו "64 סיביות" לעומת "32 סיביות". " בחירה באפשרות זו מבדילה את סמלי bazel-bin (וכו').

הרצת בדיקות

כדי לבנות ולהפעיל בדיקות עם בזל, מקלידים bazel test ולאחר מכן את שם יעדי הבדיקה.

כברירת מחדל, פקודה זו מבצעת בו-זמנית פעילות build ובדיקה בו-זמנית, תוך בניית כל היעדים שצוינו (כולל יעדים שאינם למטרות בדיקה שצוינו בשורת הפקודה) ובדיקה של יעדי *_test ו-test_suite ברגע שנוצרות הדרישות המוקדמות, כלומר, ביצוע הבדיקה משולב באתר. פעולה זו מובילה בדרך כלל לשיפורי מהירות משמעותיים.

אפשרויות של bazel test

--cache_test_results=(yes|no|auto) (-t)

אם אפשרות זו מוגדרת כ 'אוטומטי' (ברירת המחדל), Bazel תפעיל מחדש בדיקה רק אם מתקיים אחד מהתנאים הבאים:

  • Bazel מזהה שינויים בבדיקה או בתלויות שלה
  • הבדיקה סומנה כ-external
  • בקשות לבדיקה מרובות של בקשות עם--runs_per_test
  • הבדיקה נכשלה.

אם התשובה היא 'לא', כל הבדיקות יבוצעו ללא תנאי.

אם התשובה היא 'כן', פעולת השמירה במטמון תהיה אוטומטית, אבל היא עלולה לשמור במטמון את כשלונות הבדיקה ולהריץ את הבדיקה יחד עם --runs_per_test.

משתמשים שהפעילו את האפשרות הזו כברירת מחדל בקובץ .bazelrc שלהם עשויים למצוא את הקיצורים -t (מופעל) או -t- (כבוי) נוח לשינוי של ברירת המחדל ריצה ספציפית.

--check_tests_up_to_date

אפשרות זו מורה ל-Bazel לא להפעיל את הבדיקות, אלא רק לבדוק את תוצאות הבדיקה השמורות במטמון ולדווח עליהן. אם יש בדיקות שלא נבנו או שפעלו בעבר, או שתוצאות הבדיקות שלהן לא מעודכנות (לדוגמה, מפני שקוד המקור או אפשרויות ה-build השתנו), Bazel תדווח הודעת שגיאה ("תוצאת הבדיקה אינה מעודכנת"), תתעד את סטטוס הבדיקה כ"ללא סטטוס" (באדום, אם הופעל פלט צבע), ותוחזר קוד יציאה שאינו אפס.

האפשרות הזו מרמזת גם על התנהגות [--check_up_to_date](#check-up-to-date).

אפשרות זו יכולה להיות שימושית לבדיקות טרום-השקה.

--test_verbose_timeout_warnings

אפשרות זו מורה ל-Bazel להזהיר באופן מפורש את המשתמש אם זמן קצוב לתפוגה של בדיקה ארוך משמעותית מזמן הביצוע של הבדיקה בפועל. בזמן הקצוב לבדיקה יש להגדיר את הזמן הקצוב לתפוגה כך שלא יהיה רעוע, אך בדיקה עם זמן קצוב לתפוגה נדיב מדי עשויה להסתיר בעיות אמיתיות שצצות באופן בלתי צפוי.

למשל, בדיקה שמבצעת בדרך כלל דקה או שתיים לא אמורה להיות בעלת זמן קצוב לתפוגה של ETERNAL או DURATION, שכן הן הרבה יותר נדיבות.

האפשרות הזו שימושית כדי לעזור למשתמשים להחליט על ערך טוב של זמן קצוב לתפוגה, או לבדוק את הערכים של הזמן הקצוב הקיים לתפוגה.

--[no]test_keep_going

כברירת מחדל, כל הבדיקות מסתיימות עד להשלמה. אם הדגל הזה מושבת, ה-build מבוטל בכל בדיקה שאינה עוברת. שלבי הבנייה ובדיקת הניסוי הבאים אינם פועלים, וההפעלות במהלך טיסה מבוטלות. אין לציין גם --notest_keep_going וגם --keep_going.

--flaky_test_attempts=attempts

אפשרות זו מציינת את מספר הפעמים המקסימלי שיש לנסות בדיקה כלשהי, אם היא נכשלת מסיבה כלשהי. בדיקה שנכשלה בהתחלה אך בסופו של דבר מצליחה מדווחת כ-FLAKY בסיכום הבדיקה. עם זאת, הדבר ייחשב כציון דרך כשמדובר בזיהוי קוד יציאה של בזל או מספר כולל של בדיקות שעברו בהצלחה. בדיקות שנכשלו בכל הניסיונות המותרים נכשלות.

כברירת מחדל (כאשר אפשרות זו אינה מוגדרת, או כאשר היא מוגדרת לברירת מחדל), מותר רק ניסיון אחד לבדיקות רגילות, ו-3 לכללי בדיקה עם קבוצת המאפיינים flaky. ניתן לציין ערך של מספר שלם כדי לבטל את המגבלה המקסימלית של ניסיונות בדיקה. Bazel מאפשרת 10 ניסיונות בדיקה לכל היותר על מנת למנוע ניצול לרעה של המערכת.

--runs_per_test=[regex@]number

אפשרות זו מציינת את מספר הפעמים שיש לבצע כל בדיקה. כל הפעלות הבדיקה נחשבות כבדיקות נפרדות (פונקציונליות הגיבוי תחול על כל אחת מהן בנפרד).

הסטטוס של יעד שהניסיונות שלו נכשלים תלוי בערך של הסימון --runs_per_test_detects_flakes:

  • אם חסר, הרצת תיכשל גורמת לכשל בבדיקה כולה.
  • אם קיימות שתי ריצוף מאותו פיצול, מוחזרות PASS ו-Fail, הבדיקה תקבל סטטוס של תקלה (אלא אם ניסיונות כושלים אחרים יגרמו לכשלון).

אם צוין מספר אחד, כל הבדיקות יופעלו מספר רב של פעמים. לחלופין, ביטוי רגולרי ניתן לציין באמצעות התחביר regex@number. מגבילה את ההשפעה של--runs_per_test אל יעדים שתואם לביטוי הרגולרי (--runs_per_test=^//pizza:.*@4 מפעיל את כל הבדיקות בקטע//pizza/ 4 פעמים). ניתן לציין את הצורה הזו של --runs_per_test יותר מפעם אחת.

--[no]runs_per_test_detects_flakes

אם ציינתם את האפשרות הזו (כברירת מחדל היא לא מסומנת), Bazel תזהה מקטעים ניסיוניים של בדיקה באמצעות --runs_per_test. אם פעם אחת או יותר פועלת לקבלת פיצול אחד, ונכשלה ריצה אחת או יותר עבור אותו פיצול, היעד יתייחס לדגל החדש. אם לא צוין יעד, היעד ידווח על כשל.

--test_summary=output_style

מציין כיצד להציג את סיכום תוצאות הבדיקה.

  • אם הבדיקה נכשלה, short תדפיס את התוצאות של כל בדיקה בצירוף שם הקובץ המכיל את פלט הבדיקה. זהו ערך ברירת המחדל.
  • terse דומה ל-short, אבל הוא קצר עוד יותר: הדפס רק מידע על בדיקות שלא עברו.
  • detailed מדפיס כל מקרה בדיקה שנכשל, לא רק כל בדיקה. המערכת מתעלמת משמות של קובצי פלט לבדיקה.
  • none אינו מדפיס את סיכום הבדיקה.

--test_output=output_style

מציין כיצד להציג את פלט הבדיקה:

  • בעמודה summary מוצג סיכום אם הבדיקה עברה או נכשלה. מציג גם את שם קובץ יומן הפלט עבור בדיקות שנכשלו. הסיכום יודפס בסוף ה-build (במהלך ה-build, יוכל לראות רק הודעות התקדמות פשוטות כאשר הבדיקות מתחילות, עוברות או נכשלות). זוהי התנהגות ברירת המחדל.
  • errors שולח פלט משולב stdout/stdr מבדיקות כושלות רק אל ה-stdout מיד לאחר סיום הבדיקה, באופן שמבטיח שפלט הבדיקה מבדיקות בו-זמניות לא ישולב זה עם זה. מסכמת סיכום של ה-build לפי פלט של הסיכום שלמעלה.
  • all דומה למחרוזת errors אבל היא מודפסת בכל הבדיקות, כולל אלה שעברו.
  • streamed מזרים פלט stdout/stderr מכל בדיקה בזמן אמת.

--java_debug

אפשרות זו גורמת למכונת ה-Java הווירטואלית של בדיקת Java להמתין לחיבור מכלי ניפוי באגים תואם ל-JDWP לפני התחלת הבדיקה. אפשרות זו מרמזת על --test_output=streamed.

--[no]verbose_test_summary

כברירת מחדל, אפשרות זו מופעלת וגורמת להדפסה של זמני הבדיקות ומידע נוסף (כגון ניסיונות בדיקה) בסיכום הבדיקה. אם מצוין --noverbose_test_summary, סיכום הבדיקה יכלול רק את שם הבדיקה, סטטוס הבדיקה והמחוון לבדיקה השמור, ויהפוך לפורמט תקין ל-80 תווים כשאפשר.

--test_tmpdir=path

מציין ספרייה זמנית לבדיקות שבוצעו באופן מקומי. כל בדיקה תתבצע בספריית משנה נפרדת בספרייה זו. הספרייה תנוקה בתחילת כל פקודה של bazel test. כברירת מחדל, Bazel תמקם את הספרייה הזו תחת ספריית הבסיס של פלט Bazel.

--test_timeout=seconds או --test_timeout=seconds,seconds,seconds,seconds

עוקף את ערך הזמן הקצוב לתפוגה עבור כל הבדיקות על ידי שימוש במספר השניות שצוינו כערך חדש של זמן קצוב לתפוגה. אם אתם מספקים רק ערך אחד, המערכת תשתמש בו בכל הקטגוריות של זמן קצוב לתפוגה של בדיקה.

לחלופין, ניתן לספק ארבעה ערכים מופרדים בפסיקים, המציינים זמנים קצובים בודדים לבדיקות קצרות, בינוניות, ארוכות ונצחיות (בסדר הזה). בכל אחד מהצורות, אפס או ערך שלילי בכל אחד מגודלי הבדיקה יוחלפו על ידי הזמן הקצוב לתפוגה של קטגוריות הזמן הקצוב לתפוגה, כפי שהוגדר בדף כתיבת בדיקות. כברירת מחדל, Bazel תשתמש בזמן הקצוב לתפוגה עבור כל הבדיקות על ידי הסקת מגבלת הזמן הקצוב מתוך גודל הבדיקה בין אם הגודל מוגדר באופן מפורש או מפורש.

בדיקות המציינות במפורש שקטגוריית הזמן הקצוב לתפוגה שונה מהגודל שלהן יקבלו ערך זהה כאילו תם הזמן הקצוב שהוגדר על ידי תג הגודל. לכן, לבדיקת גודל 'קטן' המכריזה על זמן קצוב לתפוגה 'ארוך', הזמן הקצוב בפועל של הבדיקה ה 'גדולה' יהיה זהה ללא זמן קצוב מפורש.

--test_arg=arg

העברה של אפשרויות/פקודות/ארגומנטים של שורת פקודה לכל תהליך בדיקה. ניתן להשתמש באפשרות הזו מספר פעמים כדי להעביר מספר ארגומנטים. לדוגמה, --test_arg=--logtostderr --test_arg=--v=3.

--test_env=variable=_value_ או --test_env=variable

מציינת משתנים נוספים שיש להחדיר לסביבת הבדיקה של כל בדיקה. אם לא צוין value, הוא יעבור בירושה מסביבת המעטפת המשמשת להפעלת הפקודה bazel test.

ניתן לגשת אל הסביבה מתוך בדיקה באמצעות System.getenv("var") (Java), getenv("var") (C או C++),

--run_under=command-prefix

פעולה זו מציינת קידומת שהרצת הבדיקה תוסיף לפני פקודת הבדיקה לפני הפעלתה. הcommand-prefix מחולק למילים באמצעות כללי הטוקני במעטפת, ולאחר מכן רשימת המילים מתווספת לפני הפקודה שתתבצע.

אם המילה הראשונה היא תווית מלאה (מתחילה ב-//) היא בנויה. לאחר מכן, התווית מוחלפת במיקום ההפעלה התואם, שנוסף לפני הפקודה, אשר תתבצע ביחד עם המילים האחרות.

לפניכם כמה נקודות שחשוב לשים לב אליהן:

  • ה-PATH המשמש להרצת הבדיקות עשוי להיות שונה מה-PATH בסביבה שלך, כך שייתכן שיהיה עליך להשתמש בנתיב מוחלט עבור הפקודה --run_under (המילה הראשונה ב- command-prefix).
  • stdin לא מחובר, לכן לא ניתן להשתמש ב--run_under באמצעות פקודות אינטראקטיביות.

לדוגמה:

        --run_under=/usr/bin/strace
        --run_under='/usr/bin/strace -c'
        --run_under=/usr/bin/valgrind
        --run_under='/usr/bin/valgrind --quiet --num-callers=20'

בחירת בדיקה

כפי שמתואר באפשרויות בחירת פלט, ניתן לסנן בדיקות לפי גודל, זמן קצוב לתפוגה, תג או שפה. מסנן שם כללי נוח יכול להעביר קבוצות סינון מסוימות אל מפעיל הבדיקה.

אפשרויות אחרות בשביל bazel test

התחביר והאפשרויות הנותרות הם בדיוק כמו bazel build.

קובצי הפעלה פעילים

הפקודה bazel run דומה לפונקציה bazel build, אבל היא משמשת להפעלה והרצה של יעד יחיד. זה סשן טיפוסי:

  % bazel run java/myapp:myapp -- --arg1 --arg2
  Welcome to Bazel
  INFO: Loading package: java/myapp
  INFO: Loading package: foo/bar
  INFO: Loading complete.  Analyzing...
  INFO: Found 1 target...
  ...
  Target //java/myapp:myapp up-to-date:
    bazel-bin/java/myapp:myapp
  INFO: Elapsed time: 0.638s, Critical Path: 0.34s

  INFO: Running command line: bazel-bin/java/myapp:myapp --arg1 --arg2
  Hello there
  $EXEC_ROOT/java/myapp/myapp
  --arg1
  --arg2

bazel run דומה, אך לא זהה, להפעלה ישירה של הקובץ הבינארי שנבנה על ידי בזל והתנהגותו שונה, בהתאם לאופן שבו הוא מופעל, למשל, בדיקה או לא.

כאשר הקובץ הבינארי אינו בדיקה, ספריית העבודה הנוכחית תהיה עץ ההרצה של הקובץ הבינארי.

כאשר הקובץ הבינארי הוא מבחן, ספריית העבודה הנוכחית תהיה שורש היישום ובוצע ניסיון בתום לב כדי לשכפל את בדיקות הסביבה. בדרך כלל מתבצעות הבדיקות. עם זאת, האמולציה לא מושלמת. לא ניתן להפעיל בדיקות עם מספר פיצולים בדרך זו (אפשר להשתמש באפשרות שורת הפקודה --test_sharding_strategy=disabled כדי לעקוף את הבעיה הזו)

המשתנים הסביבתיים הנוספים הבאים זמינים גם הם בקובץ הבינארי:

  • BUILD_WORKSPACE_DIRECTORY: השורש של סביבת העבודה שבה פעלה ה-build.
  • BUILD_WORKING_DIRECTORY: ספריית העבודה הנוכחית שממנהBazel הופעל.

לדוגמה, הם יכולים לפרש את שמות הקבצים בשורת הפקודה בדרך ידידותית למשתמש.

אפשרויות של bazel run

--run_under=command-prefix

פעולה זו זהה לאפשרות של --run_under עבור bazel test (ראה לעיל), אך היא חלה על הפקודה המופעלת על ידי bazel run במקום מאשר לבדיקות שבוצעו על ידי bazel test ולא ניתן להפעיל אותן תחת התווית.

סינון פלטי רישום מ-Bazel

בעת הפעלת קובץ בינארי עם bazel run, Bazel מדפיס את פלט הרישום של Bazel עצמו והבינארי תחת ההפעלה. כדי שהיומנים יהיו פחות רועשים, אפשר להשאיר את הפלטים של Bazel עצמם באמצעות הסימונים של --ui_event_filters ו---noshow_progress.

לדוגמה: bazel run --ui_event_filters=-info,-stdout,-stderr --noshow_progress //java/myapp:myapp

ביצוע בדיקות

bazel run יכול/ה גם לבצע בינאריים של בדיקה, כך שניתן להריץ את הבדיקה בערך משוער של הסביבה המתוארת בכתיבת בדיקות. שימו לב שאף אחד מהארגומנטים מסוג --test_* לא משפיע על הפעלת בדיקה מסוג זה, למעט --test_arg .

ניקוי פלטי ה-build

הפקודה clean

ל-Bazel יש פקודת clean, שדומה ל-Make. היא מוחקת את ספריות הפלט עבור כל תצורות ה-build המבוצעות על ידי מופע זה של Bazel, או את כל עץ העבודה שנוצר על ידי מופע בזל זה, ומאפסת מטמון פנימי. אם תתבצע פעולה ללא אפשרויות של שורת פקודה, ספריית הפלט של כל התצורות תנוקה.

חשוב לזכור שכל מופע של Bazel משויך לסביבת עבודה יחידה, כך שהפקודה clean תמחק את כל הפלטים של כל ה-builds שהשתתפת בהם באותו מופע של Bazel בסביבת העבודה הזו.

כדי להסיר לחלוטין את עץ העבודה המלא שנוצר על ידי מופע בזל, ניתן לציין את האפשרות --expunge. כשהיא מופעלת עם --expunge, הפקודה הנקייה פשוט מסירה את כל עץ הבסיס של הפלט, שבנוסף לפלט ה-build, המכילה את כל הקבצים הזמניים שנוצרו על ידי Bazel. היא גם מפסיקה את שרת Bazel אחרי הפקודה הנקייה, המקבילה לפקודה shutdown. לדוגמה, כדי לנקות את כל עקבות הדיסק והזיכרון של מופע בזל, ניתן לציין:

  % bazel clean --expunge

לחלופין, ניתן להסיר את הפעילות ברקע ברקע באמצעות --expunge_async. אפשר להזמין פקודת Bazel באותו לקוח בזמן שהמחיקה האסינכרונית ממשיכה לרוץ.

הפקודה clean מוגדרת בעיקר כאמצעי למשיכת שטח דיסק לסביבות עבודה שכבר לא נחוצות. ייתכן שהבנייה מחדש המצטברת של Bazel לא מושלמת, כך שניתן להשתמש ב-clean כדי לשחזר מצב עקבי כשתתעורר בעיות.

העיצוב של Bazel מאפשר לפתור את הבעיות האלה, ואת הבאגים האלה יש עדיפות גבוהה לתיקון. אם אי פעם נתקלת בגרסה שגויה שגויה, הגש דוח על באג ודווח על באגים בכלים במקום להשתמש ב-clean.

יצירת שאילתה על תלות הגרף

Bazel כולל שפת שאילתה לשאול שאלות בנוגע לתרשים התלות שבו נעשה שימוש במהלך ה-build. שפת השאילתה משמשת בשתי פקודות: שאילתה ו-cquery. ההבדל העיקרי בין שתי הפקודות הוא שהשאילתה רצה אחרי שלב הטעינה וה-cquery מופעל לאחר שלב הניתוח. לכלים האלו יש עזר רב-ערך במשימות של הנדסת תוכנה רבות.

שפת השאילתה מבוססת על הרעיון של פעולות אלגבריות על פני תרשימים; זה מתועד בפירוט ב:

הפניה לשאילתות ב-Bazel. עיינו במסמך הזה כדי לעיין בו, כדי לעיין בו ובאפשרויות של שורת הפקודה הספציפית לשאילתה.

כלי השאילתות מקבל מספר אפשרויות של שורת פקודה. הפונקציה --output בוחרת את פורמט הפלט. --[no]keep_going (מושבת כברירת מחדל) גורם לכלי השאילתה להמשיך להתקדם עם שגיאות; התנהגות זו עשויה להיות מושבתת אם תוצאה חלקית אינה קבילה במקרה של שגיאות.

האפשרות --[no]tool_deps, המופעלת כברירת מחדל, גורמת לתלויות בתצורות שאינן יעד להיכלל בתרשים התלות שבו השאילתה פועלת.

האפשרות --[no]implicit_deps, המופעלת כברירת מחדל, גורמת לתלויות משתמעת כדי להיכלל בתרשים התלות שבו השאילתה פועלת. תלות משתמעת היא כזו שלא מצוינת במפורש בקובץ ה-BUILD, אלא מתווספת על ידי בזל.

דוגמה: "הצגת המיקומים של ההגדרות (בקובצי BUILD) של כל ה-genrules הדרושים לבניית כל הבדיקות בעץ ה-PEBL."

  bazel query --output location 'kind(genrule, deps(kind(".*_test rule", foo/bar/pebl/...)))'

יצירת שאילתה לגבי תרשים הפעולה

הפקודה aquery מאפשרת לך לשלוח שאילתות לגבי פעולות בתרשים ה-build. הוא פועל בתרשים היעד המוגדר לאחר ניתוח, וחושף מידע על פעולות, חפצים והקשר שלהם.

הכלי מקבל מספר אפשרויות של שורת פקודה. הפונקציה --output בוחרת את פורמט הפלט. פורמט הפלט שמוגדר כברירת מחדל (text) הוא קריא לקריאה. יש להשתמש ב-proto או ב-textproto בפורמט קריא למחשבים. בעיקר, פקודת aquery פועלת על גבי build רגיל של Bazel ועוברת בירושה את קבוצת האפשרויות הזמינות במהלך ה-build.

הוא תומך באותה קבוצת פונקציות הזמינה גם במצב מסורתיquery אבלsiblings, buildfiles וגםtests הנתונים.

לפרטים נוספים, ראה שאילתת תרשים פעולה.

פקודות שונות ואפשרויות שונות

help

הפקודה help מספקת עזרה אונליין. כברירת מחדל, הוא מציג סיכום של פקודות זמינות ונושאי עזרה, כפי שמוצג במבנה עם Bazel. ציון ארגומנט מציג עזרה מפורטת בנושא מסוים. רוב הנושאים הם פקודות Bazel, כגון build או query, אבל יש כמה נושאי עזרה נוספים שאינם תואמים לפקודות.

--[no]long (-l)

כברירת מחדל, bazel help [topic] מדפיס רק סיכום של האפשרויות הרלוונטיות לנושא. אם תצוין האפשרות --long, גם הסוג, ערך ברירת המחדל והתיאור המלא של כל אפשרות יודפס.

shutdown

ייתכן שתהליכי שרת Bazel נעצרו באמצעות הפקודה shutdown. פקודה זו גורמת לשרת Bazel לצאת מיד כשהוא הופך ללא פעיל (לדוגמה, לאחר השלמת בנייה או פקודות אחרות שנמצאות כעת בתהליך). פרטים נוספים זמינים במאמר הטמעת לקוח/שרת.

שרתי Bazel עוצרים את עצמם לאחר זמן קצוב לתפוגה של מצב לא פעיל, כך שהפקודה נדרשת לעתים רחוקות; עם זאת, כדאי להשתמש בסקריפטים כאשר ידוע שמבנים נוספים לא יתבצעו בסביבת עבודה נתונה.

shutdown מקבלת אפשרות אחת, --iff_heap_size_greater_than _n_, שמחייבת ארגומנט מסוג מספר שלם (ב-MB). אם תגדירו פעולה זו, הכיבוי יציב את כמות הזיכרון שכבר נוצלה. אפשרות זו שימושית עבור סקריפטים שמפעילים הרבה גרסאות build, מכיוון שכל דליפת זיכרון בשרת Bazel עלולה לקרוס באופן אקראי, ביצוע של הפעלה מותנית מראש כולל את התנאי הזה.

info

הפקודה info מדפיסה ערכים שונים המשויכים למופע של שרת Bazel, או עם תצורה ספציפית של build. (ניתן להשתמש בהם בסקריפטים שמפעילים גרסת build).

הפקודה info מאפשרת גם ארגומנטים בודדים (אופציונליים), שהם השמות של אחד מהמפתחות ברשימה שלמטה. במקרה זה, bazel info key תדפיס רק את הערך של אותו מפתח. (שיטה זו שימושית במיוחד כשיוצרים סקריפט ב-Bazel, כי היא מונעת את הצורך למיין את התוצאה דרך sed -ne /key:/s/key://p:

נתונים שאינם תלויים בהגדרות

  • release: תווית ההפצה של המופע הזה של "באזל", או "גרסת פיתוח", אם זו אינה בינארית חדשה.
  • workspace הנתיב המוחלט לספרייה הבסיסית של סביבת העבודה.
  • install_base: הנתיב המוחלט לספריית ההתקנה המשמשת את מופע Bazel הזה עבור המשתמש הנוכחי. Bazel מתקינה את קובצי ההפעלה הפנימיים הנדרשים דרך ספרייה זו.

  • output_base: הנתיב המוחלט לספרייה הבסיסית של פלט המשמש את המופע הזה של Bazel עבור השילוב הנוכחי של המשתמש וסביבת העבודה. Bazel מעבירה את כל השורשים שלה ויוצרת פלט מתחת לספרייה הזו.

  • execution_root: הנתיב המוחלט לספריית הבסיס של ההפעלה בדף Output_base. הספרייה הזו היא השורש לכל הקבצים הנגישים לפקודות שבוצעו במהלך ה-build, והיא הספרייה הפועלת של פקודות אלה. אם הספרייה של סביבת העבודה ניתנת לכתיבה, ממוקם סמל קישור בשם bazel-<workspace> המצביע על הספרייה הזו.

  • output_path: הנתיב המוחלט לספריית הפלט שמופיע מתחת לספריית הבסיס של ההפעלה לכל הקבצים שנוצרו בפועל כתוצאה מפקודות build. אם הספרייה של סביבת העבודה ניתן לכתיבה, יופיע שם סמל קישור בשם bazel-out המצביע על הספרייה הזו.

  • server_pid: מזהה התהליך של שרת Bazel.

  • server_log: הנתיב המוחלט לקובץ יומן ניפוי הבאגים של שרת בזל. הקובץ מכיל מידע על ניפוי באגים עבור כל הפקודות בכל משך החיים של שרת Bazel, והוא מיועד לצריכה אנושית על ידי מפתחי Bazel ומשתמשים מתקדמים.

  • command_log: הנתיב המוחלט לקובץ יומן הפקודה; הוא מכיל את רצף ה-stdout וה-stdr המורכבים זה בזה של הפקודה האחרונה ב-Bazel. הערה: הפעלת bazel info תחליף את התוכן של הקובץ, כי היא הופכת לפקודת Bazel העדכנית ביותר. עם זאת, המיקום של קובץ יומן הפקודה לא ישתנה, אלא אם תשנה את ההגדרה של האפשרויות --output_base או --output_user_root.

  • used-heap-size, committed-heap-size, max-heap-size: מדווח על מגוון פרמטרים של ערימה (heap) של JVM. ליתר ביטחון: הזיכרון שנמצא בשימוש כרגע, הזיכרון בטוח כעת שיהיה זמין ל-JVM מהמערכת, הקצאה אפשרית מקסימלית.

  • gc-count, gc-time: הספירה המצטברת של אוספים של אשפה מאז תחילת השרת של Bazel והזמן שחלף כדי לבצע אותם. שימו לב שערכים אלה לא מאופסים בתחילת כל build.

  • package_path: רשימת מסלולים מופרדים בנקודתיים שניתן לחפש באמצעות חבילות לפי באז. יש את אותו פורמט כמו הארגומנט של שורת ה-build --package_path.

לדוגמה: המזהה של תהליך שרת Bazel.

% bazel info server_pid
1285

נתונים ספציפיים להגדרה

ייתכן שנתונים אלה יושפעו מאפשרויות התצורה שהועברו אל bazel info, לדוגמה --cpu, --compilation_mode וכו'. הפקודה info מקבלת את כל האפשרויות שקובעות ניתוח של תלות, מאחר שכמה מהן קובעות את מיקום ספריית הפלט של build, בחירת מהדר וכו'.

  • bazel-bin, bazel-testlogs, bazel-genfiles: מדווח על הנתיב המוחלט אל הספריות של bazel-* שבהן ממוקמות תוכניות שנוצרו על ידי ה-build. בדרך כלל, הם לא תמיד זהים לbazel-*סמלי הקישורים שנוצרו בספריית סביבת העבודה הבסיסית לאחר build מוצלח. עם זאת, אם הספרייה של סביבת העבודה זמינה לקריאה בלבד, לא ניתן ליצור קישורים ל-bazel-*. סקריפטים שמשתמשים בערך שמדווח על ידי bazel info, במקום בהנחה שהקיים של הסמל הסימבולי, יהיו חזקים יותר.
  • כל סביבת "Make". אם צוין הסימון --show_make_env, כל המשתנים בסביבת "Make" של התצורה הנוכחית יוצגו גם (כגון CC, GLIBC_VERSION וכדומה). אלה המשתנים שניגשים אליהם באמצעות התחביר $(CC) או varref("CC") שבתוך קובצי BUILD.

לדוגמה: מהדר C++ לתצורה הנוכחית. זהו המשתנה $(CC) בסביבה "Make", לכן יש צורך בסימון --show_make_env.

  % bazel info --show_make_env -c opt COMPILATION_MODE
  opt

לדוגמה: ספריית הפלט של bazel-bin עבור התצורה הנוכחית. זוהי פעולה נכונה גם במקרים שבהם לא ניתן ליצור את סמל ה-bazel-bin מסיבה כלשהי (למשל, אם אתם בונים מספרייה לקריאה בלבד).

% bazel info --cpu=piii bazel-bin
/var/tmp/_bazel_johndoe/fbd0e8a34f61ce5d491e3da69d959fe6/execroot/io_bazel/bazel-out/piii-opt/bin
% bazel info --cpu=k8 bazel-bin
/var/tmp/_bazel_johndoe/fbd0e8a34f61ce5d491e3da69d959fe6/execroot/io_bazel/bazel-out/k8-opt/bin

version ו---version

פקודת הגרסה מדפיסה פרטי גרסה של הקובץ הבינארי של בזל שנבנה, כולל רשימת השינויים שבה הוא נבנה והתאריך. הגדרות אלה שימושיות במיוחד כדי לקבוע אם העסק נמצא בבזל האחרון, או אם אתם מדווחים על באגים. חלק מהערכים המעניינים הם:

  • changelist: רשימת השינויים שבה הושקה הגרסה הזו של בזל.
  • label: תווית ההפצה של המופע הזה של "באזל", או "גרסת פיתוח", אם זו אינה בינארית חדשה. שימושי במיוחד כשמדווחים על באגים.

bazel --version, ללא ארגומנטים אחרים, תפלט את אותו פלט כמו bazel version --gnu_format, למעט ללא תופעות לוואי של אפשרות התחלתית של שרת Bazel או פתיחת האריזה של ארכיון השרת. אפשר להריץ את bazel --version מכל מקום – אין צורך בספרייה של סביבת עבודה.

mobile-install

הפקודה mobile-install מתקינה אפליקציות במכשירים ניידים. בשלב זה, יש תמיכה רק במכשירי Android שבהם פועל ART.

למידע נוסף, ראה התקנת לנייד.

האפשרויות הבאות נתמכות:

--incremental

אם היא מוגדרת, Bazel מנסה להתקין את האפליקציה בצורה מדורגת. כלומר, רק החלקים שהשתנו מאז ה-build האחרון. לא ניתן לעדכן את המשאבים שהופנו מ-AndroidManifest.xml, קוד מקור או משאבי Java (כגון המשאבים ש-Class.getResource() מפנה אליהם). אם דברים אלה משתנים, יש להשמיט אפשרות זו. בניגוד לרוחה של בזל ועקב מגבלות של פלטפורמת Android, אחריות המשתמש היא לדעת מתי הפקודה הזו טובה מספיק וכאשר מלאה נדרשת התקנה.

אם אתם משתמשים במכשיר עם גרסת Marshmallow ואילך, כדאי לשקול את הסימון --split_apks.

--split_apks

האם להשתמש ב-APKs מפוצלים כדי להתקין ולעדכן את האפליקציה במכשיר. פועלת רק במכשירים עם Marshmallow ואילך. הערה: הסימון --incremental לא נדרש כשמשתמשים ב---split_apks.

--start_app

הפעלת האפליקציה במצב נקי לאחר ההתקנה. שווה ערך ל---start=COLD.

--debug_app

בהמתנה לכלי לניפוי באגים לפני שמפעילים את האפליקציה במצב נקי לאחר ההתקנה. שווה ערך ל---start=DEBUG.

--start=_start_type_

כיצד יש להפעיל את האפליקציה לאחר התקנתה. _start_type_s נתמכים הם:

  • NO לא מפעיל את האפליקציה. זוהי ברירת המחדל.
  • COLD הפעלת האפליקציה ממצב נקי לאחר ההתקנה.
  • WARM משמר ומשחזר את מצב האפליקציה בהתקנות מצטברות.
  • DEBUGבהמתנה לכלי לניפוי באגים לפני שמפעילים את האפליקציה במצב נקי לאחר ההתקנה.

--adb=path

מציין את הקובץ הבינארי של adb לשימוש.

ברירת המחדל היא להשתמש ב-adb ב-Android SDK שצוין על ידי --android_sdk.

--adb_arg=serial

ארגומנטים נוספים לפונקציה adb. הן מופיעות לפני פקודת המשנה בשורת הפקודה. בדרך כלל הן משמשות לקביעת המכשיר שבו יש להתקין אותו. לדוגמה, כדי לבחור את המדמה או המכשיר של Android לשימוש:

% bazel mobile-install --adb_arg=-s --adb_arg=deadbeef

הפעלת adb בתור

adb -s deadbeef install ...

--incremental_install_verbosity=number

דרגת המלל עבור התקנה מצטברת. יש להגדיר כ-1 כדי שיומן ניפוי הבאגים יודפס במסוף.

dump

הפקודה dump מודפסת כדי ליצור Dump של המצב הפנימי של שרת בזל. פקודה זו מיועדת בעיקר לשימוש על ידי מפתחי Bazel, כך שהפלט של פקודה זו לא צוין, וכפופה לשינויים.

כברירת מחדל, הפקודה רק תדפיס הודעת עזרה הכוללת אפשרויות אפשריות לDumps של אזורים ספציפיים בבזל. כדי ליצור מצב פנימי, יש לציין לפחות אחת מהאפשרויות.

האפשרויות הבאות נתמכות:

  • --action_cache שומר תוכן של קובץ שמור של פעולה.
  • --packages שומר תוכן של מטמון חבילה.
  • --skyframe מצבי תרשים של תלות פנימית בבזל.
  • --rules מסכם את כלל הכללים עבור כל כלל וסיווג, כולל ספירות ופעולות. כלל זה חל גם על כללים מקוריים וגם על כללים של Starlark. אם מעקב זיכרון מופעל, צריכת הזיכרון של הכללים תודפס גם היא.
  • --skylark_memory משליך קובץ .gz תואם pprof לנתיב שצוין. כדי לבצע את הפעולה הזו, צריך להפעיל מעקב זיכרון.

מעקב אחר זיכרון

פקודות מסוימות של dump מחייבות מעקב אחר הזיכרון. כדי להפעיל את התכונה הזו, צריך להעביר ל-Bazel סימוני אתחול:

  • --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar
  • --host_jvm_args=-DRULE_MEMORY_TRACKER=1

ה-Java-agent נבדק ב-Bazel בכתובת third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar, לכן חשוב להתאים את $BAZEL למקום שבו אתה שומר את המאגר של Bazel.

חשוב לזכור להמשיך להעביר את האפשרויות האלה ל-Bazel עבור כל פקודה, אחרת השרת יופעל מחדש.

דוגמה:

    % bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar \
    --host_jvm_args=-DRULE_MEMORY_TRACKER=1 \
    build --nobuild <targets>

    # Dump rules
    % bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar \
    --host_jvm_args=-DRULE_MEMORY_TRACKER=1 \
    dump --rules

    # Dump Starlark heap and analyze it with pprof
    % bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar \
    --host_jvm_args=-DRULE_MEMORY_TRACKER=1 \
    dump --skylark_memory=$HOME/prof.gz
    % pprof -flame $HOME/prof.gz

analyze-profile

הפקודה analyze-profile מנתחת נתונים שנאספו בעבר במהלך ה-build באמצעות האפשרות --profile. הוא מספק מספר אפשרויות לביצוע ניתוח של ביצועי ה-build או ייצוא נתונים בפורמט שצוין.

האפשרויות הבאות נתמכות:

  • --dump מציג את כל הנתונים שנאספו בפורמט קריא לקריאה. עם זאת, הוא עדיין לא תומך בפורמטים אחרים.

לפרטי הפורמט ולעזרה בנושא שימוש, ראה פתרון בעיות בביצועים על ידי יצירת פרופיל.

canonicalize-flags

פקודה canonicalize-flags, שעורכת רשימה של אפשרויות לפקודת Bazel ומחזירה רשימה של אפשרויות בעלות אותה השפעה. רשימת האפשרויות החדשה היא קנונית. לדוגמה, שתי רשימות של אפשרויות עם אותה השפעה יהיו קנוניות לאותה רשימה חדשה.

ניתן להשתמש באפשרות --for_command כדי לבחור בין פקודות שונות. בשלב זה, רק build וtest נתמכים. אפשרויות שהפקודה הנתונה לא תומכת בהן גורמות לשגיאה.

לדוגמה:

  % bazel canonicalize-flags -- --config=any_name --test_tag_filters="-lint"
  --config=any_name
  --test_tag_filters=-lint

אפשרויות הפעלה

האפשרויות המתוארות בסעיף זה משפיעות על הפעלת המכונה הווירטואלית של Java המשמשת את תהליך שרת Bazel, והן חלות על כל הפקודות הבאות בטיפול על ידי השרת הזה. אם כבר קיים שרת Bazel ואפשרויות ההפעלה לא תואמות, הוא יופעל מחדש.

יש לציין את כל האפשרויות המתוארות בסעיף הזה באמצעות התחביר --key=value או --key value. כמו כן, האפשרויות האלה חייבות להופיע לפני השם של פקודת הבזל. יש להשתמש בקובץ startup --key=value כדי לרשום אותם בקובץ .bazelrc.

--output_base=dir

האפשרות הזו מחייבת ארגומנט נתיב, שחייב לציין ספרייה שניתן לכתוב בה. Bazel תשתמש במיקום הזה כדי לכתוב את כל הפלט שלו. בסיס הפלט הוא גם המפתח שבאמצעותו הלקוח מאתר את שרת באזל. בשינוי בסיס הפלט, משנים את השרת שיטפל בפקודה.

כברירת מחדל, בסיס הפלט נגזר משם ההתחברות של המשתמש מהשם של ספריית סביבת העבודה (למעשה, התקציר של MD5 שלו), כך שערך טיפוסי נראה כך: /var/tmp/google/_bazel_johndoe/d41d8cd98f00b204e9800998ecf8427e.

למשל:

 OUTPUT_BASE=/var/tmp/google/_bazel_johndoe/custom_output_base
% bazel --output_base ${OUTPUT_BASE}1 build //foo  &  bazel --output_base ${OUTPUT_BASE}2 build //bar

בפקודה זו, שתי פקודות Bazel פועלות בו-זמנית (בגלל אופרטור המעטפת &amp;), וכל אחת מהן משתמשת במופע שרת Bazel אחר (בגלל בסיסי הפלט השונים). לעומת זאת, אם נעשה שימוש בבסיס הפלט שהוגדר כברירת מחדל בשתי הפקודות, שתי הבקשות יישלחו לאותו שרת, דבר שיטפל בהן ברצף: קודם כל בנייה של //foo ואחריה build מצטבר של //bar.

--output_user_root=dir

מצביע אל ספריית הבסיס שבה נוצרים בסיסי הפלט וההתקנה. הספרייה לא חייבת להיות קיימת או להיות בבעלות המשתמש שמתקשר. בעבר, הדבר הצביע על ספרייה משותפת למשתמשים שונים, אבל זה לא הותאם יותר. ייתכן שהדבר יתאפשר לאחר שגורם מס' 11100 יטופל.

אם מציינים את האפשרות --output_base, היא מבטלת את החישוב ב---output_user_root כדי לחשב את בסיס הפלט.

מיקום הבסיס של ההתקנה מחושב על סמך --output_user_root, בנוסף לזהות ה-MD5 של הקבצים הבינאריים המוטמעים של Bazel.

אם יש מיקום טוב יותר בפריסת מערכת הקבצים, אפשר להשתמש באפשרות --output_user_root כדי לבחור מיקום בסיס חלופי לכל פלטי בזל:

--server_javabase=dir

מציינת את המכונה הווירטואלית של Java שבה מופעלת הכרטיס עצמו. הערך חייב להיות נתיב לספרייה המכילה JDK או JRE. התווית לא יכולה להיות תווית. האפשרות הזו צריכה להופיע לפני כל פקודת Bazel, לדוגמה:

  % bazel --server_javabase=/usr/local/buildtools/java/jdk11 build //foo

הסימון הזה לא משפיע על מכונות ה-JVM שמשמשות את תהליכי המשנה של Bazel, כמו אפליקציות, בדיקות, כלים וכו'. במקום זאת, יש להשתמש באפשרויות build --Javabase או --host_Javabase.

השם של הדיווח הזה נקרא בעבר--host_javabase (לעיתים מכונה גם 'הצד השמאלי')--host_javabase ), אך שינינו את שמו כדי למנוע בלבול עם סימון ה-build--host_Javabase (לעיתים מכונה גם 'צד ימין'--host_javabase ).

--host_jvm_args=string

מציינת אפשרות להפעלה שיש להעביר למכונה הווירטואלית של Java שבה מופעלת הכרטיס עצמו. ניתן להשתמש במאפיין הזה כדי להגדיר את גודל הערימה, לדוגמה:

  % bazel --host_jvm_args="-Xss256K" build //foo

ניתן להשתמש באפשרות הזו מספר פעמים עם ארגומנטים נפרדים. שימו לב: לעתים רחוקות בלבד יש להגדיר את הסימון הזה. תוכל גם להעביר רשימת רווחים מופרדים ברווחים. כל אחד מהם יפורש כארגומנט JVM נפרד, אך בקרוב התכונה הזו תוצא משימוש.

השינוי הזה לא משפיע על מכשירי JVM שמשמשים תהליכי משנה של Bazel: אפליקציות, בדיקות, כלים וכו'. כדי להעביר אפשרויות של JVM לתוכניות הפעלה של Java, בין אם הן מופעלות על ידי bazel run ובין אם הן מיועדות לשורת הפקודה, עליך להשתמש בארגומנט של --jvm_flags שבו כל java_binary ו-java_test תוכניות. אפשרות נוספת היא להשתמש בבדיקות bazel test --test_arg=--jvm_flags=foo ....

--host_jvm_debug

אפשרות זו גורמת למכונה הווירטואלית של Java להמתין לחיבור מכלי ניפוי באגים תואם ל-JDWP לפני הקריאה לשיטה הראשית של באז עצמה. תכונה זו מיועדת בעיקר לשימוש על ידי מפתחי Bazel.

--autodetect_server_javabase

אפשרות זו גורמת ל-Bazel לחפש באופן אוטומטי JDK מותקן בזמן ההפעלה, ולחזור ל-JRE המותקן אם ה-JRE המוטמע לא זמין. ניתן להשתמש ב---explicit_server_javabase כדי לבחור JRE מפורש שיריץ את בזל.

--batch

מצב אצווה גורם ל-Bazel לא להשתמש במצב לקוח/שרת רגיל, אלא הוא מפעיל תהליך Bazel של Java עבור פקודה יחידה, ששימש עבור סמנטיקה צפויה יותר בכל הנוגע לטיפול בסימנים, לבקרת משרות ולירושה משתנה בסביבה, והוא נחוץ להפעלת בזל בכלא חרוט.

מצב האצווה שומר על הסמנטיקה הנכונה של התור בתור אותו פלט_base. כלומר, הפעלות בו-זמנית יעובדו לפי סדר, ללא חפיפה. אם מצב באצול מופעל בלקוח עם שרת פועל, תחילה הוא הורג את השרת לפני עיבוד הפקודה.

Bazel תפעל לאט יותר במצב אצווה, או בחלופות שתוארו למעלה. הסיבה לכך היא, בין השאר, שמטמון קובצי ה-build מאוחסן בזיכרון, כך שהוא לא נשמר בין הפעלות אצווה רציפות. לכן, השימוש במצב אצווה בדרך כלל הגיוני יותר במקרים שבהם הביצועים פחות קריטיים, כגון גרסאות רציף.

--max_idle_secs=n

אפשרות זו מציינת כמה זמן, בשניות, תהליך שרת Bazel צריך להמתין לאחר בקשת הלקוח האחרונה, לפני שהוא יוצא. ערך ברירת המחדל הוא 10800 (3 שעות). --max_idle_secs=0 יגרום לתהליך של שרת בזל להמשיך ללא הגבלה.

ניתן להשתמש באפשרות זו בסקריפטים שמופעלים על ידי Bazel כדי להבטיח שלא יעזבו תהליכי שרת של Bazel במחשב של המשתמש כאשר הם לא יפעלו בדרך אחרת. לדוגמה, סקריפט לשליחה מראש עשוי לרצות להפעיל את bazel query, כדי להבטיח שהשינוי הממתין למשתמש לא יוצר יחסי תלות בלתי רצויים. עם זאת, אם המשתמש לא ביצע לאחרונה build בסביבת העבודה הזו, לא כדאי שהסקריפט שנשלח מראש יתחיל שרת Bazel רק שהוא יישאר במצב לא פעיל למשך שארית היום. על ידי ציון ערך קטן של --max_idle_secs בבקשת השאילתה, הסקריפט יכול להבטיח שאם הוא גרם לשרת חדש להתחיל, השרת יצא באופן מיידי, אבל אם במקום זאת, כבר היה שרת פעיל, הוא ימשיך לפעול עד שלא יהיה פעיל במשך הזמן הרגיל. כמובן, הטיימר לא פעיל של השרת הקיים יאופס.

--[no]shutdown_on_low_sys_mem

אם האפליקציה מופעלת ומוגדר משך זמן חיובי, --max_idle_secs לאחר ששרת ה-build לא פעיל במשך זמן מה, יש לכבות את השרת כשאין מספיק זיכרון בזיכרון. Linux בלבד.

בנוסף להרצת בדיקת חוסר פעילות התואמת ל-max_idle_secs, שרת ה-build יתחיל לעקוב אחר זיכרון המערכת הזמין לאחר שהשרת לא יהיה פעיל למשך זמן מה. אם זיכרון המערכת הזמין הולך ואוזל, השרת ייסגר.

--[no]block_for_lock

אם תופעל, Bazel תמתין לפקודות אחרות של Bazel שמחזיקים בנעילת השרת לפני שהוא מתקדם. אם ההגדרה מושבתת, Bazel תצא ממצב שגיאה אם היא לא תצליח להשיג את הנעילה ולהמשיך מיד.

ייתכן שהמפתחים ישתמשו באפשרות הזו בבדיקות מראש כדי להימנע מממתינים ארוכים שנגרמו על ידי פקודת Bazel אחרת באותו לקוח.

--io_nice_level=n

קביעת רמת דירוג מ-0 עד 7 לתזמון IO המתאים ביותר. 0 הוא בעדיפות הגבוהה ביותר, 7 הוא הנמוך ביותר. מתזמן ההצגה עשוי לכבד את עדיפות 4 בלבד. המערכת תתעלם מהערכים שליליים.

--batch_cpu_scheduling

אפשר להשתמש בתזמון batch של יחידת העיבוד המרכזית (CPU) של Bazel. מדיניות זו שימושית עבור עומסי עבודה שאינם אינטראקטיביים, אבל לא רוצים להוריד את הערך הנחמד שלהם. ראה 'man 2 sched_setScheduler'. המדיניות הזו עשויה לספק אינטראקציה טובה יותר על המערכת במקרה של תפוקת Bazel.

אפשרויות שונות

--[no]announce_rc

קובעת אם Bazel מכריז על אפשרויות פקודה שנקראות מקובץ bazelrc בעת ההפעלה. (אפשרויות אתחול הוכרזו ללא תנאי.)

--color (yes|no|auto)

האפשרות הזו קובעת אם Bazel תשתמש בצבעים כדי להדגיש את הפלט שלה על המסך.

אם האפשרות הזו מוגדרת כ-yes, פלט הצבע יופעל. אם האפשרות הזו מוגדרת כ-auto, Bazel תשתמש בפלט הצבע רק אם הפלט נשלח למסוף והמשתנה הסביבתי TERM מוגדר לערך שאינו dumb, emacs או xterm-mono. אם האפשרות הזו מוגדרת כ-no, פלט הצבע מושבת, לא משנה אם הפלט מגיע למסוף, וללא קשר להגדרה של משתנה הסביבה TERM.

--config=name

בוחר קטע config נוסף מקובצי ה-rc; עבור ה-command הנוכחי, הוא כולל גם את האפשרויות מתוך command:name, אם קיים קטע כזה. אפשר לציין כמה פעמים כדי להוסיף סימונים מכמה קטעי config. הרחבות יכולות להתייחס להגדרה אחרת (לדוגמה, אפשר לשרשר הרחבות).

--curses (yes|no|auto)

אפשרות זו קובעת אם Bazel תשתמש בפקדי הסמן בפלט המסך. כתוצאה מכך מתקבלים פחות נתונים לגלילה, וזרם פלט קומפקטי וקל יותר לקריאה מ-Bazel. זה עובד היטב עם --color.

אם האפשרות הזו מוגדרת כ-yes, השימוש בפקדי הסמן מופעל. אם האפשרות הזו מוגדרת כ-no, השימוש בפקדי הסמן מושבת. אם האפשרות הזו מוגדרת כ-auto, שימוש בפקדי הסמן יופעל באותם תנאים כמו עבור --color=auto.

--[no]show_timestamps

אם צוין, חותמת זמן נוספת לכל הודעה שנוצרת על ידי באזל, המציינת את השעה שבה הוצגה ההודעה.