دستورات و گزینه ها

این صفحه گزینه هایی را پوشش می دهد که با دستورات مختلف Bazel در دسترس هستند، مانند bazel build bazel، bazel run و bazel test . این صفحه همراه لیست دستورات Bazel در Build with Bazel است.

نحو هدف

برخی از دستورات، مانند build یا test ، می توانند بر روی لیستی از اهداف عمل کنند. آنها از نحوی استفاده می‌کنند که انعطاف‌پذیرتر از برچسب‌ها است، که در تعیین اهداف برای ساخت مستند شده است.

گزینه ها

بخش‌های زیر گزینه‌های موجود در طول ساخت را توضیح می‌دهند. هنگامی که --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 از دایرکتوری‌های زیر فضای کاری bazel استفاده کنید، ممکن است غیرمنتظره رفتار کند. به عنوان مثال، اگر از عنصر Package-path استفاده می . و سپس cd را در دایرکتوری /home/bob/clients/bob_client/bazel/foo قرار دهید، بسته ها از پوشه /home/bob/clients/bob_client/bazel/ /home/bob/clients/bob_client/bazel/foo حل می شوند.

اگر از یک مسیر بسته غیر پیش‌فرض استفاده می‌کنید، آن را در فایل پیکربندی Bazel خود برای راحتی مشخص کنید.

Bazel نیازی به وجود هیچ بسته ای در دایرکتوری فعلی ندارد ، بنابراین اگر همه بسته های لازم را در جای دیگری در مسیر بسته پیدا کنید، می توانید از یک فضای کاری خالی bazel یک ساخت انجام دهید.

مثال: ساختن از یک مشتری خالی

  % 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 است، به طوری که به طور پیش فرض بررسی visibility انجام می شود.

--output_filter= regex

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

در اینجا چند مقدار معمولی برای این گزینه آورده شده است:

پرچم های ابزار

این گزینه ها کنترل می کنند که 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 -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

قوانین ساخت همچنین می توانند گزینه های پیوند را در ویژگی های خود مشخص کنند. تنظیمات این گزینه همیشه اولویت دارند. همچنین به cc_library.linkopts مراجعه کنید.

--strip (always|never|sometimes)

این گزینه با فراخوانی پیوند دهنده با گزینه -Wl,--strip-debug تعیین می کند که آیا Bazel اطلاعات اشکال زدایی را از همه باینری ها و کتابخانه های مشترک حذف خواهد کرد. --strip=always یعنی همیشه اطلاعات اشکال زدایی را حذف کنید. --strip=never یعنی هرگز اطلاعات اشکال زدایی را پاک نکنید. مقدار پیش‌فرض --strip=sometimes به معنای نوار است اگر --compilation_mode fastbuild باشد.

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

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

گزینه --strip با گزینه --strip-debug ld مطابقت دارد: فقط اطلاعات اشکال زدایی را حذف می کند. اگر به دلایلی می خواهید همه نمادها را حذف کنید، نه فقط نمادهای اشکال زدایی ، باید از گزینه --strip-all ld استفاده کنید، که می توانید با عبور --linkopt=-Wl,--strip-all به Bazel این کار را انجام دهید. همچنین توجه داشته باشید که با تنظیم پرچم بازل ---strip، --strip --linkopt=-Wl,--strip-all می شود، بنابراین باید فقط یکی یا دیگری را تنظیم کنید.

اگر فقط یک باینری می‌سازید و می‌خواهید همه نمادها حذف شوند، می‌توانید --stripopt=--strip-all را نیز ارسال کنید و صراحتاً //foo:bar.stripped نسخه هدف را بسازید. همانطور که در بخش --stripopt توضیح داده شد، این یک عمل نواری را پس از پیوند باینری نهایی اعمال می‌کند نه اینکه در تمام اقدامات پیوند ساخت‌وساز گنجانده شود.

--stripopt= strip-option

این یک گزینه اضافی برای ارسال به دستور strip هنگام تولید یک *.stripped باینری است. پیش فرض -S -p است. این گزینه را می توان چندین بار استفاده کرد.

--fdo_instrument= profile-output-dir

گزینه --fdo_instrument تولید خروجی نمایه FDO (بهینه سازی هدایت شده بازخورد) را هنگامی که باینری ساخته شده C/C++ اجرا می شود، فعال می کند. برای GCC، آرگومان ارائه شده به عنوان پیشوند دایرکتوری برای درخت دایرکتوری فایل per-object از فایل های gcda. که حاوی اطلاعات نمایه برای هر فایل .o است، استفاده می شود.

هنگامی که درخت داده پروفایل تولید شد، درخت پروفایل باید فشرده شود و در اختیار گزینه --fdo_optimize= profile-zip قرار گیرد تا کامپایل بهینه شده توسط FDO فعال شود.

برای کامپایلر LLVM، آرگومان همچنین دایرکتوری است که فایل(های) داده خام پروفایل LLVM در آن ریخته می شود. به عنوان مثال: --fdo_instrument= /path/to/rawprof/dir/ .

گزینه های --fdo_instrument و --fdo_optimize را نمی توان همزمان استفاده کرد.

--fdo_optimize= profile-zip

گزینه --fdo_optimize استفاده از اطلاعات نمایه فایل هر شی را برای انجام بهینه سازی های FDO (بهینه سازی هدایت شده با بازخورد) در هنگام کامپایل امکان پذیر می کند. برای شورای همکاری خلیج فارس، آرگومان ارائه شده، فایل فشرده حاوی درخت فایل های تولید شده قبلی از فایل های .gcda است که حاوی اطلاعات نمایه برای هر فایل .o است.

از طرف دیگر، آرگومان ارائه شده می تواند به نمایه خودکار مشخص شده توسط پسوند afdo اشاره کند.

برای کامپایلر LLVM، آرگومان ارائه شده باید به فایل خروجی نمایه LLVM نمایه شده که توسط ابزار llvm-profdata تهیه شده است اشاره کند و باید پسوند .profdata داشته باشد.

گزینه های --fdo_instrument و --fdo_optimize را نمی توان همزمان استفاده کرد.

--java_language_version= version

این گزینه نسخه منابع جاوا را مشخص می کند. مثلا:

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

تنها ساختارهای سازگار با مشخصات جاوا 8 را کامپایل می کند و اجازه می دهد. مقدار پیش‌فرض 11 است. --> مقادیر ممکن عبارتند از: 8، 9، 10، 11، 14، و 15 و ممکن است با ثبت زنجیره‌های ابزار جاوای سفارشی با استفاده از default_java_toolchain گسترش یابند.

--tool_java_language_version= version

نسخه زبان جاوا برای ساخت ابزارهایی که در حین ساخت اجرا می شوند استفاده می شود. مقدار پیش فرض 11 است.

--java_runtime_version= version

این گزینه نسخه JVM را برای اجرای کد و اجرای تست ها مشخص می کند. مثلا:

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

JDK 11 را از یک مخزن راه دور دانلود می کند و برنامه جاوا را با استفاده از آن اجرا می کند.

مقدار پیش فرض 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 ارسال شوند. می توان آن را با یک آرگومان بزرگ یا چندین بار با آرگومان های فردی استفاده کرد. مثلا:

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

از VM سرور برای راه‌اندازی همه باینری‌های جاوا استفاده می‌کند و اندازه پشته راه‌اندازی ماشین مجازی را روی ۲۵۶ مگابایت تنظیم می‌کند.

--javacopt= javac-option

این گزینه اجازه می دهد تا آرگومان های گزینه به javac ارسال شوند. می توان آن را با یک آرگومان بزرگ یا چندین بار با آرگومان های فردی استفاده کرد. مثلا:

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

یک java_binary با اطلاعات اشکال زدایی پیش فرض javac (به جای پیش فرض bazel) بازسازی می کند.

این گزینه بعد از گزینه های پیش فرض داخلی Bazel برای javac و قبل از گزینه های per-rule به javac منتقل می شود. آخرین مشخصات هر گزینه javac برنده است. گزینه های پیش فرض جاواک عبارتند از:

  -source 8 -target 8 -encoding UTF-8

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

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

• off به این معنی است که بررسی غیرفعال است.
• warn به این معنی است که javac برای هر وابستگی مستقیم گمشده، هشدارهای استاندارد جاوا از نوع [strict] ایجاد می کند.
• default ، strict و error ، همگی میانگین جاواک به‌جای اخطار، خطا ایجاد می‌کنند و در صورت یافتن وابستگی‌های مستقیم گمشده، هدف فعلی ساخته نمی‌شود. این نیز رفتار پیش فرض زمانی است که پرچم مشخص نشده باشد.

