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

דף זה מכסה את האפשרויות הזמינות בפקודות Bazel שונות, כגון bazel build, bazel run וbazel test. דף זה נלווה לרשימת הפקודות של Bazel&33;s בקטע Build with Bazel.

תחביר היעד

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

אפשרויות

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

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

מיקום החבילה

--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 מספריות מתחת לסביבת העבודה של הבסיס. לדוגמה, אם משתמשים ברכיב נתיב החבילה ., ואז מוגדר כ-CD בספרייה /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

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

--output_filter=regex

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

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

`--פלט_filter='^//(first/project|sec/project):'`	הצגת הפלט של החבילות שצוינו.
`--פלט_filter='^//(?!(first/bad_project|two/bad_project):).)*$'`	אין להציג פלט עבור החבילות שצוינו.
`--פלט_filter=`	הצגת הכול.
`--פלט_filter=DONT_MATCH_ANYTHING`	לא להציג שום דבר.

סימונים לכלים

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

--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

באפשרות זו מתקבל ארגומנט שמועבר ל-linker עבור קובצי המקור ש: היא דומה לאפשרות --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&d; היא רק מסירה מידע על תוצאות ניפוי הבאגים. אם מסיבה כלשהי אתם רוצים להסיר את כל הסמלים, ולא רק ניפוי באגים, תצטרכו להשתמש באפשרות --strip-all של ld&#39. לשם כך, צריך להעביר את --linkopt=-Wl,--strip-all אל Bazel. כמו כן, חשוב לזכור שהגדרת הסימון ב-Bazel&--strip3 תבטל את --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 מאפשרת יצירה של פלט פרופיל FDO (אופטימיזציה ממשוב) כאשר מתבצע הממשק הבינארי של C/C++. עבור GCC, הארגומנט שסופק משמש כקידומת ספרייה לעץ ספריית קבצים עבור אובייקטים של קובצי .gcda המכיל פרטי פרופיל עבור כל קובץ .o

לאחר יצירת עץ נתוני הפרופיל, יש לכווץ את עץ הפרופיל ולמסור אותו לאפשרות --fdo_optimize=profile-zip

לגבי מהדר LLVM, הארגומנט הוא גם הספרייה שבה נמצאים קובצי הנתונים הגולמיים של פרופיל 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 בו-זמנית.

--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 המשמשת לביצוע כלים הדרושים במהלך build. ערך ברירת המחדל הוא remotejdk_11.

--jvmopt=jvm-option

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

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

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

--javacopt=javac-option

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

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

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

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

  -source 8 -target 8 -encoding UTF-8

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

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

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

סמנטי

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

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

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

• המשמעות של fastbuild היא לבנות מהר ככל האפשר: מומלץ ליצור מידע מינימלי על ניפוי באגים (-gmlt -Wl,-S) ולא לבצע אופטימיזציה. זוהי אפשרות ברירת המחדל. הערה: לא יוגדר -DNDEBUG.
• dbg פירושו build עם ניפוי באגים (-g), כדי שתוכלו להשתמש ב-gdb (או בכלי לניפוי באגים אחר).
• opt אומר שה-build עם אופטימיזציה מופעל ו-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 ייווצר לפחות פעמיים: פעם אחת לכל מעבד (CPU) שצוין ב---fat_apk_cpu עבור הכלל android_binary, ופעם אחת למעבד (CPU) שצוין ב---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++ יקושרו באופן דינמי, בזמן אינטראקציה עם מאפיין הקישור הסטטי בכללי בנייה.

מצבים:

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

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

מפעילה את Fission, שכותב מידע על ניפוי באגים באמצעות C++ לקובצי .dwo ייעודיים במקום קובצי .o,

מוגדר ל-[dbg][,opt][,fastbuild] (דוגמה: --fission=dbg,fastbuild) אפשרות זו שימושית בהגדרות בזלת. בתקן yes אפשר להשתמש ב-Fision באופן כללי. בתקן 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

אפשרות זו מציינת את המיקום של חבילת המהדרים מוצלבים שבה ייעשה שימוש לכל הידור C++ במהלך build. Bazel תבדוק את המיקום בקובץ CROSSTOOL ותשתמש בה כדי לקבוע באופן אוטומטי את ההגדרות עבור --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 כללים. אפשרות זו שימושית אם ליעדים אחרים במבנה יש צורך בכלי חוצה אחר. הגדרת ברירת המחדל היא שימוש בכלי להצלבה שנוצר על ידי הכלל android_ndk_repository בקובץ WORKSPACE. מידע נוסף זמין ב---fat_apk_cpu.

--compiler=version

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

--android_sdk=label

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

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

--java_toolchain=label

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

--host_java_toolchain=label

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

--javabase=(label)

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

--host_javabase=label

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

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

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

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

--spawn_strategy=strategy

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

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

--strategy mnemonic=strategy

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

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

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

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

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

--genrule_strategy=strategy

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

--jobs=n (-j)

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

--progress_report_interval=n

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

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

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

--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 ומספר הליבות של המעבד (CPU) ישירות מהתצורה של המערכת המקומית.

--[no]build_runfile_links

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

כשבדיקות (או אפליקציות) מתבצעות, התלות של הנתונים בזמן הריצה נאספים במקום אחד. בעץ Bazel's& במהלך ביצוע הבדיקה, אפשר לגשת לקובצי ה-ריצה באמצעות נתיבים בצורה $TEST_SRCDIR/workspace/packagename/filename. עץ ה-runfiles מוודא שלבדיקות יש גישה לכל הקבצים שבהם יש להם תלות מוצהרת, ולא דברים נוספים. כברירת מחדל, עץ ה-runfiles מיושם על ידי בניית קבוצה של קישורים סימבוליים לקבצים הנדרשים. ככל שקבוצת הקישורים הולכת וגדלה, כך עולה העלות של הפעולה הזו, ובמבנים גדולים מסוימים היא יכולה לתרום באופן משמעותי לזמן הבנייה הכולל, במיוחד מפני שלכל בדיקה (או אפליקציה) מסוימים נדרש עץ Runruns משלה.

--[no]build_runfile_manifests

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

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

--[no]discard_analysis_cache

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

--[no]keep_going (-k)

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

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

--[no]use_ijars

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

--[no]interface_shared_objects

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

בחירת פלט

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

--[no]build

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

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

--[no]build_tests_only

אם ציינתם זאת, Bazel תיצור רק את מה שדרוש כדי להפעיל את כללי *_test ו-test_suite, שלא סוננו עקב גודל, זמן קצוב לתפוגה, תג או שפה. אם צוין, 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

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

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

--save_temps

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

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

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

--build_tag_filters=tag[,tag]*

אם צוין, בזאר יבנה רק יעדים שיש להם לפחות תג חובה אחד (אם צוין אחד מהם) ואין לו תגים מוחרגים. מסנן 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 מוגדר גם כן) רק מטרות עסקיות עם זמן קצוב לתפוגה שהוגדר. המסנן 'זמן קצוב לתפוגה של בדיקה' מצוין כרשימה מופרדת בפסיקים של ערכים מותרים של זמן קצוב לתפוגה (קצר, בינוני, ארוך או נצחי), שלפניהם מופיע הסימן '&&339. למידע נוסף על תחביר, ראו --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=string[,string]*

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

  % bazel test --test_lang_filters=foo,bar //baz/...

יבדוק רק מופעים של foo_test או של bar_test ב-//baz/..., בעוד

  % bazel test --test_lang_filters=-foo,-bar //baz/...

תבדוק את כל היעדים ב-//baz/... מלבד המופעים foo_test ו-bar_test.