Çalışma alanı kuralları, harici bağımlılıkları (genellikle ana deponun dışında bulunan kaynak kodu) çekmek için kullanılır.
Not: Bazel, yerel çalışma alanı kurallarının yanı sıra, özellikle web'de barındırılan git depoları veya arşivlerle ilgili kurallar olmak üzere çeşitli Starlark çalışma alanı kurallarını da yerleştirir.
Kurallar
bind
bind(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 açıklama için "Bağlantıyı kaldırmayı düşünün" bölümüne bakın. Özellikle repo_mapping
deposu özelliklerini kullanmayı düşünün.
Uyarı: select()
, bind()
içinde kullanılamaz. Ayrıntılar için Yapılandırılabilir Özellikler ile İlgili SSS bölümünü inceleyin.
//external
paketinde bir hedefe takma ad verir.
//external
paketi "normal" bir paket değil: 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 WORKSPACE dosyasında bu hedefi bind
. Örneğin, //third_party/javacc-v2
adında bir java_library
hedefi olduğunu varsayalım. WORKSPACE dosyasına aşağıdaki dosya eklenerek diğer ad verilebilir:
bind( name = "javacc-latest", actual = "//third_party/javacc-v2", )
Artık hedefler //third_party/javacc-v2
yerine //external:javacc-latest
değerine bağlı olabilir. javacc-v3 yayınlanırsa bind
kuralı güncellenebilir ve //external:javacc-latest
öğesine bağlı tüm DERLEME dosyaları artık düzenlenmesine gerek kalmadan javacc-v3'e bağlı olur.
Bağlama özelliği, harici depolardaki hedefleri çalışma alanınızın kullanımına sunmak için de kullanılabilir.
Örneğin, WORKSPACE dosyasına içe aktarılmış @my-ssl
adlı bir uzak depo varsa ve //src:openssl-lib
cc_library hedefine sahipse bind
kullanarak bu hedef için takma ad oluşturabilirsiniz:
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
tarafından sunulan üst bilgi dosyalarına, depo köklerine göre yol 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
öğeleri aşağıdaki gibi görünebilir:
#include "sign_in.h" #include "src/openssl.h"
Bağımsız değişkenler
Özellikler | |
---|---|
name |
Bu hedef için benzersiz bir ad. |
actual
|
Bu hedef mevcut olmalıdır ancak herhangi bir kural türünde (bağlama dahil) olabilir. Bu özellik atlanırsa |
local_repository
local_repository(name, path, repo_mapping)
Yerel dizindeki hedeflerin bağlanmasına izin verir. Bu, geçerli deponun bu diğer dizinde tanımlanan hedefleri kullanabileceği anlamına gelir. Daha ayrıntılı bilgi için bağlama bölümüne bakın.
Örnekler
Mevcut deponun, rootlanmış ~/chat-app dizininde bulunan bir sohbet istemcisi olduğunu varsayalım. Bu depo, farklı bir depoda tanımlanmış bir SSL kitaplığı kullanmak istiyor: ~/ssl. SSL kitaplığında bir hedef //src:openssl-lib
bulunur.
Kullanıcı, ~/chat-app/WORKSPACE öğesine 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ı olarak @my-ssl//src:openssl-lib
değerini belirtir.
Bağımsız değişkenler
Özellikler | |
---|---|
name |
Bu hedef için benzersiz bir ad. |
path
|
Bu, deponun WORKSPACE dosyasını içeren dizine giden bir yol olmalıdır. Yol, mutlak veya ana deponun WORKSPACE dosyasına göreli olabilir. |
repo_mapping
|
Örneğin, bir |
new_local_repository
new_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 izin verir. Bu, geçerli deponun dosya sisteminde herhangi bir yerden hedef tanımlayıp kullanabileceği anlamına gelir.
Bu kural, WORKSPACE dosyası ile BUILD dosyasının sembolik bağlantılarını ve belirtilen yolu içeren alt dizin oluşturarak bir Bazel deposu oluşturur. Derleme dosyası, path
ile göreli hedefler oluşturmalıdır. Halihazırda WORKSPACE dosyası ve BUILD dosyası içeren dizinler için local_repository
kuralı kullanılabilir.
Örnekler
Mevcut deponun, rootlanmış ~/chat-app dizininde bulunan bir sohbet istemcisi olduğunu varsayalım. Bu istemci, farklı bir dizinde tanımlanmış bir SSL kitaplığı kullanmak istiyor: ~/ssl.
Kullanıcı, SSL kitaplığı (~/chat-app/BUILD.my-ssl) için şunları içeren bir BUILD dosyası oluşturarak bağımlılık ekleyebilir:
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 bağlantı kuran bir @my-ssl
deposu oluşturur.
Hedefler, hedefin bağımlılıklarına @my-ssl//:openssl
ekleyerek bu kitaplığa bağlı olabilir.
Yalnızca dizinleri değil, tek tek dosyaları eklemek için de new_local_repository
kullanabilirsiniz. Örneğin, /home/username/Downloads/piano.jar konumunda bir jar dosyanızın olduğunu varsayalım. WORKSPACE dosyanıza aşağıdakileri ekleyerek sadece bu dosyayı derlemenize ekleyebilirsiniz:
new_local_repository( name = "piano", path = "/home/username/Downloads/piano.jar", build_file = "BUILD.piano", )
Ayrıca aşağıdaki BUILD.piano dosyasını oluşturarak:
java_import( name = "play-music", jars = ["piano.jar"], visibility = ["//visibility:public"], )Bu durumda hedefler, piano.jar'ı kullanmak için
@piano//:play-music
hizmetine bağlı olabilir.
Bağımsız değişkenler
Özellikler | |
---|---|
name |
Bu hedef için benzersiz bir ad. |
build_file
|
build_file veya build_file_content belirtilmelidir. Bu özellik, ana çalışma alanıyla göreli bir etikettir. Dosyanın BUILD olarak adlandırılması gerekmez, ancak adlandırılmış olabilir. (BUILD.new-repo-name gibi bir işlev, dosyayı deponun gerçek DERLEME dosyalarından ayırt etmek için işe yarayabilir.) |
build_file_content
|
build_file veya build_file_content belirtilmelidir. |
path
|
Bu değer, mutlak veya ana deponun WORKSPACE dosyasıyla göreli olabilir. |
repo_mapping
|
Örneğin, bir |
workspace_file
|
workspace_file ve workspace_file_content değerleri belirtilebilir ancak ikisi birden belirtilemez. Bu özellik, ana çalışma alanıyla göreli bir etikettir. Dosyanın WORKSPACE olarak adlandırılması gerekmez ancak adlandırılmış olabilir. (WORKSPACE.new-repo-name kodu, deponun gerçek WORKSPACE dosyalarından ayırt edilmesi için kullanışlıdır.) |
workspace_file_content
|
workspace_file ve workspace_file_content değerleri belirtilebilir ancak ikisi birden belirtilemez. |