קבוצות ביצוע מאפשרות ליצור כמה פלטפורמות הפעלה בתוך אותו יעד. לכל קבוצת הפעלה יש תלויות Toolchain משלה ומבצעת רזולוציה של Toolchain משלה.
רקע
קבוצות ביצוע מאפשרות למחבר הכלל להגדיר קבוצות של פעולות, שבכל אחת מהן יש פלטפורמת ביצוע שונה. מספר פלטפורמות להרצה יכולות לאפשר ביצוע של פעולות שונות. לדוגמה, הידור של אפליקציה ל-iOS בעובד מרוחק (Linux) ולאחר מכן קישור/חתימת קוד של עובד Mac מקומי.
היכולת להגדיר קבוצות של פעולות עוזרת גם להקל על השימוש בפעולות בשרת proxy לצורך ציון פעולות. הזיכרון לא בטוח להיות ייחודי, והוא יכול להתייחס רק לפעולה אחת. זה שימושי במיוחד בהקצאת משאבים נוספים לזיכרון ספציפי ועיבוד פעולות אינטנסיביות כמו קישור ב-build של C++ מבלי להקצות יותר מדי משימות בפחות ביקוש.
הגדרת קבוצות הפעלה
במהלך הגדרת הכלל, יוצרי הכללים יכוליםלהצהיר על קבוצה של קבוצות הפעלה. בכל קבוצת הפעלה, מחבר הכללים יכול לציין
כל מה שצריך כדי לבחור פלטפורמת הפעלה לקבוצת הביצוע הזאת,
כלומר אילוצים דרך exec_compatible_with
וסוגי שרשרת הכלים דרך
toolchain
.
# foo.bzl
my_rule = rule(
_impl,
exec_groups = {
“link”: exec_group(
exec_compatible_with = [ "@platforms//os:linux" ]
toolchains = ["//foo:toolchain_type"],
),
“test”: exec_group(
toolchains = ["//foo_tools:toolchain_type"],
),
},
attrs = {
"_compiler": attr.label(cfg = config.exec("link"))
},
)
בקטע הקוד שלמעלה, אפשר לראות גם שהכלים תלויים בכלי
כך שניתן לציין את המעבר של קבוצת execreed באמצעות פרמטר המאפיין
cfg
והמודול
config
. המודול חושף פונקציית exec
שמשתמשת בפרמטר אחד של מחרוזת, כלומר השם של קבוצת ה-exec שעבורה יש ליצור את התלות.
כמו בכללים מותאמים, קבוצת הביצוע test
נמצאת כברירת מחדל בכללי הבדיקה של Starlark.
ירושה מקבוצת ביצוע
בנוסף להגדרת אילוצים וארגזי כלים משלה, קבוצת הטמעה חדשה
יכולה להצהיר שהיא רוצה לרשת את קבוצת הברירת מחדל
של הכלל על ידי העברת הפרמטר copy_from_rule = True
. זו שגיאה בהגדרה של
copy_from_rule
כ-True וגם להעביר את exec_compatible_with
או
toolchains
.
קבוצת הפעלה שמקבלת בירושה מקבוצת ההפעלה המוגדרת כברירת מחדל מעתיקים את המגבלות, ערכות הכלים ומאפייני הביצוע מברירת המחדל. כולל אילוצים ומאפייני הפעלה שהוגדרו ברמת היעד, ולא רק אלו שצוינו על ידי הכלל עצמו. במילים אחרות, בהינתן הדברים הבאים:
# foo.bzl
my_rule = rule(
_impl,
exec_groups = {
“copied”: exec_group(
copy_from_rule = True,
# This will inherit exec_compatible_with and toolchains.
# Setting them here directly would be an error, however.
),
},
toolchains = ["//foo_tools:toolchain_type"],
exec_compatible_with = ["@platforms//os:linux"],
)
# BUILD
my_rule(
name = "demo",
exec_compatible_with = [":local_constraint"],
)
קבוצת הביצוע של copied
ליעד שהוגדר demo
תכלול את כל הנתונים הבאים:
- //fool_tools:toolchain_type
- @platforms//os:linux
- :local_constraint
גישה לקבוצות ביצוע
בהטמעה של הכלל, אפשר להצהיר שיש להריץ את הפעולות
בפלטפורמה לביצוע של קבוצת הפעלה. אפשר לעשות זאת באמצעות exec_group
השיטה של יצירת פעולות, ספציפית ctx.actions.run
ו-
ctx.actions.run_shell
.
# foo.bzl
def _impl(ctx):
ctx.actions.run(
inputs = [ctx.attr._some_tool, ctx.srcs[0]]
exec_group = "compile",
# ...
)
מחברים לכלל יוכלו גם לגשת לערכות הכלים המתוקנות של קבוצות הפעלה, בדומה לאופן שבו אתם יכולים לגשת לארגז הכלים המטורגט של יעד:
# foo.bzl
def _impl(ctx):
foo_info = ctx.exec_groups["link"].toolchains["//foo:toolchain_type"].fooinfo
ctx.actions.run(
inputs = [foo_info, ctx.srcs[0]]
exec_group = "link",
# ...
)
שימוש בקבוצות הפעלה כדי להגדיר מאפייני הפעלה
קבוצות ביצוע משולבות עם המאפיין
exec_properties
הכולל כל כלל ומאפשר לכותב היעד לציין
סקריפט של מאפיינים המועבר אל מכונות ההפעלה. לדוגמה, אם רציתם להגדיר נכס מסוים, למשל זיכרון, עבור היעד הזה ולתת
לפעולות מסוימות הקצאת זיכרון גבוהה יותר, עליכם לכתוב רשומה של exec_properties
עם מפתח משופר של קבוצת הפעלה, למשל:
# BUILD
my_rule(
name = 'my_target',
exec_properties = {
'mem': '12g',
'link.mem': '16g'
}
…
)
כל הפעולות שיבוצעו עם exec_group = "link"
יוצגו בנכסי ה-execable
במילון כ-{"mem": "16g"}
. כפי שניתן לראות כאן, הגדרות ברמת קבוצת הביצוע מבטלות הגדרות ברמת היעד.
קבוצות ביצוע של כללים מותאמים
קבוצות הביצוע הבאות זמינות לפעולות המוגדרות באמצעות כללים מותאמים:
test
: בדיקת הפעולות של הראנר.cpp_link
: פעולות קישור +C+.
יצירת קבוצות של execx כדי להגדיר מאפייני exec
לפעמים רוצים להשתמש בקבוצת מנהלים כדי לבצע פעולות ספציפיות
בנכסי execution אחרים, אבל לא רוצים להשתמש בערכות כלים או במגבלות שונות מאשר
בכלל. במצבים האלה, אפשר ליצור קבוצות מנהלים ב-AdWords באמצעות הפרמטר
copy_from_rule
:
# foo.bzl
# Creating an exec group with `copy_from_rule=True` is the same as explicitly
# setting the exec group's toolchains and constraints to the same values as the
# rule's respective parameters.
my_rule = rule(
_impl,
exec_compatible_with = ["@platforms//os:linux"],
toolchains = ["//foo:toolchain_type"],
exec_groups = {
# The following two groups have the same toolchains and constraints:
“foo”: exec_group(copy_from_rule = True),
"bar": exec_group(
exec_compatible_with = ["@platforms//os:linux"],
toolchains = ["//foo:toolchain_type"],
),
},
)
#
קבוצות הפעלה ומאפייני ביצוע של פלטפורמות
אפשר להגדיר exec_properties
לקבוצות הפעלה שרירותיות
ביעדי פלטפורמה (בשונה מ-exec_properties
שמוגדר ישירות ביעד, שבו
נכסים של קבוצות הפעלה לא ידועות נדחו). לאחר מכן היעדים יורשים
את פלטפורמת הביצועexec_properties
ומשפיעה על קבוצת הביצוע שמוגדרת כברירת מחדל
ועל כל קבוצת הפעלה רלוונטית אחרת.
לדוגמה, נניח שכדי לבצע בדיקת C++ יש צורך במשאב מסוים, אך הוא לא נדרש לצורך קישור וקישור. ניתן לדמות את המודל הזה באופן הבא:
constraint_setting(name = "resource")
constraint_value(name = "has_resource", constraint_setting = ":resource")
platform(
name = "platform_with_resource",
constraint_values = [":has_resource"],
exec_properties = {
"test.resource": "...",
},
)
cc_test(
name = "my_test",
srcs = ["my_test.cc"],
exec_compatible_with = [":has_resource"],
)
ל-exec_properties
שמוגדרים ישירות ביעדים