الأوامر والخيارات

تتناول هذه الصفحة الخيارات المتوفّرة باستخدام أوامر Bazel المختلفة، مثل bazel build وbazel run وbazel test. هذه الصفحة هي رفيق إلى قائمة أوامر Bazel' في تصميم باستخدام Bazel.

البنية المستهدفة

يمكن أن تعمل بعض الأوامر، مثل build أو test، على قائمة من الأهداف. وهي تستخدِم بنية أكثر مرونة من التصنيفات، وقد تم توثيقها في تحديد الأهداف المطلوب إنشاؤها.

الخيارات

توضّح الأقسام التالية الخيارات المتاحة أثناء إنشاء المبنى. عند استخدام --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 من الأدلة أسفل مساحة العمل. على سبيل المثال، إذا استخدمت عنصر مسار الحزمة .، ثم اضغط على القرص في الدليل /home/bob/clients/bob_client/bazel/foo، سيتم التعامل مع الحِزم من دليل /home/bob/clients/bob_client/bazel/foo.

إذا كنت تستخدم مسار حزمة غير تلقائي، حدِّده في ملف إعداد Bazel لتسهيل الأمر عليك.

لا يتطلب Bazel وجود أي حِزم في الدليل الحالي، لذا يمكنك إنشاء مبنى من مساحة عمل بازار فارغة إذا كان من الممكن العثور على كل الحِزم اللازمة في مكان آخر على مسار الحزمة.

مثال: المبنى من عميل فارغ

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

--deleted_packages

يحدّد هذا الخيار قائمة مفصولة بفواصل لحزم البيانات التي على Bazel حذفها، ولا يحاول التحميل من أي دليل على مسار الحزمة. ويمكن استخدام هذا الإجراء لمحاكاة حذف الطرود بدون حذفها.

حدث خطأ أثناء التحقق.

تتحكم هذه الخيارات في Bazel's للتحقق من الأخطاء و/أو التحذيرات.

--[no]check_visibility

وفي حال ضبط هذا الخيار على "خطأ"، يتم خفض ترتيب عمليات التحقّق من مستوى الرؤية إلى تحذيرات. القيمة التلقائية لهذا الخيار صحيحة، لذلك يتم التحقق من مستوى الرؤية تلقائيًا.

--output_filter=regex

لن يعرض الخيار --output_filter سوى تحذيرات الإصدار والتجميع للأهداف التي تتطابق مع التعبير العادي. إذا لم يتطابق الاستهداف مع التعبير العادي المحدد وتم تنفيذه بنجاح، يتم تجاهل الناتج العادي والخطأ العادي.

إليك بعض القيم النموذجية لهذا الخيار:

`--output_filterيين#39;^//(first/project|second/project):'`	عرض مُخرجات الحِزم المحدّدة.
`--output_filterdmca#39;^//((?!(first/bad_project|second/bad_project):))*$'`	عدم عرض مخرجات للحزم المحددة.
`--output_filter=`	عرض كل شيء.
`--output_filter=DONT_MATCH_ANYTHING`	عدم عرض أي شيء

علامات الأداة

تتحكّم هذه الخيارات في الخيارات التي سيرسل بها Bazel إلى أدوات أخرى.

--copt=cc-option

يحصل هذا الخيار على وسيطة يتم تمريرها إلى برنامج التجميع. سيتم تمرير الوسيطة إلى برنامج التجميع متى تم استدعاءه للمعالجة المسبقة و/أو التجميع و/أو تجميع C أو C++ أو رمز التجميع. ولن يتم تمريره عند الربط.

يمكن استخدام هذا الخيار عدة مرات. مثلاً:

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

ستجمّع مكتبة foo بدون جداول تصحيح الأخطاء، ما يؤدي إلى إنشاء رمز مستقل عن الموضع.

--host_copt=cc-option

يستخدم هذا الخيار وسيطة يتم تمريرها إلى المُجمِّع للملفات المصدر التي يتم تجميعها في إعداد المضيف. يُعد هذا مماثلاً للخيار --copt، ولكنه ينطبق فقط على إعداد المضيف.

--host_conlyopt=cc-option

يأخذ هذا الخيار وسيطة يتم تمريرها إلى المُجمِّع لملفات المصدر C التي يتم تجميعها في إعداد المضيف. يُعد هذا مماثلاً للخيار --conlyopt، ولكنه ينطبق فقط على إعداد المضيف.

