Workspace kuralları, genellikle harici bağımlılıkları çekmek için kullanılır. ana deponun dışında bulunan bir kaynak kodu içerir.
Not: Bazel, yerel çalışma alanı kurallarının yanı sıra çeşitli Starlark çalışma alanı kuralları, özellikle de arşivleriyle birlikte çalışır.
Kurallar
bind
Kural kaynağını görüntülebind(name, actual, compatible_with, deprecation, distribs, features, licenses, restricted_to, tags, target_compatible_with, testonly, visibility)
Uyarı: bind()
kullanılması önerilmez. "Bağlantıyı kaldırmayı düşünün" bölümüne bakın uzun süreyle
ve alternatifleri üzerine konuşacağız. Özellikle de proje yaşam döngüsü boyunca
repo_mapping
depo özelliklerini aşağıda görebilirsiniz.
Uyarı: select()
, bind()
içinde kullanılamaz. Aşağıdakiler için Yapılandırılabilir Özellikler SSS sayfasına bakın
içerir.
//external
paketinde bir hedefe takma ad verir.
//external
paketi "normal" değil paket: harici/ dizin yok,
bu nedenle bir "sanal paket" olarak düşünülebilir. içerir.
Örnekler
Bir hedefe takma ad vermek için hedefi WORKSPACE dosyasında bind
. Örneğin,
adında bir java_library
hedefi olduğunu varsayalım
//third_party/javacc-v2
. Bu takma ad,
WORKSPACE dosyası:
bind( name = "javacc-latest", actual = "//third_party/javacc-v2", )
Artık hedefler şuna bağlı olabilir: //external:javacc-latest
//third_party/javacc-v2
. javacc-v3 yayınlanırsa bind
kuralı
güncellendi ve //external:javacc-latest
öğesine bağlı tüm BUILD dosyaları artık
Javacc-v3'e bağımlıdır ve düzenlenmesi gerekmez.
Bağlama, harici depolardaki hedefleri çalışma alanınızda kullanılabilir hale getirmek için de kullanılabilir.
Örneğin, @my-ssl
adlı bir uzak depo varsa
WORKSPACE dosyası ve bu dosyanın cc_library hedefi //src:openssl-lib
varsa
bind
kullanarak bu hedef için bir takma ad oluşturun:
bind( name = "openssl", actual = "@my-ssl//src:openssl-lib", )
Ardından, çalışma alanınızdaki bir BUILD dosyasında bağlı hedef aşağıdaki gibi kullanılabilir:
cc_library( name = "sign-in", srcs = ["sign_in.cc"], hdrs = ["sign_in.h"], deps = ["//external:openssl"], )
sign_in.cc
ve sign_in.h
içinde,
//external:openssl
, deposuna göre kendi yolu kullanılarak yönlendirilebilir
kök. Örneğin, @my-ssl//src:openssl-lib
için kural tanımı şunun gibiyse,
bu:
cc_library( name = "openssl-lib", srcs = ["openssl.cc"], hdrs = ["openssl.h"], )
Bu durumda, sign_in.cc
öğesinin kapsamı aşağıdaki gibi görünebilir:
#include "sign_in.h" #include "src/openssl.h"
Bağımsız değişkenler
Özellikler | |
---|---|
name |
Ad; zorunlu Bu hedef için benzersiz bir ad. |
actual
|
Etiket; varsayılan değer Bu hedef mevcut olmalıdır ancak herhangi bir kural türünde (bağlama dahil) olabilir. Bu özellik atlanırsa |
local_repository
Kural kaynağını görüntülelocal_repository(name, path, repo_mapping)
Yerel dizinden hedeflerin bağlanmasına izin verir. Bu, mevcut deponun bu diğer dizinde tanımlanan hedefleri kullanır. Bağlantı bölümünü inceleyin.
Örnekler
Mevcut deponun, ~/chat-app dizininde rootlanmış bir sohbet istemcisi olduğunu varsayalım. Google
, farklı bir depoda tanımlanmış bir SSL kitaplığı kullanmak istiyor: ~/ssl. İlgili içeriği oluşturmak için kullanılan
SSL kitaplığında bir hedef //src:openssl-lib
var.
Kullanıcı, hedefine aşağıdaki satırları ekleyerek bu hedefe bir bağımlılık ekleyebilir: ~/chat-app/WORKSPACE:
local_repository( name = "my-ssl", path = "/home/user/ssl", )
Hedefler, buna bağımlı bir bağımlılık olarak @my-ssl//src:openssl-lib
belirtir
kitaplığını tanıtır.
Bağımsız değişkenler
Özellikler | |
---|---|
name |
Ad; zorunlu Bu hedef için benzersiz bir ad. |
path
|
String; zorunlu Yerel depo dizininin yolu.Bu, deponun WORKSPACE dosyası olarak kaydedin. Yol mutlak olabilir ya da ana deponun WORKSPACE dosyası olarak kaydedin. |
repo_mapping
|
Sözlük: Dize -> String; varsayılan değer Örneğin, |
new_local_repository
Kural kaynağını görüntülenew_local_repository(name, build_file, build_file_content, path, repo_mapping, workspace_file, workspace_file_content)
Yerel bir dizinin Bazel deposuna dönüştürülmesini sağlar. Bu, şu anki durumun depo, dosya sisteminde herhangi bir yerden hedefleri tanımlayabilir ve kullanabilir.
Bu kural, WORKSPACE dosyası ve aşağıdakileri içeren bir alt dizin oluşturarak bir Bazel deposu oluşturur:
belirtilen BUILD dosyasının ve yolun sembolik bağlantılarını içerir. Derleme dosyası,
path
Zaten bir WORKSPACE dosyası ve bir BUILD dosyası içeren dizinler için
local_repository
kuralı kullanılabilir.
Örnekler
Mevcut deponun, ~/chat-app dizininde rootlanmış bir sohbet istemcisi olduğunu varsayalım. Google , farklı bir dizinde tanımlanmış bir SSL kitaplığı kullanmak istiyor: ~/ssl.
Kullanıcı SSL kitaplığı için BUILD dosyası oluşturarak bağımlılık ekleyebilir (~/chat-app/BUILD.my-ssl) şunları içeren:
java_library( name = "openssl", srcs = glob(['*.java']) visibility = ["//visibility:public"], ).
Ardından, şu satırları ~/chat-app/WORKSPACE alanına ekleyebilirler:
new_local_repository( name = "my-ssl", path = "/home/user/ssl", build_file = "BUILD.my-ssl", )
Bu işlem, /home/user/ssl ile sembolik bir şekilde bağlantılı bir @my-ssl
deposu oluşturur.
Hedefler, @my-ssl//:openssl
bir hedefin eklenmesine eklenerek bu kitaplığa bağlı olabilir
ve bildirmeyi konuştuk.
new_local_repository
öğesini yalnızca değil, tek bir dosya eklemek için de kullanabilirsiniz
dizin oluşturabilirsiniz. Örneğin, /home/username/Downloads/piano.jar dizininde bir jar dosyanızın olduğunu varsayalım. Siz
aşağıdakini WORKSPACE dosyanıza ekleyerek sadece o dosyayı derlemenize ekleyebilir:
new_local_repository( name = "piano", path = "/home/username/Downloads/piano.jar", build_file = "BUILD.piano", ).
Ayrıca aşağıdaki BUILD.piano dosyasını da oluşturun:
java_import( name = "play-music", jars = ["piano.jar"], visibility = ["//visibility:public"], ). Ardından hedefler, piano.jar'ı kullanmak için
@piano//:play-music
uygulamasına bağlı olabilir.
Bağımsız değişkenler
Özellikler | |
---|---|
name |
Ad; zorunlu Bu hedef için benzersiz bir ad. |
build_file
|
Ad; varsayılan değer Build_file veya build_file_content değeri belirtilmelidir. Bu özellik, ana çalışma alanına bağlı bir etikettir. Dosyanın BUILD olarak adlandırılır ama bazen de devam eder. (BUILD.new-repo-name gibi bir komut dosyası adlandırmanız için (bunu, deponun gerçek BUILD dosyalarından ayırt ediyoruz.) |
build_file_content
|
String; varsayılan değer Build_file veya build_file_content değeri belirtilmelidir. |
path
|
String; zorunlu Yerel dosya sistemindeki bir yoldur.Bu değer mutlak olabilir ya da ana deponun WORKSPACE dosyasına göre olabilir. |
repo_mapping
|
Sözlük: Dize -> String; varsayılan değer Örneğin, |
workspace_file
|
Ad; varsayılan değer workspace_file veya workspace_file_content özelliklerinden yalnızca biri belirtilebilir ancak ikisi birden belirtilemez. Bu özellik, ana çalışma alanına bağlı bir etikettir. Dosyanın WORKSPACE adlı, ancak şeklinde de olabilir. (WORKSPACE.new-repo-name gibi bir dosya kullanılabilir (bunu, deposunun asıl WORKSPACE dosyalarından ayırt edebilirsiniz.) |
workspace_file_content
|
String; varsayılan değer workspace_file veya workspace_file_content özelliklerinden yalnızca biri belirtilebilir ancak ikisi birden belirtilemez. |