כללי סביבת עבודה משמשים למשיכת יחסי תלות חיצוניים, שהם בדרך כלל קוד מקור שנמצא מחוץ למאגר הראשי.
הערה: מעבר לכללי סביבת העבודה המקוריות, Bazel מטמיעה גם כמה כללים לסביבת עבודה של Starlark, ובמיוחד כאלה שמטפלים במאגרי git או בארכיונים שמתארחים באינטרנט. הנתונים.
כללים
איגוד
bind(name, actual, compatible_with, deprecation, distribs, features, licenses, restricted_to, tags, target_compatible_with, testonly, visibility)
אזהרה: לא מומלץ להשתמש ב-bind()
. עיינו במאמר "כדאי להסיר את האיגוד" כדי לדון
בנושאים ארוכים ובחלופות שלהם. בפרט, כדאי להשתמש ב
repo_mapping
מאפייני מאגר.
אזהרה: לא ניתן להשתמש ב-select()
ב-bind()
. לקבלת פרטים, ניתן לעיין בשאלות הנפוצות לגבי מאפיינים הניתנים להגדרה.
מתן יעד לחבילה //external
.
החבילה //external
אינה חבילה "רגילה": אין תיקייה חיצונית/ ספרייה,
ניתן לחשוב עליה כ "חבילה וירטואלית" שמכילה את כל היעדים המקושרים.
דוגמאות
כדי לתת יעד לכתובת bind
, יש לציין אותה בקובץ WORKSPACE. לדוגמה, נניח שיש יעד מסוג java_library
שנקרא
//third_party/javacc-v2
. הוספת כתובת ה-URL לקובץ
WORKSPACE עשויה להוביל לכך כינוי.
bind( name = "javacc-latest", actual = "//third_party/javacc-v2", )
היעדים יכולים להיות תלויים ב//external:javacc-latest
במקום
ב//third_party/javacc-v2
. אם משיקים את Javacc-v3, אפשר לעדכן את הכלל bind
וכל קובצי BUILD בהתאם ל-//external:javacc-latest
תלויים כעת ב-Javacc-v3 ללא צורך בעריכה.
אפשר להשתמש גם בקישור כדי שיעדים במאגרים חיצוניים יהיו זמינים לסביבת העבודה שלך.
לדוגמה, אם מאגר מרוחק בשם @my-ssl
יובא בקובץ WORKSPACE ויש לו יעד cc_library //src:openssl-lib
, תוכל ליצור כינוי עבור טירגוט באמצעות bind
:
bind( name = "openssl", actual = "@my-ssl//src:openssl-lib", )
לאחר מכן, בקובץ BUILD בסביבת העבודה שלכם, תוכלו להשתמש ביעד המוגבל באופן הבא:
cc_library( name = "sign-in", srcs = ["sign_in.cc"], hdrs = ["sign_in.h"], deps = ["//external:openssl"], )
בתוך sign_in.cc
ו-sign_in.h
, ניתן להפנות את קובצי הכותרת שנחשפו על ידי //external:openssl
באמצעות הנתיב שלהם יחסית לבסיס המאגר שלהם. לדוגמה, אם הגדרת הכלל של @my-ssl//src:openssl-lib
נראית כך:
cc_library( name = "openssl-lib", srcs = ["openssl.cc"], hdrs = ["openssl.h"], )
אז הרכיבים של sign_in.cc
עשויים להיראות כך:
#include "sign_in.h" #include "src/openssl.h"
ארגומנטים
מאפיינים | |
---|---|
name |
שם ייחודי ליעד זה. |
actual
|
היעד הזה חייב להתקיים, אבל הוא יכול להיות כל סוג של כלל (כולל איגוד). אם מאפיין זה יושמט, כללים שמפנים ליעד זה בקבוצת המודעות |
מאגר_מקומי
local_repository(name, path, repo_mapping)
מאפשר לעמוד ביעדים מספרייה מקומית. המשמעות היא שהמאגר הנוכחי יכול להשתמש ביעדים שהוגדרו בספרייה האחרת. לפרטים נוספים, ניתן לעיין בקטע האיגוד.
דוגמאות
נניח שהמאגר הנוכחי הוא לקוח צ'אט המבוסס על הספרייה ~/chat-app. היא רוצה להשתמש בספריית SSL, המוגדרת במאגר אחר: ~/ssl. ספריית ה-SSL כוללת יעד //src:openssl-lib
.
המשתמש יכול להוסיף תלות ביעד הזה על ידי הוספת השורות הבאות ב-~/chat-app/WORKSPACE:
local_repository( name = "my-ssl", path = "/home/user/ssl", )
יעדים יציינו את @my-ssl//src:openssl-lib
כתלויות
בספרייה הזו.
ארגומנטים
מאפיינים | |
---|---|
name |
שם ייחודי ליעד זה. |
path
|
הקובץ חייב להיות נתיב לספרייה המכילה את קובץ WORKSPACE של המאגר. הנתיב יכול להיות אבסולוטי או יחסי לקובץ WORKSPACE של המאגר הראשי. |
repo_mapping
|
לדוגמה, רשומה |
new_local_repository
new_local_repository(name, build_file, build_file_content, path, repo_mapping, workspace_file, workspace_file_content)
מאפשר להפוך ספרייה מקומית למאגר של Bazel. פירוש הדבר הוא שמאגר הנתונים הנוכחי יכול להגדיר יעדים ולהשתמש בהם מכל מקום במערכת הקבצים.
הכלל הזה יוצר מאגר Bazel על ידי יצירת קובץ WORKSPACE וספריית משנה הכוללים קישורים סימבוליים לקובץ ולנתיב של BUILD. קובץ ה-build צריך ליצור יעדים ביחס ל-path
. אם יש ספריות שכבר מכילות קובץ WORKSPACE וקובץ BUILD, אפשר להשתמש בכלל
local_repository
.
דוגמאות
נניח שהמאגר הנוכחי הוא לקוח צ'אט המבוסס על הספרייה ~/chat-app. היא רוצה להשתמש בספריית SSL, המוגדרת בספרייה אחרת: ~/ssl.
המשתמש יכול להוסיף תלות על ידי יצירת קובץ BUILD עבור ספריית SSL (~/chat-app/BUILD.my-ssl) המכיל:
java_library( name = "openssl", srcs = glob(['*.java']) visibility = ["//visibility:public"], )
לאחר מכן הוא יוכל להוסיף את השורות הבאות אל ~/chat-app/WORKSPACE:
new_local_repository( name = "my-ssl", path = "/home/user/ssl", build_file = "BUILD.my-ssl", )
פעולה זו תיצור מאגר @my-ssl
המקשר אל /home/user/ssl.
היעדים יכולים להיות תלויים בספרייה זו על ידי הוספת @my-ssl//:openssl
ליחסי תלות של היעד.
ניתן גם להשתמש ב-new_local_repository
כדי לכלול קבצים בודדים, ולא רק ספריות. לדוגמה, נניח שהיה לך קובץ Jam בכתובת /home/username/Downloads/piano.jan. ניתן
להוסיף רק את הקובץ הזה לגרסת ה-build על ידי הוספת הפקודות הבאות לקובץ WORKSPACE:
new_local_repository( name = "piano", path = "/home/username/Downloads/piano.jar", build_file = "BUILD.piano", )
ויצירת קובץ BUILD.piano הבא:
java_import( name = "play-music", jars = ["piano.jar"], visibility = ["//visibility:public"], )לאחר מכן, בהתאם למיקוד ב-
@piano//:play-music
, ייתכן שהטירגוט יהיה תלוי בפסנתר.
ארגומנטים
מאפיינים | |
---|---|
name |
שם ייחודי ליעד זה. |
build_file
|
יש לציין את build_file או build_file_content. מאפיין זה הוא תווית יחסית לסביבת העבודה הראשית. אין צורך לתת לקובץ שם בשם BUILD, אבל הוא יכול להיות. (משהו כמו BUILD.new-repo-name עשוי לעבוד היטב להבחנה בינו לבין קובצי ה-BUILD של המאגר). |
build_file_content
|
יש לציין את build_file או build_file_content. |
path
|
זה יכול להיות מוחלט או יחסי לקובץ WORKSPACE של המאגר הראשי. |
repo_mapping
|
לדוגמה, רשומה |
workspace_file
|
אפשר לציין את workspace_file או את workspace_file_content, אבל לא את שניהם. מאפיין זה הוא תווית יחסית לסביבת העבודה הראשית. אין צורך לתת שם לקובץ, אבל הוא יכול להיות. (משהו כמו WORKSPACE.new-repo-name עשוי לפעול היטב להבחנה בינו לבין קובצי ה-WORKSPACE של המאגר בפועל.) |
workspace_file_content
|
אפשר לציין את workspace_file או את workspace_file_content, אבל לא את שניהם. |