--host_cxxopt=cc-option

يحصل هذا الخيار على وسيطة يتم تمريرها إلى المُجمِّع لملفات المصدر C++ التي يتم تجميعها في إعداد المضيف. يُعد هذا مماثلاً للخيار --cxxopt، ولكنه ينطبق فقط على إعداد المضيف.

--host_linkopt=linker-option

يأخذ هذا الخيار وسيطة يتم تمريرها إلى رابط الملفات المصدر التي يتم تجميعها في إعداد المضيف. يُعد هذا مماثلاً لخيار --linkopt، ولكنه ينطبق فقط على إعداد المضيف.

--conlyopt=cc-option

يستخدم هذا الخيار وسيطة يتم تمريرها إلى برنامج التجميع عند تجميع ملفات المصدر C.

إنّ هذا الرمز يشبه --copt، ولكنّه ينطبق فقط على المحتوى المجمّع C، وليس على التجميع أو C++. بحيث يمكنك تمرير الخيارات الخاصة بـ C (مثل -Wno-pointer-sign) باستخدام --conlyopt.

--cxxopt=cc-option

يحصل هذا الخيار على وسيطة يتم تمريرها إلى برنامج التجميع عند تجميع ملفات مصدر C++.

إنّ هذا الرمز يشبه --copt، ولكنّه ينطبق فقط على المحتوى المجمّع C++، وليس على المحتوى المجمّع أو الربط C. حتى تتمكن من تمرير الخيارات الخاصة بـ C++ (مثل -fpermissive أو -fno-implicit-templates) باستخدام --cxxopt.

مثلاً:

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

--linkopt=linker-option

يستخدم هذا الخيار وسيطة يتم تمريرها إلى برنامج التجميع عند الربط.

إنّ هذا الإجراء يشبه --copt، ولكنه ينطبق فقط على عملية الربط، وليس على التجميع. بحيث يمكنك تمرير خيارات المُجمِّع المفيدة فقط في وقت الربط (مثل -lssp أو -Wl,--wrap,abort) باستخدام --linkopt. مثلاً:

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

ويمكن أيضًا أن تحدّد قواعد الإصدار خيارات الروابط في سماتها. وتكون الأولوية دائمًا لإعدادات هذا الخيار. راجِع أيضًا 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 ld' : لا يزيل سوى معلومات تصحيح الأخطاء. إذا أردت لسبب ما إزالة جميع الرموز، وليس فقط رموز تصحيح الأخطاء، ستحتاج إلى استخدام خيار --strip-all ld's، والذي يمكنك فعله من خلال تمرير --linkopt=-Wl,--strip-all إلى Bazel. يُرجى العلم أيضًا بأنّ ضبط علامة --strip على Bazel&#39 سيلغي --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، يتم استخدام الوسيط كبادئة دليل لشجرة دليل الملفات لكل كائن لملفات .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) عند تحسين الملاحظات. بالنسبة إلى GCC، الوسيطة هي ملف ZIP الذي يحتوي على شجرة الملفات التي تم إنشاؤها مسبقًا لملفات gc .التي تحتوي على معلومات الملف الشخصي لكل ملف .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 المُستخدَم لإنشاء أدوات يتم تنفيذها أثناء الإصدار. القيمة التلقائية هي 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. يمكنك تمديد القيم من خلال تسجيل JavaScript مخصّص باستخدام قواعد المستودع local_java_repository أو remote_java_repostory.

--tool_java_runtime_version=version

إصدار JVM المُستخدَم لتنفيذ الأدوات اللازمة أثناء عملية الإصدار القيمة التلقائية هي remotejdk_11.

--jvmopt=jvm-option

يسمح هذا الخيار بتمرير وسيطات الخيار إلى جهاز افتراضي جافا. يمكن استخدامه مع وسيطة واحدة كبيرة أو عدة مرات مع وسيطات فردية. مثلاً:

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

استخدام الجهاز الافتراضي (VM) للخادم لتشغيل كل برامج Java الثنائية وضبط حجم ذاكرة التخزين المؤقت لتشغيل الجهاز الافتراضي (VM) على 256 ميغابايت.

--javacopt=javac-option

يسمح هذا الخيار بتمرير وسيطات الخيار إلى javac. يمكن استخدامه مع وسيطة واحدة كبيرة أو عدة مرات مع وسيطات فردية. مثلاً:

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