معناشناسی بسازید

این گزینه ها بر دستورات ساخت و/یا محتوای فایل خروجی تأثیر می گذارد.

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

گزینه --compilation_mode (اغلب به -c کوتاه می شود، به خصوص -c opt ) آرگومان fastbuild ، dbg یا opt را می گیرد و بر گزینه های مختلف تولید کد C/C++ مانند سطح بهینه سازی و کامل بودن جداول اشکال زدایی تأثیر می گذارد. . Bazel از یک دایرکتوری خروجی متفاوت برای هر حالت کامپایل مختلف استفاده می کند، بنابراین می توانید بدون نیاز به بازسازی کامل هر بار بین حالت ها جابجا شوید.

• fastbuild به معنای ساخت سریع‌ترین سرعت ممکن است: حداقل اطلاعات اشکال‌زدایی را تولید کنید ( -gmlt -Wl,-S ) و بهینه‌سازی نکنید. این پیش فرض است. توجه: -DNDEBUG تنظیم نخواهد شد.
• dbg به معنای ساخت با اشکال زدایی فعال ( -g ) است، به طوری که می توانید از gdb (یا اشکال زدایی دیگر) استفاده کنید.
• opt به معنای ساخت با فعال بهینه سازی و با فراخوانی assert() غیر فعال است ( -O2 -DNDEBUG ). اطلاعات اشکال زدایی در حالت opt ایجاد نمی شود مگر اینکه --copt -g را نیز پاس کنید.

--cpu= cpu

این گزینه معماری CPU مورد نظر را برای کامپایل کردن باینری ها در طول ساخت مشخص می کند.

--action_env= VAR=VALUE

مجموعه ای از متغیرهای محیطی موجود در طول اجرای تمام اقدامات را مشخص می کند. متغیرها را می توان با نام مشخص کرد، در این صورت مقدار از محیط فراخوانی گرفته می شود، یا با جفت name=value که مقدار را مستقل از محیط فراخوانی تعیین می کند.

این پرچم --action_env را می توان چندین بار مشخص کرد. اگر مقداری به یک متغیر در چندین پرچم --action_env اختصاص داده شود، آخرین انتساب برنده می شود.

--experimental_action_listener= label

گزینه experimental_action_listener به Bazel دستور می دهد تا از جزئیات قانون action_listener مشخص شده توسط label برای درج extra_actions در نمودار ساخت استفاده کند.

--[no]experimental_extra_action_top_level_only

اگر این گزینه روی true تنظیم شود، اقدامات اضافی مشخص شده توسط گزینه خط فرمان --experimental_action_listener فقط برای اهداف سطح بالا برنامه ریزی می شود.

--experimental_extra_action_filter= regex

گزینه experimental_extra_action_filter به 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]*

پردازنده‌هایی برای ساخت کتابخانه‌های C/C++ در بخش‌های android_binary deps سایر قوانین C/C++ تحت تأثیر قرار نمی گیرند. به عنوان مثال، اگر یک cc_library در عمق های انتقالی یک قانون android_binary و یک قانون deps cc_binary شود، cc_library حداقل دو بار ساخته می شود: یک بار برای هر CPU مشخص شده با --fat_apk_cpu برای قانون android_binary ، و یک بار برای CPU مشخص شده با --cpu برای قانون cc_binary .

پیش فرض armeabi-v7a است.

برای هر CPU مشخص شده با --fat_apk_cpu یک فایل .so ایجاد و در APK بسته بندی می شود. نام فایل .so نام قانون android_binary را با "lib" پیشوند می کند. برای مثال، اگر نام android_binary "foo" باشد، پس فایل libfoo.so است.

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

