Çalışma alanı kuralları, genellikle ana deposun dışında bulunan kaynak kodu olan harici bağımlılıkları almak için kullanılır.
Not: Bazel, yerel Workspace kurallarının yanı sıra çeşitli Starlark Workspace kuralları da yerleştirir. Özellikle web'de barındırılan git depolarıyla veya arşivleriyle ilgilenen kurallar bu kapsamdadır.
Kurallar
bind
Kural kaynağını görüntülemebind(name, actual, compatible_with, deprecation, distribs, features, licenses, restricted_to, tags, target_compatible_with, testonly, visibility)
Uyarı: bind()
kullanılması önerilmez. Sorunları ve alternatifleri hakkında uzun bir tartışma için "Bağlantıyı kaldırmayı düşünün" bölümüne bakın. Özellikle repo_mapping
depolama alanı özelliklerini kullanmayı düşünün.
Uyarı: select()
, bind()
içinde kullanılamaz. Ayrıntılar için Yapılandırılabilir Özellikler ile ilgili SSS başlıklı makaleyi inceleyin.
//external
paketinde bir hedefe takma ad verir.
//external
paketi "normal" bir paket değildir: Harici/ dizin yoktur, bu nedenle tüm bağlı hedefleri içeren bir "sanal paket" olarak düşünülebilir.
Örnekler
Bir hedefe takma ad vermek için hedefi WORKSPACE dosyasında bind
. Örneğin, //third_party/javacc-v2
adlı bir java_library
hedefi olduğunu varsayalım. Aşağıdakiler WORKSPACE dosyasına eklenerek bu adla başka bir ad verilebilir:
bind( name = "javacc-latest", actual = "//third_party/javacc-v2", )
Artık hedefler //third_party/javacc-v2
yerine //external:javacc-latest
'e bağlı olabilir. javacc-v3 yayınlanırsa bind
kuralı güncellenebilir ve //external:javacc-latest
'e bağlı tüm BUILD dosyaları artık düzenlenmesine gerek kalmadan javacc-v3'e bağlı olur.
Bağlama, harici depolardaki hedefleri çalışma alanınızda kullanılabilir hale getirmek için de kullanılabilir.
Örneğin, WORKSPACE dosyasına içe aktarılan @my-ssl
adlı bir uzak depolama alanı varsa ve bu depolama alanında cc_library hedefi //src:openssl-lib
varsa bind
kullanarak bu hedef için bir takma ad oluşturabilirsiniz:
bind( name = "openssl", actual = "@my-ssl//src:openssl-lib", )
Ardından, bağlı hedef, çalışma alanınızdaki bir BUILD dosyasında 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
tarafından sunulan üstbilgi dosyalarına, depo köklerine göreli yolları kullanılarak referans verilebilir. Örneğin, @my-ssl//src:openssl-lib
için kural tanımı aşağıdaki gibiyse:
cc_library( name = "openssl-lib", srcs = ["openssl.cc"], hdrs = ["openssl.h"], )
Bu durumda sign_in.cc
'nin içeriği şöyle 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 türde kural (bağlama dahil) olabilir. Bu özellik atlanırsa |
local_repository
Kural kaynağını gösterlocal_repository(name, path, repo_mapping)
Yerel dizinlerdeki hedeflerin bağlanmasına izin verir. Yani mevcut depo, bu diğer dizinde tanımlanan hedefleri kullanabilir. Daha fazla bilgi için bağlantı oluşturma bölümüne bakın.
Örnekler
Mevcut deponun, kökü ~/chat-app dizininde olan bir sohbet istemcisi olduğunu varsayalım. Bu istemci, farklı bir depoda (~/ssl) tanımlanmış bir SSL kitaplığı kullanmak istiyor. SSL kitaplığında bir //src:openssl-lib
hedefi vardır.
Kullanıcı, ~/chat-app/WORKSPACE adresine aşağıdaki satırları ekleyerek bu hedefe bağımlılık ekleyebilir:
local_repository( name = "my-ssl", path = "/home/user/ssl", )
Hedefler, bu kitaplığa bağımlı olacak bir bağımlılık olarak @my-ssl//src:openssl-lib
'ü belirtir.
Bağımsız değişkenler
Özellikler | |
---|---|
name |
Ad; zorunlu Bu hedef için benzersiz bir ad. |
path
|
Dize; zorunlu Yerel deponun dizininin yolu.Bu, kod deposunun WORKSPACE dosyasını içeren dizinin yolu olmalıdır. Yol, ana deponun WORKSPACE dosyasına göre mutlak veya göreli olabilir. |
repo_mapping
|
Sözlük: Dize -> Dize; varsayılan değer Örneğin, |
new_local_repository
Kural kaynağını görüntülemenew_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ülmesine olanak tanır. Bu, mevcut deponun dosya sisteminde herhangi bir yerden hedefleri tanımlayıp kullanabileceği anlamına gelir.
Bu kural, bir WORKSPACE dosyası ve belirtilen BUILD dosyası ve yol ile ilgili semboller içeren bir alt dizin oluşturarak Bazel deposu oluşturur. Derleme dosyası, path
ile ilgili hedefler oluşturmalıdır. Halihazırda bir WORKSPACE dosyası ve BUILD dosyası içeren dizinler için local_repository
kuralı kullanılabilir.
Örnekler
Mevcut deponun, kökü ~/chat-app dizininde olan bir sohbet istemcisi olduğunu varsayalım. Bu istemci, farklı bir dizinde (~/ssl) tanımlanmış bir SSL kitaplığı kullanmak istiyor.
Kullanıcı, SSL kitaplığı için aşağıdakileri içeren bir BUILD dosyası (~/chat-app/BUILD.my-ssl) oluşturarak bağımlılık ekleyebilir:
java_library( name = "openssl", srcs = glob(['*.java']) visibility = ["//visibility:public"], )
Ardından, ~/chat-app/WORKSPACE adresine aşağıdaki satırları ekleyebilirler:
new_local_repository( name = "my-ssl", path = "/home/user/ssl", build_file = "BUILD.my-ssl", )
Bu işlem, /home/user/ssl adresine simge bağlantısı veren bir @my-ssl
deposu oluşturur.
Hedefler, @my-ssl//:openssl
öğesini hedefin bağımlılıklarına ekleyerek bu kitaplığa bağımlı olabilir.
Yalnızca dizinleri değil, tek dosyaları da dahil etmek için new_local_repository
simgesini kullanabilirsiniz. Örneğin, /home/kullanıcıadı/Downloads/piano.jar adresinde bir jar dosyanız olduğunu varsayalım. WORKSPACE dosyanıza aşağıdakini ekleyerek derlemenize sadece bu dosyayı ekleyebilirsiniz:
new_local_repository( name = "piano", path = "/home/username/Downloads/piano.jar", build_file = "BUILD.piano", )
Aşağıdaki BUILD.piano dosyasını oluşturun:
java_import( name = "play-music", jars = ["piano.jar"], visibility = ["//visibility:public"], )
@piano//:play-music
'a 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 belirtilmelidir. Bu özellik, ana çalışma alanına göre bir etikettir. Dosyanın BUILD olarak adlandırılması gerekmez ancak kullanılabilir. (BUILD.yeni-repo-adı gibi bir ad, deponun gerçek BUILD dosyalarından ayırt edilmesini sağlayabilir.) |
build_file_content
|
Dize; varsayılan değer build_file veya build_file_content belirtilmelidir. |
path
|
Dize; zorunlu Yerel dosya sistemindeki bir yol.Bu, ana deponun WORKSPACE dosyasına göre mutlak veya göreli olabilir. |
repo_mapping
|
Sözlük: Dize -> Dize; 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 göre bir etikettir. Dosyanın WORKSPACE olarak adlandırılması gerekmez ancak şöyle adlandırılabilir. (WORKSPACE.yeni-repo-adı gibi bir ad, deponun gerçek WORKSPACE dosyalarından ayırt edilmesini sağlayabilir.) |
workspace_file_content
|
Dize; varsayılan değer workspace_file veya workspace_file_content özelliklerinden yalnızca biri belirtilebilir ancak ikisi birden belirtilemez. |