سيعيد إنشاء java_binary باستخدام معلومات تصحيح الأخطاء التلقائية javac (بدلاً من الإعدادات التلقائية للبازل).

يتم تمرير الخيار إلى javac بعد الخيارات التلقائية المدمجة في Bazel لـ Java قبل خيارات كل قاعدة. المواصفات الأخيرة لأي خيار من أجل javac تفوز. الخيارات التلقائية لـ javac هي:

  -source 8 -target 8 -encoding UTF-8

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

يتحكّم هذا الخيار في ما إذا كانت javac تتحقق من الاعتماديات المباشرة المفقودة. يجب أن تحدّد استهدافات Java صراحةً جميع الأهداف المستخدَمة مباشرةً باعتبارها ارتباطات. توجّه هذه العلامة javac إلى تحديد ملفات الخيوط التي يتم استخدامها فعليًا في فحص كل ملف من ملفات java، وتحذير/خطأ إذا لم تكن هناك مخرجات اعتمادية مباشرة من الهدف الحالي.

• off يعني أنّه تم إيقاف ميزة التحقّق.
• warn تعني أن javac ستنشئ تحذيرات عادية من JavaScript من النوع [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

يحدد هذا الخيار بنية وحدة المعالجة المركزية المستهدفة المراد استخدامها لتجميع البرامج الثنائية أثناء الإصدار.

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

إذا تم ضبط هذا الخيار على "صحيح"، ستتم جدولة الإجراءات الإضافية التي يحدّدها خيار سطر الأوامر --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 لتطبيقها فقط على الإجراءات التي يحتوي عليها تصنيف owner's، '/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_library مرّتين على الأقل: مرة واحدة لكل وحدة معالجة مركزية محدّدة باستخدام --fat_apk_cpu للقاعدة android_binary، ومرة واحدة لوحدة المعالجة المركزية المحدّدة باستخدام --cpu للقاعدة cc_binary.

والقيمة التلقائية هي armeabi-v7a.

يتم إنشاء ملف .so واحد وتجميعه في حزمة APK لكل وحدة معالجة مركزية (CPU) محدّدة باستخدام --fat_apk_cpu. يكون اسم الملف .so& يسبقه اسم القاعدة android_binary بالاسم "&";&;;lib". على سبيل المثال، إذا كان اسم الخاصية android_binary هو "foo;quot;، يجب أن يكون الملف libfoo.so.

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

عند توفّر هذه العلامة، سيتم إنشاء أي ملف C++ يتضمن تصنيفًا أو مسار تنفيذ يتطابق مع أحد تعبيرات التعبير العادي للتضمين وليس مطابقة أي من تعبيرات الاستبعاد باستخدام الخيارات المحدّدة. تستخدم مطابقة التصنيف النموذج الأساسي للتصنيف (أي //package:label_name).

مسار التنفيذ هو المسار النسبي لدليل مساحة العمل، بما في ذلك الاسم الأساسي (بما في ذلك الإضافة) لملف C++. ويتضمن أيضًا أي بادئات تابعة للنظام الأساسي.

لمطابقة الملفات التي تم إنشاؤها (مثل مخرجات genrule) يمكن لبرنامج Bazel استخدام مسار التنفيذ فقط. في هذه الحالة، يجب أن لا يبدأ التعبير العادي بـ '//' بما لا يتطابق مع أيٍّ من مسارات التنفيذ. يمكن استخدام أسماء الحِزم على النحو التالي: --per_file_copt=base/.*\.pb\.cc@-g0. سيطابق هذا كل ملف .pb.cc ضمن دليل باسم base.

يمكن استخدام هذا الخيار عدة مرات.

يتم تطبيق الخيار بغض النظر عن وضع التجميع. على سبيل المثال، يمكن التجميع باستخدام --compilation_mode=opt وتجميع بعض الملفات بشكل انتقائي مع تفعيل تحسين أقوى أو إيقاف التحسين.

تنبيه: إذا تم تجميع بعض الملفات بشكل انتقائي باستخدام رموز تصحيح الأخطاء، قد تتم إزالة الرموز أثناء الربط. ويمكن منع ذلك من خلال ضبط الخيار --strip=never.

البنية: [+-]regex[,[+-]regex]...@option[,option]... حيث يشير regex إلى تعبير عادي يمكن أن يسبقه بالبادئة + لتحديد الأنماط وتضمينها في - لتحديد الأنماط. يشير الاختصار option إلى خيار عشوائي يتم تمريره إلى برنامج التجميع C++. إذا كان أحد الخيارات يحتوي على ,، يجب اقتباسه على النحو التالي \,. يمكن أن تتضمن الخيارات أيضًا @، نظرًا لأنّه سيتم استخدام أول @ فقط لفصل التعبيرات العادية عن الخيارات.

مثال: --per_file_copt=//foo:.*\.cc,-//foo:file\.cc@-O0,-fprofile-arcs يضيف الخيارَين -O0 و-fprofile-arcs إلى سطر الأوامر في برنامج التجميع C++ لجميع ملفات .cc في //foo/ باستثناء file.cc.

--dynamic_mode=mode

تحدد ما إذا كان سيتم ربط برامج ثنائية C++ بشكل ديناميكي، مع التفاعل مع سمة linkstatic في قواعد الإصدار.

وسائل النقل:

• auto: ترجمة إلى وضع يعتمد على النظام الأساسي، default لنظام التشغيل Linux وoff لـ cygwin.
• default: يسمح للبازل باختيار ما إذا كان سيتم ربطه ديناميكيًا. لمزيد من المعلومات، يمكنك الاطّلاع على linkstatic.
• fully: ربط جميع الأهداف ديناميكيًا سيؤدي ذلك إلى تسريع وقت الربط وتقليل حجم البرامج الثنائية الناتجة.
• off: يربط جميع الأهداف في وضع الثابت في الغالب. إذا تم ضبط -static في الروابط، سيتم تغيير الاستهدافات إلى ثابتة.

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

تفعيل Fission، الذي يكتب معلومات تصحيح الأخطاء باستخدام C++ إلى ملفات .dwo المخصصة بدلاً من ملفات .o، حيث سيتم توجيه خلاف ذلك. يؤدي ذلك إلى تقليل حجم الإدخال بشكل كبير إلى الروابط ويمكن أن يقلل من أوقات الروابط.

عند الضبط على [dbg][,opt][,fastbuild] (مثال: --fission=dbg,fastbuild)، يتم تفعيل "التصوير" للمجموعة المحدّدة من أوضاع التجميع. وهو مفيد لإعدادات البازار. عند الضبط على yes، يتم تفعيل Fission في جميع الأحوال. وعند الضبط على no، يتم إيقاف Fission على نحو عام. الإعداد التلقائي هو no.

--force_ignore_dash_static

في حال تم ضبط هذه العلامة، سيتم تجاهل أي خيارات -static في اختيارات ربط cc_* قواعد BUILD. وتهدف هذه الطريقة فقط إلى إيجاد حلول لتحميص إصدارات C++.

--[no]force_pic

في حال تفعيل هذا الإعداد، تنشئ جميع التجميعات C++ رمزًا مستقلاً عن الموضع ("-f;&fPIC")، وتفضّل الروابط المكتبات المصمّمة مسبقًا بتقنية PIC على المكتبات غير المزوّدة بتقنية PIC، وتنشئ الروابط ملفات تنفيذية مستقلة عن الموضع ("-pie"). تم إيقاف الإعداد التلقائي.

--android_resource_shrinking

اختيار ما إذا كان سيتم تقليص الموارد لقواعد Android_binary. لضبط الإعداد التلقائي لسمة shrink_resources على قواعد Android_binary، يُرجى الاطّلاع على المستندات الخاصة بهذه القاعدة للحصول على مزيد من التفاصيل. الإعداد التلقائي هو "إيقاف".

--custom_malloc=malloc-library-target

استخدِم دائمًا طريقة تنفيذ "مركز عملائي" المحدّدة، مع إلغاء جميع السمات malloc="target"، بما في ذلك السمات المستهدفة التي تستخدم القيمة التلقائية (بدون تحديد أي malloc).

--crosstool_top=label

يحدد هذا الخيار موقع حزمة برامج التجميع عبر الأدوات الذي سيتم استخدامه لجميع مواقع C++ أثناء عملية الإنشاء. سيبحث Bazel في ذلك الموقع عن ملف CROSSTool ويستخدم هذه البيانات لتحديد إعدادات --compiler تلقائيًا.

--host_crosstool_top=label

وإذا لم يتم تحديده، يستخدم Bazel قيمة --crosstool_top لتجميع الرمز في إعداد المضيف، مثل الأدوات التي يتم تشغيلها أثناء الإصدار. والغرض الأساسي من هذه العلامة هو تفعيل التجميع.

--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) الذي سيتم استخدامه لتجميع البرامج الثنائية أثناء الإصدار. إذا كنت تريد إنشاء الأداة باستخدام أداة متقاطعة مخصّصة، يجب استخدام ملف CROSSTool بدلاً من تحديد هذه العلامة.

--android_sdk=label

يحدِّد هذا الخيار سلسلة أدوات حزمة تطوير البرامج (SDK) لنظام التشغيل Android/نظام التشغيل Android ومكتبة وقت تشغيل Android التي سيتم استخدامها لإنشاء أي قاعدة ذات صلة بنظام التشغيل Android.

سيتم اختيار حزمة تطوير البرامج (SDK) لنظام التشغيل Android تلقائيًا في حال تحديد قاعدة android_sdk_repository في ملف WORKSPACE.

--java_toolchain=label

يحدّد هذا الخيار تصنيف java_toolchain المستخدَم في تجميع ملفات مصدر Java.

--host_java_toolchain=label

وإذا لم يتم تحديده، يستخدم Bazel قيمة --java_toolchain لتجميع الرمز في إعداد المضيف، مثل الأدوات التي يتم تشغيلها أثناء الإصدار. والغرض الأساسي من هذه العلامة هو تفعيل التجميع.

--javabase=(label)

يحدد هذا الخيار تصنيف تثبيت Java الأساسي لاستخدامه في تشغيل البازل واختبار البازل وللبرامج الثنائية في Java التي أنشأتها قواعد java_binary وjava_test. يتم اشتقاق JAVABASE وJAVA "Make"variable من هذا الخيار.

--host_javabase=label

يُحدِّد هذا الخيار تصنيف تثبيت Java الأساسي لاستخدامه في ضبط المضيف، على سبيل المثال بالنسبة إلى أدوات إنشاء المضيف، بما في ذلك JavaBuilder وsinglejar.

لا يؤدي ذلك إلى اختيار برنامج Java الذي يُستخدم لتجميع ملفات مصدر Java. يمكن اختيار برنامج التجميع من خلال الإعدادات --java_toolchain.

استراتيجية التنفيذ

تؤثر هذه الخيارات في طريقة تنفيذ Bazel للإصدار. ويجب ألا يكون لها تأثير كبير في ملفات المخرجات التي تم إنشاؤها من خلال الإصدار. يكون تأثيرها الرئيسي عادةً في سرعة الإصدار.

--spawn_strategy=strategy

يتحكّم هذا الخيار في مكان تنفيذ الأوامر وكيفية تنفيذها.

• standalone يؤدي تنفيذ الأوامر كعمليات فرعية محلية. تم إيقاف هذه القيمة. يُرجى استخدام الأعمدة local بدلاً منها.
• يؤدي استخدام sandboxed إلى تنفيذ الأوامر داخل وضع الحماية على الجهاز المحلي. ويتطلّب ذلك إدراج جميع ملفات الإدخال والبيانات التابعة للبيانات والأدوات التابعة بشكلٍ مستقل في السمات srcs وdata وtools. يستطيع Bazel تفعيل وضع الحماية المحلي بشكل تلقائي على الأنظمة التي تتيح تنفيذ وضع الحماية.
• local يؤدي تنفيذ الأوامر كعمليات فرعية محلية.
• يتسبب worker في تنفيذ الأوامر باستخدام عامل ثابت، في حال توفّره.
• يؤدي docker إلى تنفيذ الأوامر داخل وضع حماية الإرساء على الجهاز المحلي. يتطلب هذا تثبيت الإرساء.
• في حال تنفيذ الأوامر عن بُعد من قِبل remote، لن يتوفّر هذا الأمر إلا إذا تم ضبط منفّذ عن بُعد بشكل منفصل.

--strategy mnemonic=strategy

يتحكّم هذا الخيار في مكان تنفيذ الأوامر وطريقة تنفيذها، ما يؤدي إلى إلغاء --spawn_strategy (و --genrule_strategy مع اللعبة Gmnrule) بشكل قائم على التذكّر. راجِع --spawn_strategy للاطّلاع على الاستراتيجيات المتوافقة وتأثيراتها.

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

يحدّد هذا الخيار الاستراتيجية التي يجب استخدامها لتنفيذ الأوامر التي تتضمّن أوصافًا تتطابق مع سمة regex_filter معيّنة. يمكنك الاطّلاع على--per_file_copt للحصول على تفاصيل حول مطابقة regex_filter. راجِع --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 runs 'Compiling //foo/bar/baz' with sandboxed مع اتباع الترتيب local.
• مثال: تشغيل --strategy_regexp='Compiling.*/bar=local,sandboxed' 'Compiling //foo/bar/baz' باستخدام الاستراتيجية local والرجوع إلى sandboxed في حال تعذّر إتمامه.

--genrule_strategy=strategy

هذا اختصار مختصر لـ --strategy=Genrule=strategy.

--jobs=n ( -j)

يحدّد هذا الخيار وسيطة عدد صحيح يحدّد عدد المهام التي يجب تنفيذها بشكلٍ متزامن خلال مرحلة التنفيذ ضمن عملية الإنشاء.

--progress_report_interval=n

تعرض "بازل" تقريرًا دوريًا عن الوظائف التي لم تكتمل بعد (مثل الاختبارات التي تستغرق وقتًا طويلاً). يحدد هذا الخيار معدل تكرار إعداد التقارير، وستتم طباعة مدى التقدم كل n ثانية.

والقيمة التلقائية هي 0، ما يعني أنّ الخوارزمية تدريجية: ستتم طباعة التقرير الأول بعد 10 ثوانٍ، ثم على 30 ثانية وبعد ذلك يتم تسجيل هذا التقدّم مرة واحدة كل دقيقة.

عندما تستخدم Bazel التحكّم في المؤشر، كما هو محدّد في --curses، يتم الإبلاغ عن مستوى التقدّم كل ثانية.

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

تحدّد هذه الخيارات كمية الموارد المحلية (ذاكرة الوصول العشوائي (ميغابايت) وعدد النوى المنطقية لوحدة المعالجة المركزية (CPU)) التي يمكن أن تأخذها Bazel في الاعتبار عند جدولة أنشطة الإصدار والاختبار للتشغيل محليًا. ويستخدمون عددًا صحيحًا أو كلمة رئيسية (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

يحدّد هذا الخيار، الذي يتم تفعيله تلقائيًا، ما إذا كان يجب إنشاء روابط الملفات الثنائية للاختبارات والبرامج الثنائية في دليل الإخراج. يمكن أن يكون استخدام --nobuild_runfile_links مفيدًا في التحقق مما إذا كانت كل الأهداف مجمّعة بدون تكبّد عبئ زائد على إنشاء أشجار الملفات.

عند تنفيذ الاختبارات (أو التطبيقات)، يتم تجميع العناصر التابعة لبيانات وقت التشغيل معًا في مكان واحد. داخل شجرة Bazel&#39s الناتجة، يتم عادةً تزويد الجذر الخاص بـ "run;"quot;شهية" كشقيق ثنائي أو اختبار ذي صلة. أثناء تنفيذ الاختبار، يمكن الوصول إلى runfiles باستخدام مسارات النموذج$TEST_SRCDIR/workspace/packagename/filename. يضمن العرض التدرّجي للملفات أن تصل الاختبارات إلى جميع الملفات التي تم الاعتماد عليها بشكل صريح، وليس هناك أي شرط آخر. بشكل تلقائي، يتم تنفيذ العرض التدرّجي للملفات من خلال إنشاء مجموعة من الروابط الرمزية للملفات المطلوبة. ومع نمو مجموعة الروابط، تزداد تكلفة هذه العملية، وبالنسبة إلى بعض الإصدارات الكبيرة، يمكن أن تساهم بشكل كبير في وقت الإنشاء الإجمالي، خاصةً لأن كل اختبار فردي (أو تطبيق) يتطلب شجرة ملفات التشغيل الخاصة بها.

--[no]build_runfile_manifests

يحدّد هذا الخيار الذي يتم تفعيله تلقائيًا ما إذا كان يجب كتابة بيانات runfiles في شجرة النتائج. ويعني إيقافها أنّه --nobuild_runfile_links.

ويمكن إيقافها عند إجراء الاختبارات عن بُعد، حيث سيتم إنشاء أشجار الملفات الجارية عن بُعد من بيانات الذاكرة.

--[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 أوعية الواجهة التي تحتوي على توقيعات الأعضاء غير الخاصين (العامين، والمحميّين، والتلقائيين (الحزمة)) وحقول الوصول) واستخدام حاويات الأواني لتجميع الأهداف التابعة. وبالتالي، من الممكن تجنّب إعادة التجميع عندما يتم إجراء تغييرات على هيئات المحتوى أو الأعضاء الخاصين في الصف فقط.

--[no]interface_shared_objects

يؤدي هذا الخيار إلى تفعيل العناصر المشتركة، ما يجعل البرامج الثنائية والمكتبات المشتركة الأخرى تعتمد على واجهة عنصر مشترك، بدلاً من تنفيذه. عندما يتغير التنفيذ فقط، يمكن أن يتجنّب Bazel إعادة تصميم الأهداف التي تعتمد على المكتبة المشتركة التي تم تغييرها بدون داعٍ.

اختيار الناتج

تحدِّد هذه الخيارات ما سيتم إنشاؤه أو اختباره.

--[no]build

يؤدي هذا الخيار إلى حدوث مرحلة تنفيذ الإصدار، ويكون مفعّلاً بشكل تلقائي. وعند إيقاف تشغيل هذه الميزة، يتم تخطّي مرحلة التنفيذ، ولا تحدث سوى أول مرحلتَين، وهما عملية التحميل والتحليل.

يمكن أن يكون هذا الخيار مفيدًا للتحقق من صحة ملفات BUILD واكتشاف الأخطاء في الإدخالات، بدون إنشاء أي شيء.

--[no]build_tests_only

في حال تحديد قواعد Bazel، يجب أن تنشئ ما يلزم فقط لتشغيل قاعدتَي *_test وtest_suite التي لم تتم فلترتها بسبب الحجم أو المهلة أو العلامة أو اللغة. في حال اختيار التطبيق، سيتجاهل Bazel الأهداف الأخرى المحدَّدة في سطر الأوامر. وفقًا للإعدادات التلقائية، يكون هذا الخيار غير مفعّل، وسيعمل تطبيق Bazel على إنشاء كل العناصر المطلوبة، بما في ذلك قاعدتا *_test وtest_suite اللتان يتم استبعادهما من الاختبار. ويُعدّ هذا مفيدًا لأن تشغيل bazel test --build_tests_only foo/... قد لا يرصد جميع فواصل الإصدارات في شجرة foo.

--[no]check_up_to_date

يؤدي هذا الخيار إلى عدم إجراء Bazel لإصدار، ومع ذلك يتحقق فقط من تحديث جميع الأهداف المحددة. إذا كان الأمر كذلك، تكتمل عملية الإنشاء بنجاح، على النحو المعتاد. ومع ذلك، إذا كانت أي ملفات قديمة، بدلاً من إنشاؤها، سيتم الإبلاغ عن خطأ وفشل الإصدار. قد يكون هذا الخيار مفيدًا في تحديد ما إذا كان قد تم إجراء الإصدار مؤخرًا أكثر من التعديل المصدر (على سبيل المثال، لعمليات التحقق قبل الإرسال) بدون تحمّل تكلفة الإصدار.

يمكنك أيضًا الاطّلاع على --check_tests_up_to_date.

--[no]compile_one_dependency

اجمع تبعية واحدة لملفات الوسيطة. ويُعدّ هذا مفيدًا في التحقّق من ملفات المصدر في IDE، على سبيل المثال، عن طريق إعادة إنشاء استهداف واحد يعتمد على الملف المصدر لرصد الأخطاء في أقرب وقت ممكن في دورة التعديل/الإنشاء/الاختبار. تؤثر هذه الوسيطة في طريقة تفسير كل وسيطات عدم الإبلاغ عن المحتوى: يجب أن تكون كل وسيطة عبارة عن تصنيف هدف ملف أو اسم ملف عادي مقارنة بدليل العمل الحالي، وأنّ هناك قاعدة واحدة تعتمد على كل اسم ملف مصدر. موجَّه إلى

أما بالنسبة إلى مصادر C++ وJava، فيُفضّل استخدام القواعد في مساحة اللغة نفسها. بالنسبة إلى القواعد المتعددة التي لها نفس الإعداد المفضّل، يتم اختيار القاعدة التي تظهر أولاً في ملف BUILD. نمط مُستهدَف بشكل صريح لا يشير إلى ملف مصدر يؤدي إلى حدوث خطأ.

--save_temps

يؤدي الخيار --save_temps إلى حفظ مخرجات مؤقتة من برنامج التجميع. وتشمل هذه الملفات ملفات .s (رمز التجميع) و .i (المعالج المسبق C) و .ii (الملفات التي تمت معالجتها مسبقًا C++ ). هذه النتائج مفيدة غالبًا لتصحيح الأخطاء. سيتم إنشاء درجات الحرارة فقط لمجموعة الاستهدافات المحدّدة في سطر الأوامر.

لا تعمل العلامة --save_temps حاليًا إلا مع قواعد cc_*.

للتأكّد من أن Bazel يطبع موقع ملفات الإخراج الإضافية، تحقّق من أنّ إعداد --show_result n مرتفع بما يكفي.

--build_tag_filters=tag[,tag]*

في حال اختيار أداة Bazel، ستنشئ فقط الأهداف التي تتضمّن علامة واحدة مطلوبة على الأقل (إذا تم تحديد أيٍّ منها) ولا تحتوي على أي علامات مستبعدة. يتم تحديد فلتر علامة الإصدار كقائمة مفصولة بفواصل من الكلمات الرئيسية للعلامات، والتي تسبقها بشكل اختياري مع العلامة #39;-&#39؛ العلامة المستخدمة للإشارة إلى العلامات المستبعدة. قد تحتوي العلامات المطلوبة أيضًا على علامة سابقة '+'.

عند إجراء الاختبارات، يتجاهل Bazel --build_tag_filters لاستهدافات الاختبار التي تم إنشاؤها وتشغيلها حتى إذا لم تتطابق مع هذا الفلتر. ولتجنّب إنشائها، يمكنك فلترة الأهداف المستهدفة باستخدام --test_tag_filters أو عن طريق استبعادها صراحةً.

--test_size_filters=size[,size]*

في حال التحديد، سيختبر Bazel (أو يُنشئه في حال تحديد --build_tests_only) أيضًا مع الاستهدافات ذات الحجم المحدّد فقط. يتم تحديد فلتر "حجم الاختبار" كقائمة مفصولة بفواصل من قيم حجم الاختبار المسموح بها (صغير أو متوسط أو كبير أو كبير)، وتكون مسبوقة اختياريًا بعلامة '-' مستخدَمة للإشارة إلى أحجام الاختبار المستبعدة. على سبيل المثال:

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

و

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

ستختبر فقط الاختبارات الصغيرة والمتوسطة داخل //foo.

لا يتم تطبيق فلترة حجم الاختبار بشكل تلقائي.

--test_timeout_filters=timeout[,timeout]*

في حال التحديد، سيختبر Bazel (أو ينشئه في حال تحديد --build_tests_only) أيضًا الأهداف المستهدفة فقط من خلال المهلة المحدّدة. يتم تحديد فلتر مهلة الاختبار كقائمة مفصولة بفواصل لقيم مهلة الاختبار المسموح بها (قصيرة، معتدلة، طويلة أو دائمة)، مسبوقة اختياريًا باستخدام '-' علامة تشير إلى انتهاء مهلة الاختبار المستبعدة. اطّلِع على --test_size_filters للحصول على مثال للبنية.

ولا يتم تطبيق فلترة مهلة الاختبار تلقائيًا.

--test_tag_filters=tag[,tag]*

في حال اختيار أداة Bazel، ستختبرها (أو ستنشئها في حال تحديد --build_tests_only) أيضًا لاختبار القيم المستهدفة التي تحتوي على علامة مطلوبة واحدة على الأقل (إذا تم تحديد أيٍّ منها) ولا تحتوي على أي علامات مستبعدة. يتم تحديد فلتر علامة الاختبار كقائمة من علامات الكلمات الرئيسية المفصولة بفواصل، اختياريًا يسبقها الرمز '-' العلامة المستخدمة للإشارة إلى العلامات المستبعدة. قد تحتوي العلامات المطلوبة أيضًا على علامة سابقة '+'.

على سبيل المثال:

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

سيختبر الأهداف التي تم وضع علامة عليها باستخدام العلامة performance أو stress، ولكن لم يتم وضع علامة عليها باستخدام العلامة flaky.

ولا يتم تطبيق فلترة علامات الاختبار تلقائيًا. وتجدر الإشارة إلى أنه يمكنك أيضًا الفلترة بعلامات size وlocal في الاختبار بهذه الطريقة.

--test_lang_filters=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.