در صورت وجود، هر فایل C++ با یک برچسب یا یک مسیر اجرایی که با یکی از عبارات regex گنجانده شده مطابقت داشته باشد و با هیچ یک از عبارات حذف مطابقت نداشته باشد، با گزینه های داده شده ساخته می شود. تطبیق برچسب از شکل متعارف برچسب استفاده می کند (یعنی // package : label_name ).

مسیر اجرا، مسیر نسبی دایرکتوری فضای کاری شما از جمله نام پایه (شامل پسوند) فایل C++ است. همچنین شامل هر پیشوند وابسته به پلت فرم است.

برای تطبیق فایل های تولید شده (مانند خروجی های سبک) Bazel فقط می تواند از مسیر اجرا استفاده کند. در این مورد regexp نباید با '//' شروع شود زیرا با هیچ مسیر اجرایی مطابقت ندارد. نام بسته ها را می توان به این صورت استفاده کرد: --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 arcs گزینه های -O0 و -fprofile-arcs را به خط فرمان اضافه می کند. کامپایلر C++ برای همه فایل‌های .cc در //foo/ به جز file.cc

--dynamic_mode= mode

تعیین می کند که آیا باینری های ++C به صورت پویا پیوند داده می شوند و با ویژگی linkstatic در قوانین ساخت تعامل دارند یا خیر.

حالت ها:

• auto : به حالت وابسته به پلت فرم ترجمه می شود. default برای لینوکس و off برای cygwin.
• default : به bazel اجازه می‌دهد انتخاب کند که آیا پیوندی پویا داشته باشد یا خیر. برای اطلاعات بیشتر به linkstatic مراجعه کنید.
• fully : همه اهداف را به صورت پویا پیوند می دهد. این امر زمان پیوند را سرعت می بخشد و اندازه باینری های حاصل را کاهش می دهد.
• off : همه اهداف را در حالت عمدتاً ایستا پیوند می دهد. اگر -static در linkopts تنظیم شود، اهداف به کاملا ثابت تغییر می کنند.

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

Fission را فعال می‌کند، که اطلاعات اشکال‌زدایی C++ را به جای فایل‌های .o در فایل‌های اختصاصی dwo می‌نویسد، جایی که در غیر این صورت می‌رفت. این به طور قابل توجهی اندازه ورودی لینک ها را کاهش می دهد و می تواند زمان پیوند را کاهش دهد.

وقتی روی [dbg][,opt][,fastbuild] (مثال: --fission=dbg,fastbuild )، Fission فقط برای حالت‌های کامپایل مشخص شده فعال می‌شود. این برای تنظیمات bazelrc مفید است. وقتی روی yes تنظیم شود، Fission به صورت جهانی فعال می شود. وقتی روی no تنظیم شود، Fission به طور کلی غیرفعال می شود. پیش فرض no است.

--force_ignore_dash_static

اگر این پرچم تنظیم شود، هر گزینه -static در پیوندهای فایل های BUILD قوانین cc_* نادیده گرفته می شود. این فقط به عنوان یک راه حل برای ساخت های سخت سازی 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++ در طول ساخت استفاده شود. Bazel در آن مکان به دنبال یک فایل CROSSTOOL می گردد و از آن برای تعیین خودکار تنظیمات --compiler استفاده می کند.

--host_crosstool_top= label

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

--apple_crosstool_top= label

ابزار متقابلی که برای کامپایل کردن قواعد C/C++ در قسمت‌های انتقالی قوانین deps *، ios * و apple * استفاده می‌شود. برای آن اهداف، این پرچم --crosstool_top را بازنویسی می کند.

--android_crosstool_top= label

ابزار متقابلی که برای کامپایل کردن قوانین C/C++ در android_binary deps می‌شود. این در صورتی مفید است که سایر اهداف در ساخت به یک crosstool متفاوت نیاز داشته باشند. پیش فرض استفاده از ابزار متقابل ایجاد شده توسط قانون android_ndk_repository در فایل WORKSPACE است. --fat_apk_cpu را نیز ببینید.

--compiler= version

این گزینه نسخه کامپایلر C/C++ (مانند gcc-4.1.0 ) را مشخص می کند که برای کامپایل کردن باینری ها در طول ساخت استفاده شود. اگر می خواهید با یک crosstool سفارشی بسازید، باید به جای تعیین این پرچم از یک فایل CROSSTOOL استفاده کنید.

--android_sdk= label

این گزینه زنجیره ابزار Android SDK/platform و کتابخانه زمان اجرا اندروید را مشخص می کند که برای ساختن هر قانون مرتبط با Android استفاده می شود.

اگر یک قانون android_sdk_repository در فایل WORKSPACE تعریف شده باشد، Android SDK به طور خودکار انتخاب می شود.

--java_toolchain= label

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

--host_java_toolchain= label

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

--javabase=( label )

این گزینه برچسب نصب پایه جاوا را برای استفاده برای اجرای bazel، تست bazel و برای باینری های جاوا که توسط قوانین java_binary و java_test ساخته شده اند تنظیم می کند. JAVABASE و JAVA "Make" از این گزینه مشتق شده اند.

--host_javabase= label

این گزینه برچسب نصب پایه جاوا را برای استفاده در پیکربندی میزبان تنظیم می کند، به عنوان مثال برای ابزارهای ساخت میزبان از جمله JavaBuilder و Singlejar.

این کامپایلر جاوا را که برای کامپایل فایل های منبع جاوا استفاده می شود انتخاب نمی کند. کامپایلر را می توان با تنظیمات گزینه --java_toolchain انتخاب کرد.

استراتژی اجرا

این گزینه ها بر نحوه اجرای ساخت توسط Bazel تأثیر می گذارد. آنها نباید هیچ تاثیر قابل توجهی بر روی فایل های خروجی تولید شده توسط بیلد داشته باشند. به طور معمول تأثیر اصلی آنها روی سرعت ساخت است.

--spawn_strategy= strategy

این گزینه مکان و نحوه اجرای دستورات را کنترل می کند.

• standalone باعث می شود که دستورات به عنوان زیر فرآیندهای محلی اجرا شوند. این مقدار منسوخ شده است. لطفا به جای آن از local استفاده کنید.
• sandboxed باعث می شود که دستورات در داخل یک جعبه شنی در ماشین محلی اجرا شوند. این مستلزم آن است که همه فایل‌های ورودی، وابستگی‌های داده و ابزارها به‌عنوان وابستگی مستقیم در srcs ، data و tools شوند. Bazel به طور پیش‌فرض، Sandboxing محلی را در سیستم‌هایی که از اجرای sandbox پشتیبانی می‌کنند، فعال می‌کند.
• local باعث می شود که دستورات به عنوان زیر فرآیندهای محلی اجرا شوند.
• worker باعث می شود که دستورات با استفاده از یک کارگر دائمی در صورت وجود اجرا شوند.
• docker باعث می شود که دستورات در داخل یک داکر sandbox در ماشین محلی اجرا شوند. این مستلزم نصب docker است.
• remote باعث می شود دستورات از راه دور اجرا شوند. این تنها در صورتی در دسترس است که یک مجری از راه دور به طور جداگانه پیکربندی شده باشد.

--strategy mnemonic = strategy

این گزینه مکان و نحوه اجرای دستورات را کنترل می‌کند و بر اساس هر یادگاری، --spawn_strategy (و -genrule_strategy با mnemonic Genrule) را نادیده می‌گیرد. برای استراتژی های پشتیبانی شده و اثرات آنها به --spawn_strategy مراجعه کنید.

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

این گزینه مشخص می کند که کدام استراتژی باید برای اجرای دستوراتی استفاده شود که دارای توضیحات منطبق بر یک regex_filter خاص هستند. برای جزئیات مربوط به تطبیق regex_filter به --per_file_copt مراجعه کنید. برای استراتژی های پشتیبانی شده و اثرات آنها به --spawn_strategy مراجعه کنید.

آخرین 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' //foo/bar/baz' را با استراتژی local اجرا می کند و در صورت شکست به sandboxed برمی گردد.

--genrule_strategy= strategy

این یک علامت کوتاه منسوخ برای --strategy=Genrule= strategy .

--jobs= n (-j)

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

--progress_report_interval= n

Bazel به صورت دوره ای گزارش پیشرفت کارهایی را که هنوز به پایان نرسیده اند (مانند آزمایش های طولانی مدت) چاپ می کند. این گزینه فرکانس گزارش را تنظیم می کند، پیشرفت هر n ثانیه چاپ می شود.

پیش فرض 0 است، یعنی یک الگوریتم افزایشی: اولین گزارش پس از 10 ثانیه چاپ می شود، سپس 30 ثانیه و پس از آن پیشرفت هر دقیقه یک بار گزارش می شود.

هنگامی که bazel از کنترل مکان نما استفاده می کند، همانطور که توسط --curses مشخص شده است، پیشرفت هر ثانیه گزارش می شود.

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

این گزینه‌ها مقدار منابع محلی (رم بر حسب مگابایت و تعداد هسته‌های منطقی CPU) را مشخص می‌کنند که Bazel می‌تواند هنگام برنامه‌ریزی ساخت و آزمایش فعالیت‌ها برای اجرای محلی در نظر بگیرد. آنها یک عدد صحیح یا یک کلمه کلیدی (HOST_RAM یا HOST_CPUS) می گیرند که به صورت اختیاری با [-|* float ] دنبال می شود (به عنوان مثال، --local_cpu_resources=2 , --local_ram_resources=HOST_RAM*.5 , --local_cpu_resources=HOST_CPUS-1 ). پرچم ها مستقل هستند. ممکن است یک یا هر دو تنظیم شود. به طور پیش فرض، Bazel مقدار RAM و تعداد هسته های CPU را مستقیماً از پیکربندی سیستم محلی تخمین می زند.

--[no]build_runfile_links

این گزینه که به صورت پیش‌فرض فعال است، مشخص می‌کند که آیا پیوندهای نمادین فایل‌های run برای تست‌ها و باینری‌ها باید در فهرست خروجی ساخته شوند یا خیر. استفاده از --nobuild_runfile_links می تواند برای اعتبار سنجی مفید باشد اگر همه اهداف بدون پرداخت هزینه برای ساخت درخت های runfiles کامپایل شوند.

هنگامی که تست ها (یا برنامه ها) اجرا می شوند، وابستگی های داده های زمان اجرا آنها در یک مکان جمع آوری می شوند. در درخت خروجی Bazel، این درخت "runfiles" معمولاً به عنوان خواهر و برادر باینری یا تست مربوطه ریشه دارد. در طول اجرای آزمایش، فایل‌های اجرا ممکن است با استفاده از مسیرهایی به شکل $TEST_SRCDIR/workspace/ packagename / filename قابل دسترسی باشند. درخت runfiles تضمین می‌کند که تست‌ها به تمام فایل‌هایی که به آنها وابستگی اعلام شده دارند دسترسی دارند و نه چیز دیگر. به طور پیش فرض، درخت runfiles با ساخت مجموعه ای از پیوندهای نمادین به فایل های مورد نیاز پیاده سازی می شود. همانطور که مجموعه پیوندها رشد می کند، هزینه این عملیات نیز افزایش می یابد، و برای برخی از بیلدهای بزرگ می تواند به طور قابل توجهی به زمان ساخت کلی کمک کند، به ویژه به این دلیل که هر تست (یا برنامه) جداگانه به درخت runfiles خود نیاز دارد.

--[no]build_runfile_manifests

این گزینه که به طور پیش فرض فعال است، مشخص می کند که آیا runfiles manifests باید در درخت خروجی نوشته شود یا خیر. غیرفعال کردن آن به معنی --nobuild_runfile_links است.

می‌توان آن را هنگام اجرای آزمایش‌ها از راه دور غیرفعال کرد، زیرا درخت‌های runfiles از راه دور از مانیفست‌های درون حافظه ایجاد می‌شوند.

--[no]discard_analysis_cache

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

--[no]keep_going (-k)

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

در حالی که این گزینه معمولاً با مرحله اجرای یک ساخت مرتبط است، اما بر مرحله تجزیه و تحلیل نیز تأثیر می گذارد: اگر چندین هدف در یک دستور ساخت مشخص شود، اما فقط برخی از آنها را بتوان با موفقیت آنالیز کرد، ساخت با یک خطا متوقف می شود مگر اینکه --keep_going مشخص شده است، در این صورت ساخت تا مرحله اجرا پیش می رود، اما فقط برای اهدافی که با موفقیت آنالیز شده اند.

--[no]use_ijars

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

--[no]interface_shared_objects

این گزینه اشیاء مشترک رابط را فعال می‌کند، که باعث می‌شود باینری‌ها و دیگر کتابخانه‌های مشترک به جای اجرای آن، به رابط یک شی مشترک وابسته باشند. هنگامی که فقط پیاده سازی تغییر می کند، Bazel می تواند از بازسازی اهدافی که به طور غیر ضروری به کتابخانه مشترک تغییر یافته وابسته هستند، اجتناب کند.

انتخاب خروجی

این گزینه ها تعیین می کنند که چه چیزی ساخته یا آزمایش شود.

--[no]build

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

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

--[no]build_tests_only

اگر مشخص شده باشد، Bazel فقط آنچه را که برای اجرای قوانین *_test و test_suite لازم است ایجاد می کند که به دلیل اندازه ، زمان ، برچسب یا زبان فیلتر نشده اند. در صورت مشخص شدن، Bazel سایر اهداف مشخص شده در خط فرمان را نادیده می گیرد. By default, this option is disabled and Bazel will build everything requested, including *_test and test_suite rules that are filtered out from testing. This is useful because running bazel test --build_tests_only foo/... may not detect all build breakages in the foo tree.

--[no]check_up_to_date

This option causes Bazel not to perform a build, but merely check whether all specified targets are up-to-date. If so, the build completes successfully, as usual. However, if any files are out of date, instead of being built, an error is reported and the build fails. This option may be useful to determine whether a build has been performed more recently than a source edit (for example, for pre-submit checks) without incurring the cost of a build.

See also --check_tests_up_to_date .

--[no]compile_one_dependency

Compile a single dependency of the argument files. This is useful for syntax checking source files in IDEs, for example, by rebuilding a single target that depends on the source file to detect errors as early as possible in the edit/build/test cycle. This argument affects the way all non-flag arguments are interpreted: each argument must be a file target label or a plain filename relative to the current working directory, and one rule that depends on each source filename is built. For

C++ and Java sources, rules in the same language space are preferentially chosen. For multiple rules with the same preference, the one that appears first in the BUILD file is chosen. An explicitly named target pattern which does not reference a source file results in an error.

--save_temps

The --save_temps option causes temporary outputs from the compiler to be saved. These include .s files (assembler code), .i (preprocessed C) and .ii (preprocessed C++) files. These outputs are often useful for debugging. Temps will only be generated for the set of targets specified on the command line.

The --save_temps flag currently works only for cc_* rules.

To ensure that Bazel prints the location of the additional output files, check that your --show_result n setting is high enough.

--build_tag_filters= tag[,tag]*

If specified, Bazel will build only targets that have at least one required tag (if any of them are specified) and does not have any excluded tags. Build tag filter is specified as comma delimited list of tag keywords, optionally preceded with '-' sign used to denote excluded tags. Required tags may also have a preceding '+' sign.

When running tests, Bazel ignores --build_tag_filters for test targets, which are built and run even if they do not match this filter. To avoid building them, filter test targets using --test_tag_filters or by explicitly excluding them.

--test_size_filters= size[,size]*

If specified, Bazel will test (or build if --build_tests_only is also specified) only test targets with the given size. Test size filter is specified as comma delimited list of allowed test size values (small, medium, large or enormous), optionally preceded with '-' sign used to denote excluded test sizes. For example,

  % bazel test --test_size_filters=small,medium //foo:all

  % bazel test --test_size_filters=-large,-enormous //foo:all

will test only small and medium tests inside //foo.

By default, test size filtering is not applied.

--test_timeout_filters= timeout[,timeout]*

If specified, Bazel will test (or build if --build_tests_only is also specified) only test targets with the given timeout. Test timeout filter is specified as comma delimited list of allowed test timeout values (short, moderate, long or eternal), optionally preceded with '-' sign used to denote excluded test timeouts. See --test_size_filters for example syntax.

By default, test timeout filtering is not applied.

--test_tag_filters= tag[,tag]*

If specified, Bazel will test (or build if --build_tests_only is also specified) only test targets that have at least one required tag (if any of them are specified) and does not have any excluded tags. Test tag filter is specified as comma delimited list of tag keywords, optionally preceded with '-' sign used to denote excluded tags. Required tags may also have a preceding '+' sign.

For example,

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

will test targets that are tagged with either performance or stress tag but are not tagged with the flaky tag.

By default, test tag filtering is not applied. Note that you can also filter on test's size and local tags in this manner.

--test_lang_filters= string[,string]*

Specifies a comma-separated list of strings referring to names of test rule classes. To refer to the rule class foo_test , use the string "foo". Bazel will test (or build if --build_tests_only is also specified) only targets of the referenced rule classes. To instead exclude those targets, use the string "-foo". For example,

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

will test only targets that are instances of foo_test or bar_test in //baz/... , while

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

will test all the targets in //baz/... except for the foo_test and bar_test instances.

--test_filter= filter-expression

Specifies a filter that the test runner may use to pick a subset of tests for running. All targets specified in the invocation are built, but depending on the expression only some of them may be executed; in some cases, only certain test methods are run.

The particular interpretation of filter-expression is up to the test framework responsible for running the test. It may be a glob, substring, or regexp. --test_filter is a convenience over passing different --test_arg filter arguments, but not all frameworks support it.

Verbosity

These options control the verbosity of Bazel's output, either to the terminal, or to additional log files.

--explain= logfile

This option, which requires a filename argument, causes the dependency checker in bazel build 's execution phase to explain, for each build step, either why it is being executed, or that it is up-to-date. The explanation is written to logfile .

If you are encountering unexpected rebuilds, this option can help to understand the reason. Add it to your .bazelrc so that logging occurs for all subsequent builds, and then inspect the log when you see an execution step executed unexpectedly. This option may carry a small performance penalty, so you might want to remove it when it is no longer needed.

--verbose_explanations

This option increases the verbosity of the explanations generated when the --explain option is enabled.

In particular, if verbose explanations are enabled, and an output file is rebuilt because the command used to build it has changed, then the output in the explanation file will include the full details of the new command (at least for most commands).

Using this option may significantly increase the length of the generated explanation file and the performance penalty of using --explain .

If --explain is not enabled, then --verbose_explanations has no effect.

--profile= file

This option, which takes a filename argument, causes Bazel to write profiling data into a file. The data then can be analyzed or parsed using the bazel analyze-profile command. The Build profile can be useful in understanding where Bazel's build command is spending its time.

--[no]show_loading_progress

This option causes Bazel to output package-loading progress messages. If it is disabled, the messages won't be shown.

--[no]show_progress

This option causes progress messages to be displayed; it is on by default. When disabled, progress messages are suppressed.

--show_progress_rate_limit= n

This option causes bazel to display at most one progress message per n seconds, where n is a real number. The default value for this option is 0.02, meaning bazel will limit the progress messages to one per every 0.02 seconds.

--show_result= n

This option controls the printing of result information at the end of a bazel build command. By default, if a single build target was specified, Bazel prints a message stating whether or not the target was successfully brought up-to-date, and if so, the list of output files that the target created. If multiple targets were specified, result information is not displayed.

While the result information may be useful for builds of a single target or a few targets, for large builds (such as an entire top-level project tree), this information can be overwhelming and distracting; this option allows it to be controlled. --show_result takes an integer argument, which is the maximum number of targets for which full result information should be printed. By default, the value is 1. Above this threshold, no result information is shown for individual targets. Thus zero causes the result information to be suppressed always, and a very large value causes the result to be printed always.

Users may wish to choose a value in-between if they regularly alternate between building a small group of targets (for example, during the compile-edit-test cycle) and a large group of targets (for example, when establishing a new workspace or running regression tests). In the former case, the result information is very useful whereas in the latter case it is less so. As with all options, this can be specified implicitly via the .bazelrc file.

The files are printed so as to make it easy to copy and paste the filename to the shell, to run built executables. The "up-to-date" or "failed" messages for each target can be easily parsed by scripts which drive a build.

--sandbox_debug

This option causes Bazel to print extra debugging information when using sandboxing for action execution. This option also preserves sandbox directories, so that the files visible to actions during execution can be examined.

--subcommands ( -s )

This option causes Bazel's execution phase to print the full command line for each command prior to executing it.

  >>>>> # //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)

Where possible, commands are printed in a Bourne shell compatible syntax, so that they can be easily copied and pasted to a shell command prompt. (The surrounding parentheses are provided to protect your shell from the cd and exec calls; be sure to copy them!) However some commands are implemented internally within Bazel, such as creating symlink trees. For these there's no command line to display.

--subcommands=pretty_print may be passed to print the arguments of the command as a list rather than as a single line. This may help make long command lines more readable.

See also --verbose_failures , below.

For logging subcommands to a file in a tool-friendly format, see --execution_log_json_file and --execution_log_binary_file .

--verbose_failures

This option causes Bazel's execution phase to print the full command line for commands that failed. This can be invaluable for debugging a failing build.

Failing commands are printed in a Bourne shell compatible syntax, suitable for copying and pasting to a shell prompt.

Workspace status

Use these options to "stamp" Bazel-built binaries: to embed additional information into the binaries, such as the source control revision or other workspace-related information. You can use this mechanism with rules that support the stamp attribute, such as genrule , cc_binary , and more.

--workspace_status_command= program

This flag lets you specify a binary that Bazel runs before each build. The program can report information about the status of the workspace, such as the current source control revision.

The flag's value must be a path to a native program. On Linux/macOS this may be any executable. On Windows this must be a native binary, typically an ".exe", ".bat", or a ".cmd" file.

The program should print zero or more key/value pairs to standard output, one entry on each line, then exit with zero (otherwise the build fails). The key names can be anything but they may only use upper case letters and underscores. The first space after the key name separates it from the value. The value is the rest of the line (including additional whitespaces). Neither the key nor the value may span multiple lines. Keys must not be duplicated.

Bazel partitions the keys into two buckets: "stable" and "volatile". (The names "stable" and "volatile" are a bit counter-intuitive, so don't think much about them.)

Bazel then writes the key-value pairs into two files:

• bazel-out/stable-status.txt contains all keys and values where the key's name starts with STABLE_
• bazel-out/volatile-status.txt contains the rest of the keys and their values

The contract is:

• "stable" keys' values should change rarely, if possible. If the contents of bazel-out/stable-status.txt change, Bazel invalidates the actions that depend on them. In other words, if a stable key's value changes, Bazel will rerun stamped actions. Therefore the stable status should not contain things like timestamps, because they change all the time, and would make Bazel rerun stamped actions with each build.

  Bazel always outputs the following stable keys:

  • BUILD_EMBED_LABEL : value of --embed_label
  • BUILD_HOST : the name of the host machine that Bazel is running on
  • BUILD_USER : the name of the user that Bazel is running as

• "volatile" keys' values may change often. Bazel expects them to change all the time, like timestamps do, and duly updates the bazel-out/volatile-status.txt file. In order to avoid rerunning stamped actions all the time though, Bazel pretends that the volatile file never changes . In other words, if the volatile status file is the only file whose contents has changed, Bazel will not invalidate actions that depend on it. If other inputs of the actions have changed, then Bazel reruns that action, and the action will see the updated volatile status, but just the volatile status changing alone will not invalidate the action.

  Bazel always outputs the following volatile keys:

  • BUILD_TIMESTAMP : time of the build in seconds since the Unix Epoch (the value of System.currentTimeMillis() divided by a thousand)

On Linux/macOS you can pass --workspace_status_command=/bin/true to disable retrieving workspace status, because true does nothing, successfully (exits with zero) and prints no output. On Windows you can pass the path of MSYS's true.exe for the same effect.

If the workspace status command fails (exits non-zero) for any reason, the build will fail.

Example program on Linux using 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"

Pass this program's path with --workspace_status_command , and the stable status file will include the STABLE lines and the volatile status file will include the rest of the lines.

--[no]stamp

This option, in conjunction with the stamp rule attribute, controls whether to embed build information in binaries.

Stamping can be enabled or disabled explicitly on a per-rule basis using the stamp attribute. Please refer to the Build Encyclopedia for details. When a rule sets stamp = -1 (the default for *_binary rules), this option determines whether stamping is enabled.

Bazel never stamps binaries that are built for the host configuration, regardless of this option or the stamp attribute. For rules that set stamp = 0 (the default for *_test rules), stamping is disabled regardless of --[no]stamp . Specifying --stamp does not force targets to be rebuilt if their dependencies have not changed.

Setting --nostamp is generally desireable for build performance, as it reduces input volatility and maximizes build caching.

Platform

Use these options to control the host and target platforms that configure how builds work, and to control what execution platforms and toolchains are available to Bazel rules.

Please see background information on Platforms and Toolchains .

--platforms= labels

The labels of the platform rules describing the target platforms for the current command.

--host_platform= label

The label of a platform rule that describes the host system.

--extra_execution_platforms= labels

The platforms that are available as execution platforms to run actions. Platforms can be specified by exact target, or as a target pattern. These platforms will be considered before those declared in the WORKSPACE file by register_execution_platforms() .

--extra_toolchains= labels

The toolchain rules to be considered during toolchain resolution. Toolchains can be specified by exact target, or as a target pattern. These toolchains will be considered before those declared in the WORKSPACE file by register_toolchains() .

--toolchain_resolution_debug= regex

Print debug information while finding toolchains if the toolchain type matches the regex. Multiple regexes can be separated by commas. The regex can be negated by using a - at the beginning. This might help developers of Bazel or Starlark rules with debugging failures due to missing toolchains.

Miscellaneous

--flag_alias= alias_name=target_path

A convenience flag used to bind longer Starlark build settings to a shorter name. For more details, see the Starlark Configurations .

--symlink_prefix= string

Changes the prefix of the generated convenience symlinks. The default value for the symlink prefix is bazel- which will create the symlinks bazel-bin , bazel-testlogs , and bazel-genfiles .

If the symbolic links cannot be created for any reason, a warning is issued but the build is still considered a success. In particular, this allows you to build in a read-only directory or one that you have no permission to write into. Any paths printed in informational messages at the conclusion of a build will only use the symlink-relative short form if the symlinks point to the expected location; in other words, you can rely on the correctness of those paths, even if you cannot rely on the symlinks being created.

Some common values of this option:

• Suppress symlink creation: --symlink_prefix=/ will cause Bazel to not create or update any symlinks, including the bazel-out and bazel-<workspace> symlinks. Use this option to suppress symlink creation entirely.

• Reduce clutter: --symlink_prefix=.bazel/ will cause Bazel to create symlinks called bin (etc) inside a hidden directory .bazel .

--platform_suffix= string

Adds a suffix to the configuration short name, which is used to determine the output directory. Setting this option to different values puts the files into different directories, for example to improve cache hit rates for builds that otherwise clobber each others output files, or to keep the output files around for comparisons.

--default_visibility= (private|public)

Temporary flag for testing bazel default visibility changes. Not intended for general use but documented for completeness' sake.

--[no]use_action_cache

This option is enabled by default. If disabled, Bazel will not use its local action cache. Disabling the local action cache saves memory and disk space for clean builds, but will make incremental builds slower.

--starlark_cpu_profile=_file_

This flag, whose value is the name of a file, causes Bazel to gather statistics about CPU usage by all Starlark threads, and write the profile, in pprof format, to the named file.

Use this option to help identify Starlark functions that make loading and analysis slow due to excessive computation. For example:

$ 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

For different views of the same data, try the pprof commands svg , web , and list .

Using Bazel for releases

Bazel is used both by software engineers during the development cycle, and by release engineers when preparing binaries for deployment to production. This section provides a list of tips for release engineers using Bazel.

Significant options

When using Bazel for release builds, the same issues arise as for other scripts that perform a build. For more details, see Call Bazel from scripts . In particular, the following options are strongly recommended:

• --bazelrc=/dev/null
• --nokeep_state_after_build

These options are also important:

• --package_path
• --symlink_prefix : for managing builds for multiple configurations, it may be convenient to distinguish each build with a distinct identifier, such as "64bit" vs. "32bit". This option differentiates the bazel-bin (etc.) symlinks.

Running tests

To build and run tests with bazel, type bazel test followed by the name of the test targets.

By default, this command performs simultaneous build and test activity, building all specified targets (including any non-test targets specified on the command line) and testing *_test and test_suite targets as soon as their prerequisites are built, meaning that test execution is interleaved with building. Doing so usually results in significant speed gains.

Options for bazel test

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

If this option is set to 'auto' (the default) then Bazel will only rerun a test if any of the following conditions applies:

• Bazel detects changes in the test or its dependencies
• the test is marked as external
• multiple test runs were requested with --runs_per_test
• the test failed.

If 'no', all tests will be executed unconditionally.

If 'yes', the caching behavior will be the same as auto except that it may cache test failures and test runs with --runs_per_test .

Users who have enabled this option by default in their .bazelrc file may find the abbreviations -t (on) or -t- (off) convenient for overriding the default on a particular run.

--check_tests_up_to_date

This option tells Bazel not to run the tests, but to merely check and report the cached test results. If there are any tests which have not been previously built and run, or whose tests results are out-of-date (for example, because the source code or the build options have changed), then Bazel will report an error message ("test result is not up-to-date"), will record the test's status as "NO STATUS" (in red, if color output is enabled), and will return a non-zero exit code.

This option also implies [--check_up_to_date](#check-up-to-date) behavior.

This option may be useful for pre-submit checks.

--test_verbose_timeout_warnings

This option tells Bazel to explicitly warn the user if a test's timeout is significantly longer than the test's actual execution time. While a test's timeout should be set such that it is not flaky, a test that has a highly over-generous timeout can hide real problems that crop up unexpectedly.

For instance, a test that normally executes in a minute or two should not have a timeout of ETERNAL or LONG as these are much, much too generous.

This option is useful to help users decide on a good timeout value or sanity check existing timeout values.

--[no]test_keep_going

By default, all tests are run to completion. If this flag is disabled, however, the build is aborted on any non-passing test. Subsequent build steps and test invocations are not run, and in-flight invocations are canceled. Do not specify both --notest_keep_going and --keep_going .

--flaky_test_attempts= attempts

This option specifies the maximum number of times a test should be attempted if it fails for any reason. A test that initially fails but eventually succeeds is reported as FLAKY on the test summary. It is, however, considered to be passed when it comes to identifying Bazel exit code or total number of passed tests. Tests that fail all allowed attempts are considered to be failed.

By default (when this option is not specified, or when it is set to default), only a single attempt is allowed for regular tests, and 3 for test rules with the flaky attribute set. You can specify an integer value to override the maximum limit of test attempts. Bazel allows a maximum of 10 test attempts in order to prevent abuse of the system.

--runs_per_test= [regex@]number

This option specifies the number of times each test should be executed. All test executions are treated as separate tests (fallback functionality will apply to each of them independently).

The status of a target with failing runs depends on the value of the --runs_per_test_detects_flakes flag:

• If absent, any failing run causes the entire test to fail.
• If present and two runs from the same shard return PASS and FAIL, the test will receive a status of flaky (unless other failing runs cause it to fail).

If a single number is specified, all tests will run that many times. Alternatively, a regular expression may be specified using the syntax regex@number. This constrains the effect of --runs_per_test to targets which match the regex ( --runs_per_test=^//pizza:.*@4 runs all tests under //pizza/ 4 times). This form of --runs_per_test may be specified more than once.

--[no]runs_per_test_detects_flakes

If this option is specified (by default it is not), Bazel will detect flaky test shards through --runs_per_test . If one or more runs for a single shard fail and one or more runs for the same shard pass, the target will be considered flaky with the flag. If unspecified, the target will report a failing status.

--test_summary= output_style

Specifies how the test result summary should be displayed.

• short prints the results of each test along with the name of the file containing the test output if the test failed. This is the default value.
• terse like short , but even shorter: only print information about tests which did not pass.
• detailed prints each individual test case that failed, not only each test. The names of test output files are omitted.
• none does not print test summary.

--test_output= output_style

Specifies how test output should be displayed:

• summary shows a summary of whether each test passed or failed. Also shows the output log file name for failed tests. The summary will be printed at the end of the build (during the build, one would see just simple progress messages when tests start, pass or fail). This is the default behavior.
• errors sends combined stdout/stderr output from failed tests only into the stdout immediately after test is completed, ensuring that test output from simultaneous tests is not interleaved with each other. Prints a summary at the build as per summary output above.
• all is similar to errors but prints output for all tests, including those which passed.
• streamed streams stdout/stderr output from each test in real-time.

--java_debug

This option causes the Java virtual machine of a java test to wait for a connection from a JDWP-compliant debugger before starting the test. This option implies --test_output=streamed .

--[no]verbose_test_summary

By default this option is enabled, causing test times and other additional information (such as test attempts) to be printed to the test summary. If --noverbose_test_summary is specified, test summary will include only test name, test status and cached test indicator and will be formatted to stay within 80 characters when possible.

--test_tmpdir= path

Specifies temporary directory for tests executed locally. Each test will be executed in a separate subdirectory inside this directory. The directory will be cleaned at the beginning of the each bazel test command. By default, bazel will place this directory under Bazel output base directory.

--test_timeout= seconds OR --test_timeout= seconds , seconds , seconds , seconds

Overrides the timeout value for all tests by using specified number of seconds as a new timeout value. If only one value is provided, then it will be used for all test timeout categories.

Alternatively, four comma-separated values may be provided, specifying individual timeouts for short, moderate, long and eternal tests (in that order). In either form, zero or a negative value for any of the test sizes will be substituted by the default timeout for the given timeout categories as defined by the page Writing Tests . By default, Bazel will use these timeouts for all tests by inferring the timeout limit from the test's size whether the size is implicitly or explicitly set.

Tests which explicitly state their timeout category as distinct from their size will receive the same value as if that timeout had been implicitly set by the size tag. So a test of size 'small' which declares a 'long' timeout will have the same effective timeout that a 'large' tests has with no explicit timeout.

--test_arg= arg

Passes command-line options/flags/arguments to each test process. This option can be used multiple times to pass several arguments. For example, --test_arg=--logtostderr --test_arg=--v=3 .

--test_env= variable =_value_ OR --test_env= variable

Specifies additional variables that must be injected into the test environment for each test. If value is not specified it will be inherited from the shell environment used to start the bazel test command.

The environment can be accessed from within a test by using System.getenv("var") (Java), getenv("var") (C or C++),

--run_under= command-prefix

This specifies a prefix that the test runner will insert in front of the test command before running it. The command-prefix is split into words using Bourne shell tokenization rules, and then the list of words is prepended to the command that will be executed.

If the first word is a fully-qualified label (starts with // ) it is built. Then the label is substituted by the corresponding executable location that is prepended to the command that will be executed along with the other words.

Some caveats apply:

• The PATH used for running tests may be different than the PATH in your environment, so you may need to use an absolute path for the --run_under command (the first word in command-prefix ).
• stdin is not connected , so --run_under can't be used for interactive commands.

Examples:

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

Test selection

As documented under Output selection options , you can filter tests by size , timeout , tag , or language . A convenience general name filter can forward particular filter args to the test runner.

Other options for bazel test

The syntax and the remaining options are exactly like bazel build .

Running executables

The bazel run command is similar to bazel build , except it is used to build and run a single target. Here is a typical session:

  % 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 is similar, but not identical, to directly invoking the binary built by Bazel and its behavior is different depending on whether the binary to be invoked is a test or not.

When the binary is not a test, the current working directory will be the runfiles tree of the binary.

When the binary is a test, the current working directory will be the exec root and a good-faith attempt is made to replicate the environment tests are usually run in. The emulation is not perfect, though, and tests that have multiple shards cannot be run this way (the --test_sharding_strategy=disabled command line option can be used to work around this)

The following extra environment variables are also available to the binary:

• BUILD_WORKSPACE_DIRECTORY : the root of the workspace where the build was run.
• BUILD_WORKING_DIRECTORY : the current working directory where Bazel was run from.

These can be used, for example, to interpret file names on the command line in a user-friendly way.

Options for bazel run

--run_under= command-prefix

This has the same effect as the --run_under option for bazel test ( see above ), except that it applies to the command being run by bazel run rather than to the tests being run by bazel test and cannot run under label.

Filtering logging outputs from Bazel

When invoking a binary with bazel run , Bazel prints logging output from Bazel itself and the binary under invocation. To make the logs less noisy, you can suppress the outputs from Bazel itself with the --ui_event_filters and --noshow_progress flags.

For example: bazel run --ui_event_filters=-info,-stdout,-stderr --noshow_progress //java/myapp:myapp

Executing tests

bazel run can also execute test binaries, which has the effect of running the test in a close approximation of the environment described at Writing Tests . Note that none of the --test_* arguments have an effect when running a test in this manner except --test_arg .

Cleaning build outputs

The clean command

Bazel has a clean command, analogous to that of Make. It deletes the output directories for all build configurations performed by this Bazel instance, or the entire working tree created by this Bazel instance, and resets internal caches. If executed without any command-line options, then the output directory for all configurations will be cleaned.

Recall that each Bazel instance is associated with a single workspace, thus the clean command will delete all outputs from all builds you've done with that Bazel instance in that workspace.

To completely remove the entire working tree created by a Bazel instance, you can specify the --expunge option. When executed with --expunge , the clean command simply removes the entire output base tree which, in addition to the build output, contains all temp files created by Bazel. It also stops the Bazel server after the clean, equivalent to the shutdown command. For example, to clean up all disk and memory traces of a Bazel instance, you could specify:

  % bazel clean --expunge

Alternatively, you can expunge in the background by using --expunge_async . It is safe to invoke a Bazel command in the same client while the asynchronous expunge continues to run.

The clean command is provided primarily as a means of reclaiming disk space for workspaces that are no longer needed. Bazel's incremental rebuilds may not be perfect so clean can be used to recover a consistent state when problems arise.

Bazel's design is such that these problems are fixable and these bugs are a high priority to be fixed. If you ever find an incorrect incremental build, file a bug report, and report bugs in the tools rather than using clean .

Querying the dependency graph

Bazel includes a query language for asking questions about the dependency graph used during the build. The query language is used by two commands: query and cquery. The major difference between the two commands is that query runs after the loading phase and cquery runs after the analysis phase . These tools are an invaluable aid to many software engineering tasks.

The query language is based on the idea of algebraic operations over graphs; it is documented in detail in

Bazel Query Reference . Please refer to that document for reference, for examples, and for query-specific command-line options.

The query tool accepts several command-line option. --output selects the output format. --[no]keep_going (disabled by default) causes the query tool to continue to make progress upon errors; this behavior may be disabled if an incomplete result is not acceptable in case of errors.

The --[no]tool_deps option, enabled by default, causes dependencies in non-target configurations to be included in the dependency graph over which the query operates.

The --[no]implicit_deps option, enabled by default, causes implicit dependencies to be included in the dependency graph over which the query operates. An implicit dependency is one that is not explicitly specified in the BUILD file but added by bazel.

Example: "Show the locations of the definitions (in BUILD files) of all genrules required to build all the tests in the PEBL tree."

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

Querying the action graph

The aquery command allows you to query for actions in your build graph. It operates on the post-analysis configured target graph and exposes information about actions, artifacts and their relationships.

The tool accepts several command-line options. --output selects the output format. The default output format ( text ) is human-readable, use proto or textproto for machine-readable format. Notably, the aquery command runs on top of a regular Bazel build and inherits the set of options available during a build.

It supports the same set of functions that is also available to traditional query but siblings , buildfiles and tests .

For more details, see Action Graph Query .

Miscellaneous commands and options

help

The help command provides on-line help. By default, it shows a summary of available commands and help topics, as shown in Building with Bazel . Specifying an argument displays detailed help for a particular topic. Most topics are Bazel commands, such as build or query , but there are some additional help topics that do not correspond to commands.

--[no]long ( -l )

By default, bazel help [ topic ] prints only a summary of the relevant options for a topic. If the --long option is specified, the type, default value and full description of each option is also printed.

shutdown

Bazel server processes may be stopped by using the shutdown command. This command causes the Bazel server to exit as soon as it becomes idle (for example, after the completion of any builds or other commands that are currently in progress). For more details, see Client/server implementation .

Bazel servers stop themselves after an idle timeout, so this command is rarely necessary; however, it can be useful in scripts when it is known that no further builds will occur in a given workspace.

shutdown accepts one option, --iff_heap_size_greater_than _n_ , which requires an integer argument (in MB). If specified, this makes the shutdown conditional on the amount of memory already consumed. This is useful for scripts that initiate a lot of builds, as any memory leaks in the Bazel server could cause it to crash spuriously on occasion; performing a conditional restart preempts this condition.

info

The info command prints various values associated with the Bazel server instance, or with a specific build configuration. (These may be used by scripts that drive a build.)

The info command also permits a single (optional) argument, which is the name of one of the keys in the list below. In this case, bazel info key will print only the value for that one key. (This is especially convenient when scripting Bazel, as it avoids the need to pipe the result through sed -ne /key:/s/key://p :

Configuration-independent data

• release : the release label for this Bazel instance, or "development version" if this is not a released binary.
• workspace the absolute path to the base workspace directory.

• install_base : the absolute path to the installation directory used by this Bazel instance for the current user. Bazel installs its internally required executables below this directory.

• output_base : the absolute path to the base output directory used by this Bazel instance for the current user and workspace combination. Bazel puts all of its scratch and build output below this directory.

• execution_root : the absolute path to the execution root directory under output_base. This directory is the root for all files accessible to commands executed during the build, and is the working directory for those commands. If the workspace directory is writable, a symlink named bazel-<workspace> is placed there pointing to this directory.

• output_path : the absolute path to the output directory beneath the execution root used for all files actually generated as a result of build commands. If the workspace directory is writable, a symlink named bazel-out is placed there pointing to this directory.

• server_pid : the process ID of the Bazel server process.

• server_log : the absolute path to the Bazel server's debug log file. This file contains debugging information for all commands over the lifetime of the Bazel server, and is intended for human consumption by Bazel developers and power users.

• command_log : the absolute path to the command log file; this contains the interleaved stdout and stderr streams of the most recent Bazel command. Note that running bazel info will overwrite the contents of this file, since it then becomes the most recent Bazel command. However, the location of the command log file will not change unless you change the setting of the --output_base or --output_user_root options.

• used-heap-size , committed-heap-size , max-heap-size : reports various JVM heap size parameters. Respectively: memory currently used, memory currently guaranteed to be available to the JVM from the system, maximum possible allocation.

• gc-count , gc-time : The cumulative count of garbage collections since the start of this Bazel server and the time spent to perform them. Note that these values are not reset at the start of every build.

• package_path : A colon-separated list of paths which would be searched for packages by bazel. Has the same format as the --package_path build command line argument.

Example: the process ID of the Bazel server.

% bazel info server_pid
1285

Configuration-specific data

These data may be affected by the configuration options passed to bazel info , for example --cpu , --compilation_mode , etc. The info command accepts all the options that control dependency analysis, since some of these determine the location of the output directory of a build, the choice of compiler, etc.

• bazel-bin , bazel-testlogs , bazel-genfiles : reports the absolute path to the bazel-* directories in which programs generated by the build are located. This is usually, though not always, the same as the bazel-* symlinks created in the base workspace directory after a successful build. However, if the workspace directory is read-only, no bazel-* symlinks can be created. Scripts that use the value reported by bazel info , instead of assuming the existence of the symlink, will be more robust.
• The complete "Make" environment . If the --show_make_env flag is specified, all variables in the current configuration's "Make" environment are also displayed (such as CC , GLIBC_VERSION , etc). These are the variables accessed using the $(CC) or varref("CC") syntax inside BUILD files.

Example: the C++ compiler for the current configuration. This is the $(CC) variable in the "Make" environment, so the --show_make_env flag is needed.

  % bazel info --show_make_env -c opt COMPILATION_MODE
  opt

Example: the bazel-bin output directory for the current configuration. This is guaranteed to be correct even in cases where the bazel-bin symlink cannot be created for some reason (such as if you are building from a read-only directory).

% 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 and --version

The version command prints version details about the built Bazel binary, including the changelist at which it was built and the date. These are particularly useful in determining if you have the latest Bazel, or if you are reporting bugs. Some of the interesting values are:

• changelist : the changelist at which this version of Bazel was released.
• label : the release label for this Bazel instance, or "development version" if this is not a released binary. Very useful when reporting bugs.

bazel --version , with no other args, will emit the same output as bazel version --gnu_format , except without the side-effect of potentially starting a Bazel server or unpacking the server archive. bazel --version can be run from anywhere - it does not require a workspace directory.

mobile-install

The mobile-install command installs apps to mobile devices. Currently only Android devices running ART are supported.

See bazel mobile-install for more information.

The following options are supported:

--incremental

If set, Bazel tries to install the app incrementally, that is, only those parts that have changed since the last build. This cannot update resources referenced from AndroidManifest.xml , native code or Java resources (such as those referenced by Class.getResource() ). If these things change, this option must be omitted. Contrary to the spirit of Bazel and due to limitations of the Android platform, it is the responsibility of the user to know when this command is good enough and when a full install is needed.

If you are using a device with Marshmallow or later, consider the --split_apks flag.

--split_apks

Whether to use split apks to install and update the application on the device. Works only with devices with Marshmallow or later. Note that the --incremental flag is not necessary when using --split_apks .

--start_app

Starts the app in a clean state after installing. Equivalent to --start=COLD .

--debug_app

Waits for debugger to be attached before starting the app in a clean state after installing. Equivalent to --start=DEBUG .

--start=_start_type_

How the app should be started after installing it. Supported _start_type_s are:

• NO Does not start the app. This is the default.
• COLD Starts the app from a clean state after install.
• WARM Preserves and restores the application state on incremental installs.
• DEBUG Waits for the debugger before starting the app in a clean state after install.

--adb= path

Indicates the adb binary to be used.

The default is to use the adb in the Android SDK specified by --android_sdk .

--adb_arg= serial

Extra arguments to adb . These come before the subcommand in the command line and are typically used to specify which device to install to. For example, to select the Android device or emulator to use:

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

invokes adb as

adb -s deadbeef install ...

--incremental_install_verbosity= number

The verbosity for incremental install. Set to 1 for debug logging to be printed to the console.

dump

The dump command prints to stdout a dump of the internal state of the Bazel server. This command is intended primarily for use by Bazel developers, so the output of this command is not specified, and is subject to change.

By default, command will just print help message outlining possible options to dump specific areas of the Bazel state. In order to dump internal state, at least one of the options must be specified.

Following options are supported:

• --action_cache dumps action cache content.
• --packages dumps package cache content.
• --skyframe dumps state of internal Bazel dependency graph.
• --rules dumps rule summary for each rule and aspect class, including counts and action counts. This includes both native and Starlark rules. If memory tracking is enabled, then the rules' memory consumption is also printed.
• --skylark_memory dumps a pprof compatible .gz file to the specified path. You must enable memory tracking for this to work.

Memory tracking

Some dump commands require memory tracking. To turn this on, you have to pass startup flags to Bazel:

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

The java-agent is checked into Bazel at third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar , so make sure you adjust $BAZEL for where you keep your Bazel repository.

Do not forget to keep passing these options to Bazel for every command or the server will restart.

Example:

    % 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

The analyze-profile command analyzes data previously gathered during the build using --profile option. It provides several options to either perform analysis of the build execution or export data in the specified format.

The following options are supported:

• --dump displays all gathered data in a human-readable format. However, this it does not support other formats yet.

For format details and usage help, see Troubleshooting performance by profiling .

canonicalize-flags

The canonicalize-flags command, which takes a list of options for a Bazel command and returns a list of options that has the same effect. The new list of options is canonical. For example, two lists of options with the same effect are canonicalized to the same new list.

The --for_command option can be used to select between different commands. At this time, only build and test are supported. Options that the given command does not support cause an error.

As an example:

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

Startup options

The options described in this section affect the startup of the Java virtual machine used by Bazel server process, and they apply to all subsequent commands handled by that server. If there is an already running Bazel server and the startup options do not match, it will be restarted.

All of the options described in this section must be specified using the --key=value or --key value syntax. Also, these options must appear before the name of the Bazel command. Use startup --key=value to list these in a .bazelrc file.

--output_base= dir

This option requires a path argument, which must specify a writable directory. Bazel will use this location to write all its output. The output base is also the key by which the client locates the Bazel server. By changing the output base, you change the server which will handle the command.

By default, the output base is derived from the user's login name, and the name of the workspace directory (actually, its MD5 digest), so a typical value looks like: /var/tmp/google/_bazel_johndoe/d41d8cd98f00b204e9800998ecf8427e .

For example:

 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

In this command, the two Bazel commands run concurrently (because of the shell & operator), each using a different Bazel server instance (because of the different output bases). In contrast, if the default output base was used in both commands, then both requests would be sent to the same server, which would handle them sequentially: building //foo first, followed by an incremental build of //bar .

--output_user_root= dir

Points to the root directory where output and install bases are created. The directory must either not exist or be owned by the calling user. In the past, this was allowed to point to a directory shared among various users but it's not allowed any longer. This may be allowed once issue #11100 is addressed.

If the --output_base option is specified, it overrides using --output_user_root to calculate the output base.

The install base location is calculated based on --output_user_root , plus the MD5 identity of the Bazel embedded binaries.

You can use the --output_user_root option to choose an alternate base location for all of Bazel's output (install base and output base) if there is a better location in your filesystem layout.

--server_javabase= dir

Specifies the Java virtual machine in which Bazel itself runs. The value must be a path to the directory containing a JDK or JRE. It should not be a label. This option should appear before any Bazel command, for example:

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

This flag does not affect the JVMs used by Bazel subprocesses such as applications, tests, tools, and so on. Use build options --javabase or --host_javabase instead.

This flag was previously named --host_javabase (sometimes referred to as the 'left-hand side' --host_javabase ), but was renamed to avoid confusion with the build flag --host_javabase (sometimes referred to as the 'right-hand side' --host_javabase ).

--host_jvm_args= string

Specifies a startup option to be passed to the Java virtual machine in which Bazel itself runs. This can be used to set the stack size, for example:

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

This option can be used multiple times with individual arguments. Note that setting this flag should rarely be needed. You can also pass a space-separated list of strings, each of which will be interpreted as a separate JVM argument, but this feature will soon be deprecated.

That this does not affect any JVMs used by subprocesses of Bazel: applications, tests, tools, and so on. To pass JVM options to executable Java programs, whether run by bazel run or on the command-line, you should use the --jvm_flags argument which all java_binary and java_test programs support. Alternatively for tests, use bazel test --test_arg=--jvm_flags=foo ... .

--host_jvm_debug

This option causes the Java virtual machine to wait for a connection from a JDWP-compliant debugger before calling the main method of Bazel itself . This is primarily intended for use by Bazel developers.

--autodetect_server_javabase

This option causes Bazel to automatically search for an installed JDK on startup, and to fall back to the installed JRE if the embedded JRE isn't available. --explicit_server_javabase can be used to pick an explicit JRE to run Bazel with.

--batch

Batch mode causes Bazel to not use the standard client/server mode , but instead runs a bazel java process for a single command, which has been used for more predictable semantics with respect to signal handling, job control, and environment variable inheritance, and is necessary for running bazel in a chroot jail.

Batch mode retains proper queueing semantics within the same output_base. That is, simultaneous invocations will be processed in order, without overlap. If a batch mode Bazel is run on a client with a running server, it first kills the server before processing the command.

Bazel will run slower in batch mode, or with the alternatives described above. This is because, among other things, the build file cache is memory-resident, so it is not preserved between sequential batch invocations. Therefore, using batch mode often makes more sense in cases where performance is less critical, such as continuous builds.

--max_idle_secs= n

This option specifies how long, in seconds, the Bazel server process should wait after the last client request, before it exits. The default value is 10800 (3 hours). --max_idle_secs=0 will cause the Bazel server process to persist indefinitely.

This option may be used by scripts that invoke Bazel to ensure that they do not leave Bazel server processes on a user's machine when they would not be running otherwise. For example, a presubmit script might wish to invoke bazel query to ensure that a user's pending change does not introduce unwanted dependencies. However, if the user has not done a recent build in that workspace, it would be undesirable for the presubmit script to start a Bazel server just for it to remain idle for the rest of the day. By specifying a small value of --max_idle_secs in the query request, the script can ensure that if it caused a new server to start, that server will exit promptly, but if instead there was already a server running, that server will continue to run until it has been idle for the usual time. Of course, the existing server's idle timer will be reset.

--[no]shutdown_on_low_sys_mem

If enabled and --max_idle_secs is set to a positive duration, after the build server has been idle for a while, shut down the server when the system is low on memory. Linux only.

In addition to running an idle check corresponding to max_idle_secs, the build server will starts monitoring available system memory after the server has been idle for some time. If the available system memory becomes critically low, the server will exit.

--[no]block_for_lock

If enabled, Bazel will wait for other Bazel commands holding the server lock to complete before progressing. If disabled, Bazel will exit in error if it cannot immediately acquire the lock and proceed.

Developers might use this in presubmit checks to avoid long waits caused by another Bazel command in the same client.

--io_nice_level= n

Sets a level from 0-7 for best-effort IO scheduling. 0 is highest priority, 7 is lowest. The anticipatory scheduler may only honor up to priority 4. Negative values are ignored.

--batch_cpu_scheduling

Use batch CPU scheduling for Bazel. This policy is useful for workloads that are non-interactive, but do not want to lower their nice value. See 'man 2 sched_setscheduler'. This policy may provide for better system interactivity at the expense of Bazel throughput.

Miscellaneous options

--[no]announce_rc

Controls whether Bazel announces command options read from the bazelrc file when starting up. (Startup options are unconditionally announced.)

--color (yes|no|auto)

This option determines whether Bazel will use colors to highlight its output on the screen.

If this option is set to yes , color output is enabled. If this option is set to auto , Bazel will use color output only if the output is being sent to a terminal and the TERM environment variable is set to a value other than dumb , emacs , or xterm-mono . If this option is set to no , color output is disabled, regardless of whether the output is going to a terminal and regardless of the setting of the TERM environment variable.

--config= name

Selects additional config section from the rc files ; for the current command , it also pulls in the options from command:name if such a section exists. Can be specified multiple times to add flags from several config sections. Expansions can refer to other definitions (for example, expansions can be chained).

--curses (yes|no|auto)

This option determines whether Bazel will use cursor controls in its screen output. This results in less scrolling data, and a more compact, easy-to-read stream of output from Bazel. This works well with --color .

If this option is set to yes , use of cursor controls is enabled. If this option is set to no , use of cursor controls is disabled. If this option is set to auto , use of cursor controls will be enabled under the same conditions as for --color=auto .

--[no]show_timestamps

If specified, a timestamp is added to each message generated by Bazel specifying the time at which the message was displayed.